Connecting AutoElevate to Neo

You connect AutoElevate once at the MSP level, then turn it on per agent.

AutoElevate uses a single API key per MSP. Save it once and every agent that has AutoElevate permissions can use it.

1. Create an API key in AutoElevate

Open a service user

In the AutoElevate admin portal, open a service user and add an API Key.

Pick the API Token (AE-BEARER) scheme

AutoElevate offers two schemes at creation. Pick API Token (AE-BEARER) — the value starts with aeb_.

Do not pick HMAC (AE-HMAC-SHA256). That scheme signs every request with a separate key held on your side, and Neo cannot use it. Its values start with aeh_.

Give the key its scopes

An AutoElevate key carries an explicit scope list.Grant companyView. Neo reads the company list on every PSA sync to keep the client mapping current, so this one is needed whatever your agents do.Then grant the view scopes for each area your agents read, and requestEdit as well if any agent will approve or deny.

Copy the key somewhere safe once it is generated — AutoElevate shows it only once.

2. Add the key in Neo

Open Integrations

In the Neo Dashboard, open Integrations and find the AutoElevate card, under Access Management.

Save the API Key

Paste the key and click Save. Neo checks it against AutoElevate before saving, so a wrong or mistyped key is rejected straight away.

3. Turn AutoElevate on per agent

Each agent decides whether it uses AutoElevate and which areas it can touch. Open the agent, go to its Tools & Settings tab, click Access Management, and expand the AutoElevate block.

Pick a preset

Read Only

Every area set to read only. The agent can find elevation requests, read the evidence behind them, and report — but never decides one.

Helpdesk

Elevation Requests and Elevation Rules set to read and write, with technician approval on every decision. Everything else read only. Fits a helpdesk agent working the “I need admin rights to install this” ticket.

IT Admin

Approves and denies elevation requests on its own. A decision that also creates a rule waits on a technician. Everything else read only.

Full Automation

Approves, denies and creates rules on its own, with no approval. Everything else read only.

Or set each area by hand

Area	Access levels you can pick	Notes
Elevation Requests	Disabled, Read Only, Read and Write	Pending and historic requests, and approving or denying them. Turn on approval to have a technician sign each decision.
Elevation Events	Disabled, Read Only	The file, path, hashes, publisher, signing state and user behind a request.
Elevated Sessions	Disabled, Read Only	Just-in-time admin sessions: who, when, how long.
Elevation Rules	Disabled, Read Only, Read and Write	Auto-approval and auto-denial rules and their scope. Read and Write lets an approve or deny also create a rule; turn on approval to have a technician sign each one.
Computers	Disabled, Read Only	Machine name, OS, elevation mode, last check-in.
Companies & Locations	Disabled, Read Only	Your client hierarchy, used to scope every other lookup.
Account & Audit	Disabled, Read Only	Partner usage figures and the admin audit log.

Every area except Elevation Requests and Elevation Rules is read only, because AutoElevate’s Partner API has no write for it.

Safety controls

You choose whether a decision waits on a technician. The approval setting on Elevation Requests decides it, and the access profile you pick sets it for you. A decision is final: once a request leaves PENDING AutoElevate refuses any further decision on it, and there is no un-approve.
Creating a rule needs its own permission. Both approve and deny can also create an auto-approval or auto-denial rule, and at account scope that rule decides every future matching elevation across every client you manage. AutoElevate has no API to delete a rule. So a decision that creates a rule needs Elevation Rules at read and write, and it waits on a technician when that area’s approval is on. Neo’s agents are also told to leave rules off unless a technician asked for one.
Every other area is read only. Neo cannot edit or delete a rule, or change a computer, a company or a location, through this integration, whatever the agent is set to.
Path safety. Suspicious URL paths (anything containing .., for example) are rejected before they reach AutoElevate.
Neo sets the authentication itself. The API key and AutoElevate’s required beta header are added by Neo on every call. An agent cannot set, replace or read either one.

If AutoElevate refuses Neo’s requests

What comes back	Cause	Fix
`401`	The key was revoked or deleted, or it was created with the HMAC scheme instead of AE-BEARER	Create a new key on a service user with the API Token (AE-BEARER) scheme and save it in Neo. A key starting `aeh_` will never work
`403`	The key’s scope list does not cover the operation	Widen the key’s scopes in AutoElevate. Reading requests, reading events and deciding a request are separate scopes, so a key that lists requests fine can still be refused on approve
A failed AutoElevate Company Mapping row saying the key’s scope list does not include `companyView`	Exactly that	Add `companyView` to the key in AutoElevate. The next PSA sync rebuilds the mapping
A failed AutoElevate Company Mapping row saying AutoElevate rejected the key	The key was revoked or deleted, or created with the HMAC scheme	Recreate it on a service user with the AE-BEARER scheme and save it in Neo. Widening scopes cannot help — the key never authenticated
A failed AutoElevate Company Mapping row saying anything else	A rate limit, an AutoElevate outage, or an error inside the mapping itself	Read the row’s detail before changing anything. The next PSA sync retries on its own
`409` on an approve or deny	The request is no longer pending — a technician, or a rule, already decided it	Nothing to fix. The agent re-reads the request and reports its current state
`429`	The hourly limit for that operation is spent	Wait. AutoElevate allows 100 requests per hour per operation during beta and the wait can be up to a full hour. Neo paces its own calls to stay inside the limit, so this normally means something else is also calling the API with the same key

Until a 401 or 403 is fixed, agents that use AutoElevate report the failure on the ticket they were working. The rest of Neo keeps running.

Disconnecting AutoElevate

Open the integration

In the Neo Dashboard, open Integrations and select the AutoElevate card.

Disconnect

Click Disconnect and confirm. Neo removes the credentials from Key Vault.

Your Organization Mapping is kept, including any mapping you set by hand, so reconnecting later picks up where you left off. Agents that use AutoElevate stop working until you connect it again.

Security

The API key lives in Azure Key Vault. It is never stored in plaintext.
All traffic to AutoElevate goes over HTTPS, to partner-api.autoelevate.com.
Write access is opt in per agent, and it is only ever available on Elevation Requests and Elevation Rules.

Once your key is saved and an agent has permissions, the AutoElevate tool is added to that agent automatically.

Getting started

Core

Triggered & Scheduled Agents

Chat Agents

Integrations

Product

Workflows

Customizing Neo

Connecting AutoElevate to Neo

1. Create an API key in AutoElevate

2. Add the key in Neo

3. Turn AutoElevate on per agent

Pick a preset

Read Only

Helpdesk

IT Admin

Full Automation

Or set each area by hand

Safety controls

If AutoElevate refuses Neo’s requests

Disconnecting AutoElevate

Security

​1. Create an API key in AutoElevate

​2. Add the key in Neo

​3. Turn AutoElevate on per agent

​Pick a preset

Read Only

Helpdesk

IT Admin

Full Automation

​Or set each area by hand

​Safety controls

​If AutoElevate refuses Neo’s requests

​Disconnecting AutoElevate

​Security

1. Create an API key in AutoElevate

2. Add the key in Neo

3. Turn AutoElevate on per agent

Pick a preset

Or set each area by hand

Safety controls

If AutoElevate refuses Neo’s requests

Disconnecting AutoElevate

Security