AutoElevate: admin-rights control, elevation requests, and rules

AutoElevate, from CyberFOX, is privileged access management: end users work without local admin rights, and when something needs elevating, AutoElevate settles the request with a rule or a technician, or, on a computer in Policy mode, with a rule or the ordinary Windows prompt. This connector reads four things out of it: which computers AutoElevate is controlling and which are still in audit mode or technician bypass, what users asked to elevate and what happened to each request, the rules that approve or deny automatically, and, when the key is allowed to read them, the elevated sessions that were granted. Each one hangs off the matching Current company, so it feeds the company record, your business reviews and the company alert band. Current reads AutoElevate and can never change anything in it.

Only a portal Administrator can add users in AutoElevate. A key belongs to a user and can never do more than that user's role allows, so the setup gives Current its own service user on the Read Only role and creates the key on it.

1. 1
   1 · Sign in to the AutoElevate portal as an Administrator

   The portal is msp.autoelevate.com. The redesigned portal at autoelevate.cyberfox.com, in beta since September 2026, has the same key screen.
2. 2
   2 · Add a service user on the Read Only role

   Open Users and press + at the top of the grid. Set the type to Service, give it a name a colleague will recognise, such as Current integration, set Role to Read Only and Company Access to All, and Save. Company Access All matters: a key on a user limited to some companies sees only those companies, and nothing reports the rest as missing.
3. 3
   3 · Create the key on that user

   Open the user, find the API Keys card and press + (Add New). In the New API Key dialog, name the key, keep the Scheme on Bearer (most tooling), set Expires to 1 year rather than the 90-day default, and set Scope to Full access. Then press Add.
4. 4
   4 · Copy the token now

   The API Key Created dialog shows the token once and says "Copy this token now. It will not be shown again." The token starts aeb_. Copy it, then press I've saved this. Put a reminder in your calendar a few weeks before the key expires: on the day it does, the sync stops.

1. 1
   Open the AutoElevate card

   In Current's left sidebar open Integrations (it sits under Workspace, so Tenant Admins have the link) and find AutoElevate in the Monitoring & security section.
2. 2
   Paste the token and press Test connection

   Paste the token into API token. Leave Signing key (HMAC keys only) empty: it is optional, and only a key created with the HMAC-SHA256 scheme needs it, alongside its token. Current reads one company to prove the key works and can see your companies, then one computer. A key that can read companies but not computers still connects, with a warning that computers can't be read. If AutoElevate refuses the key, the card says why. On success the token is stored server-side only; the browser never sees it again, and it is never written into a web address, a status message or a log.
3. 3
   Let the first sync fill the mapping panel

   The first sync reads your AutoElevate companies before anything else, so the mapping panel fills even on a large account.

AutoElevate syncs every 6 hours on a schedule, plus whenever a Tenant Admin presses Sync now on the card. Each run reads your companies first, then locations, then computers, then the elevation requests, then rules, then elevated sessions. The first sync reads back 90 days of requests and sessions. If the key can't read requests at first, the first sync after you give it that permission reads their 90 days instead. After that each run reads the last 30 days again, which picks up a request that was pending last time and has since been answered.

AutoElevate allows 100 requests an hour for each kind of read, and that allowance is shared with every other tool connected to your AutoElevate account. Current counts the reads its scheduled runs and Sync now make and keeps them under 90 an hour on each kind of read, which leaves room for Test connection. It can't see what your other tools spend, so they can still use up the account's 100. Sync now waits 15 minutes after the last run, and won't start while a run is still going. On a large fleet the computers and the rules can take more than one run to read in full; the next run continues each from where the last one stopped. A computer that drops off AutoElevate's list leaves Current after two complete reads without it, and a rule removed in AutoElevate leaves Current after a complete read of the rules without it.

Every request Current makes to AutoElevate is a read, checked before it is sent against a list of six exact addresses: companies, locations, computers, elevation requests, elevation rules and elevated sessions. The list is matched exactly rather than by prefix, which matters here because AutoElevate's approve and deny actions sit under the same elevation-requests address as the read Current makes. Matching exactly makes them unreachable rather than merely unused, including by a bug in Current, and the part of the connector that sends requests has no way to send anything but a read. The Read Only role is the second lock: AutoElevate itself would refuse an approval from that key. Current also leaves out reads it has no use for: your own usage and licence figures with CyberFOX, the portal audit log, and the raw elevation events.

Each AutoElevate company is one end-customer. AutoElevate also keeps an external identifier on each company, which it fills with the company name unless someone changed it. Current tries three ways to link an AutoElevate company to a Current company, in order, and the first way that recognizes it decides. First, when that external identifier is all digits and equals the PSA company ID Current already holds for one of your companies, Current links the two directly; this applies only when your PSA stores that ID on the company. Second, the normalized company name (lowercased, with punctuation and Inc/LLC/Ltd-style suffixes stripped), when exactly one company matches. Third, the external identifier read as a name, the same way. A match that fits two companies stays unmapped for you to decide rather than being paired on a guess.

1. 1
   Let the auto-matcher run first

   Every sync links each AutoElevate company to the one Current company that matches. The clear ones map themselves; only the ambiguous ones need a hand.
2. 2
   Open the mapping panel

   Integrations → AutoElevate → Manage → Customer mapping. It opens on the Unmapped tab, which lists every AutoElevate company the matcher could not place.
3. 3
   Map a company to its Current company

   On an unmapped row press Map, type a few letters of the Current company, and pick it. That company's computers, requests, rules and sessions attach right away, rather than waiting for the next 6-hour sync.
4. 4
   Ignore internal or test companies

   For a company that should never map to a partner (your own machines, a lab, a demo) press Ignore. It moves to the Ignored tab and stops counting against the card's unmapped badge.
5. 5
   Fix a wrong match later

   The Mapped tab lists every linked company; Unmap corrects a bad auto-match, and the Ignored tab's Un-ignore brings a dismissed one back. A mapping you set by hand is never overwritten by a later auto-match, and neither is a manual unlink.

AutoElevate reports one elevation mode per computer, and Current stores it exactly as AutoElevate words it. It then reads each mode as under admin-rights control or not:

• ＋Live (the portal also calls it Active): every elevation prompt is intercepted, rules apply, and anything without a rule goes to a technician. Counted as under control.
• ＋Policy: rules approve or deny, and anything without a rule gets the normal Windows prompt with no technician involved. Counted as under control. It is fully so only when AutoElevate's Remove Admin Privileges setting is on, and the API doesn't say whether it is, so Current can't tell you either.
• ＋Audit: every prompt is logged and nothing is intercepted. This is the mode a computer starts in after install. Counted as not under control.
• ＋Technician bypass: AutoElevate steps aside, with no rules and no notifications, until the bypass times out (15 minutes by default). Counted as not under control while it lasts.
• ＋Anything else, including no mode at all: counted as unknown. An unknown computer sits in neither half of the Admin rights figure, and the card says how many there are. A mode Current does not recognise is never counted as under control.

Every share Current prints is worked out over the computers with a known mode, so unknowns can never push it up or down. The whole-number shares on the card, in the Security section, in business reviews and in the AI brief read 100% only when every computer with a known mode is under control and 0% only when none is; anything between is held to 1% to 99%, so 199 of 200 reads 99%. Where Current could not read something, the figure shows a dash or its section stays hidden, rather than showing zero. And the API has no field for a computer's UAC level, for whether a user is running with admin rights, for its Blocker mode or for its agent version, so Current shows none of those.

• ＋The AutoElevate card on the company record. Four counts by mode: Controlled (live or policy), Audit (logging only), Technician bypass (rules off) and Unknown mode (not recognized yet), with the share under admin-rights control out of the computers with a known mode, and how many are past the alert threshold. Every computer count is exact, however large the fleet. The past-the-threshold count is amber when those computers are all in audit and red when any of them is in technician bypass, the same split as the alert's warning and critical. Then Not under control, a worst-first list of up to eight computers with each one's mode, the date it has been in that mode since and its last check-in, where a computer past the threshold is marked red in technician bypass and amber in audit; Recent elevation requests, the five newest with their state and date; Most requested in 30 days; Rules for this company; and Elevated sessions in the last 30 days, including any active now and any that expired without closing. When the requests, rules or sessions read reaches its cap, the line with the sync time adds "counts are floors". Rules for this company and Elevated sessions appear only when the key can read them and there is something to show, so a section the key cannot read stays hidden rather than showing zero.
• ＋The Security section of the company record: an Admin rights figure, the share of computers under control out of those with a known mode. Beneath it sit the two counts behind the share and how many computers are past the alert threshold, or, when none are, how many are not under control.
• ＋A Strategic Business Review: one line in the security posture evidence, and an "Admin rights, managed" chapter, right after the security chapter, in the magazine and in Live mode whenever the company has AutoElevate computers or requests in the review period. The chapter shows the share of assessed computers under admin-rights control, the requests handled (approved, denied, still waiting, and withdrawn when there are any), the most requested items and the preset rules that approve, deny or only log. The most requested items are printed from the records; the AI that drafts the review never sees them. Like the other optional chapters, you can remove the page from a pack. When AutoElevate was connected too recently for its request history to cover the whole review period, the request captions say "since" the date that history starts, instead of "this quarter". When some of the controlled computers are in Policy mode, a line under the share says they count as controlled only where local admin rights were removed, which the records don't show. The chapter's footer says it carries no requester names.
• ＋The company AI brief: one line of counts (computers, the share under control, how many are in audit or technician bypass, how many are past the alert threshold, how many are in a mode Current can't classify yet, and the elevation requests in the last 30 days). No application names and no machine names.
• ＋An Admin rights under control dashboard metric: the share of computers under admin-rights control right now, worked out over the computers with a known mode. It doesn't wait for the alert threshold, so it can drop before any alert opens.
• ＋The company alert band: an admin-rights-exposed entry that warns when a computer has spent 30 days or more in audit mode, or a day or more in technician bypass, measured from when Current first saw it in that mode. It turns critical when any of those computers is in technician bypass. It clears when the machine moves to Live or Policy or leaves Current after dropping off AutoElevate's list, and every open one clears the moment AutoElevate is disconnected.