Current + AutoElevate integration

AutoElevate, from CyberFOX, is privileged access management: end users work without local admin rights, and a request to elevate is settled by a rule or a technician, or, on a computer in Policy mode, by a rule or the ordinary Windows prompt. Current's AutoElevate integration is a view-only feed into the strategic business review module, the company record and the company alert band. It reads what AutoElevate already knows and never writes back.

What the integration does

Current authenticates to AutoElevate with a key on a Read Only service user, then reads your companies, computers, elevation requests and rules every six hours, plus elevated sessions when the key is allowed to read them. Instead of exporting a computer list from the portal the week of the review, the admin-rights numbers are already sitting on the company record when you open it.

What data flows

• Companies — the AutoElevate company roster, matched to your Current companies so every signal below lands on the right record.
• Computers — each machine's name, the elevation mode AutoElevate reports stored in its own words, Current's reading of whether that mode puts admin rights under control, and when it last checked in.
• Elevation requests — what was asked for, whether it was approved, denied, withdrawn or is still pending, and when. Never who asked.
• Elevation rules — how many approve automatically, how many deny automatically, and how many only log, for each company.
• Elevated sessions — when the key can read them, how many started in the last 30 days, how many are active, and how many expired without closing. A key that cannot read them leaves the section off the card rather than showing zero.

The feed is one-way. Current does not approve or deny a request, create or edit a rule, or change a computer's mode. AutoElevate stays the place where elevation decisions happen; Current uses the evidence.

Admin-rights control is hard to show

When AutoElevate is working, a user asks, the request is settled, and nothing else happens. That makes least privilege one of the harder controls to put in front of a partner. A share of computers under control, set beside how many elevation requests were handled and how many rules approve or deny without a technician, gives the review a figure for it. The computers that are not under control are the other half: a machine left in audit mode after onboarding logs every prompt and stops none of them, and Current names how many there are.

Exact addresses, not prefixes

AutoElevate's API has two write actions, approve and deny, and approving or denying a request can also create a permanent rule for a computer, a location, a company or an entire MSP. Both sit under the elevation-requests address Current reads, so a connector that allowed that address as a prefix would allow them. Current's allowlist names six complete read addresses, character for character, and the code that sends requests has no way to send anything but a read. The outer lock is the key itself: it belongs to a user on AutoElevate's Read Only role, and a key can never do more than its user's role allows.

What was requested, never who asked

An elevation request names the person who asked, and a denied one carries the note the technician wrote for them. Current never reads either. It stores what was requested, its state and its time, because that is what a business review needs, and it cleans the request text before storing it: the folder after a profile folder such as Users or home loses the user's name, on any drive and inside a network path; email addresses and sign-in names are replaced, including names in accented or non-Latin letters; and long text is cut short. A name typed into the request as plain words matches none of those rules, so Current cannot recognise it and stores it as written. The person on an elevated session is never stored either. When someone needs to know who asked, the record is in the AutoElevate portal.

Unknown reads as unknown

AutoElevate reports each computer in Live, Policy, Audit or Technician Bypass mode. Live and Policy count as under control, Audit and Technician Bypass as not, and anything else, including a missing mode, counts as unknown: in neither half of the figure, with the number of unknowns shown. A mode Current does not recognise is never counted as under control. Policy mode is fully under control only when AutoElevate's Remove Admin Privileges setting is on, and the API does not say whether it is, so Current does not claim it. The API also exposes no UAC level and no flag for a user running with admin rights, and Current claims neither.

An alert with a stated threshold

Current raises an admin-rights-exposed entry in the company alert band when a computer has spent 30 days or more in audit mode, or a day or more in technician bypass. Thirty days is where the 30-to-60-day audit onboarding window CyberFOX recommends has had its chance; technician bypass times out after 15 minutes by default, so a day in it is worth a question. The entry turns critical when any of the computers is in technician bypass. It clears when the machine moves to Live or Policy, and every open one clears the moment AutoElevate is disconnected. AutoElevate does not publish when a computer changed mode, so the clock starts when Current first sees it in that mode.

Matching companies to companies

Each AutoElevate company is one end-customer, and AutoElevate keeps an external identifier on each, which defaults to its name. Current tries three ways in order. When that identifier is all digits and equals the PSA company ID Current already holds for a company, the two link directly; that applies only when your PSA stores the ID. Next comes the normalized name, punctuation and Inc/LLC/Ltd-style suffixes stripped, when exactly one company matches. Last, the identifier is read as a name. Where two companies could both be the answer, the AutoElevate company waits on an unmapped list for a person to decide rather than being paired on a guess. A mapping set by hand is never overwritten by a later automatic match, and mapping a company attaches its computers and requests immediately instead of waiting for the next scheduled sync.

Where the data appears

• In strategic business reviews, as an Admin rights, managed chapter that follows the security posture chapter carrying detection feeds such as Huntress and application control from ThreatLocker. The most requested items on that page are printed from the records, never written by the AI.
• On the company record, where the AutoElevate card shows computers by mode, the ones not under control and since when, recent and most requested elevations, the rules set for that company, and elevated sessions when the key can read them.
• In the company's security posture, as an Admin rights figure: the share of computers under admin-rights control.
• On dashboards, as an Admin rights under control tile with the same share across your companies.
• In the company alert band, as an admin-rights-exposed entry.

Why it matters

An MSP running AutoElevate for a partner like Northwind Traders can open the account and see forty-one computers: thirty-eight under control in Live or Policy mode, two still in audit mode long after onboarding ended, and one left in technician bypass since yesterday. Beside them sit the sixty elevation requests handled last quarter, fifty-two approved and eight denied. The two audit machines are an afternoon's work. The request count is the evidence that least privilege is running on those machines rather than written in a policy document.