Automatically enabled when you configure AutoElevate permissions in your agent workflow.
What It Does
- Find the pending elevation request behind a ticket, scoped to the client on it
- Read the elevation event that carries the decision detail: file name and path, size, both hashes, digital signature state, publisher, signing certificate and the OS user
- Approve or deny a pending request, and optionally create an auto-approval or auto-denial rule with it
- Look up managed computers with their OS, elevation mode and last check-in
- Read the auto-approval and auto-denial rules that may already cover the software
- Read just-in-time admin sessions for audits and “who had admin on this machine” questions
- Enumerate companies and locations to scope a call to a specific client
The decision detail is on the event, not the request
An AutoElevate elevation request carries only its id, the computer, its approval state and a timestamp. ItsrequestedBy and targetDescription fields are usually empty. On the first live account they were empty on all 107 records, including the pending one.
Everything a technician judges on lives on the matching elevation event, which the agent finds by matching the computer and the timestamp. The agent’s skill tells it to do this, so a well-formed AutoElevate summary names the file, its path, its publisher and whether it was signed.
Neo drops five display-only paths from every event before the agent sees them: the base64 application icon (on the trigger and again on any rule that matched), the signer’s raw public key, and the two RDN lists that restate the certificate’s own issuer and subject. They were 62% of the payload and no decision reads them.
Permission Groups
Each group has an access level: Disabled, Read Only, or Read/Write. Only Elevation Requests and Elevation Rules offer Read/Write. AutoElevate’s Partner API has fourteen read routes and two write routes: approve and deny. Either one can also create a rule, so an approve or deny that creates a rule needs both groups at Read/Write. Every other group is read-only by API design.
Each Read/Write group also has an approval setting. An approve or deny asks a technician when Elevation Requests requires approval. One that also creates a rule asks when either group requires approval.
Access Profiles
Read Only
Read Only
All groups Read Only. The agent can find a request, read its evidence and report, but never decides one.
Helpdesk
Helpdesk
Elevation Requests and Elevation Rules at Read/Write, both with technician approval. Everything else Read Only. The agent works the elevation ticket end to end, and a technician signs every decision.
IT Admin
IT Admin
Elevation Requests at Read/Write with no approval, so the agent approves and denies on its own. Elevation Rules at Read/Write with technician approval, so a decision that also creates a rule waits for a technician. Everything else Read Only.
Full Automation
Full Automation
Elevation Requests and Elevation Rules at Read/Write with no approval. The agent approves, denies and creates rules on its own. Everything else Read Only.
Safety Controls
How to Configure
1
Connect AutoElevate
Save your AutoElevate API key in the Neo Dashboard under the Access Management integrations category. Create it on a service user with the API Token (AE-BEARER) scheme; the HMAC scheme cannot be used. See Connecting AutoElevate to Neo.
2
Configure permissions
On the agent’s Tools & Settings tab, click Access Management and expand the AutoElevate block. Pick one of its Presets, which are the access profiles above, or set each permission group yourself.
3
Decide whether the agent may act
Leave Elevation Requests at Read Only for an agent that should only gather and report. Set it to Read/Write for one that should decide. Turn its approval setting on to have a technician sign each decision, or off to let the agent decide on its own. Set Elevation Rules to Read/Write only for an agent that may also create rules.
