> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt
> Use this file to discover all available pages before exploring further.
# AutoElevate API
> Read AutoElevate elevation requests and the file, publisher and user behind each one, and approve or deny — deciding a request always requires technician approval
The AutoElevate API tool gives Neo agents direct access to the CyberFOX AutoElevate Partner API. An agent finds the elevation request behind a ticket, reads the evidence it should be judged on, and resolves the "I need admin rights to install this" workflow without opening the AutoElevate portal.
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 (always behind technician approval)
* 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. Its `requestedBy` 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
| Permission Group | What It Covers |
| ------------------------- | ------------------------------------------------------------------ |
| **Elevation Requests** | Pending and historic elevation requests, and deciding them |
| **Elevation Events** | File, path, hashes, signature, publisher and user behind a request |
| **Elevated Sessions** | Just-in-time admin sessions |
| **Elevation Rules** | Auto-approval and auto-denial rules and their scope |
| **Computers** | Managed machines, OS, elevation mode, last check-in |
| **Companies & Locations** | The client hierarchy every other call scopes to |
| **Account & Audit** | Partner usage figures and the admin audit log |
Each group has an access level: **Disabled**, **Read Only**, or **Read/Write**. Only Elevation Requests offers Read/Write. AutoElevate's Partner API has fourteen read routes and two write routes, and both writes are on elevation requests, so every other group is read-only by API design.
## Access Profiles
All groups Read Only. The agent can find a request, read its evidence and report, but never decides one.
Elevation Requests at Read/Write (still requires technician approval on every decision). Everything else Read Only — enough to work the elevation ticket end to end with a technician signing the decision.
There is no Full Automation profile. The only write this API has is the one that can never go through unattended.
## Safety Controls
| Control | Behavior |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Elevation decision protection** | Approving or denying a request always requires technician approval, regardless of settings |
| **Decisions are final** | Once a request leaves `PENDING`, AutoElevate refuses any further decision on it with a `409`. There is no un-approve endpoint |
| **Rule creation is not automatic** | Approve and deny can also create an auto-approval or auto-denial rule, and at account scope that decides every future matching elevation across every client. The agent is instructed to leave it off unless a technician asked for it, and the technician sees it in the approval either way |
| **Read-only areas** | Every group but Elevation Requests has no write endpoint, so there is nothing to approve or restrict there |
| **Authentication is Neo's** | The API key and AutoElevate's required beta header are set by Neo on every call. The agent cannot set, replace or read either |
| **Rate limit** | 100 requests per hour per operation during beta. Neo throttles its own calls to stay inside it, so a saturated operation fails the agent's call instead of rate-limiting your account |
## How to Configure
Save your AutoElevate API key in the Neo Dashboard under the **Security** 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](/integrations/autoelevate/connecting-to-neo).
In your agent workflow's **Integrations** tab, choose an access profile or set each permission group by hand.
Leave Elevation Requests at Read Only for an agent that should only gather and report. Set it to Read/Write for one that should propose a decision. A technician still approves every one.
Start with **Read Only**. An agent that reliably names the file, the path, the publisher and the signing state in its summary has already removed most of the work from the elevation queue, before it decides anything.