Draft, ask first, act and tell, act. Per agent, per organisation, with a ceiling.

Every security leader has now been asked some version of the same question: should we let AI agents make decisions about access? Put that way, it is the wrong question. Nobody is proposing that a model hand out production admin on a whim. The real question is narrower and more useful: for each specific job in the access lifecycle, how far should software be allowed to act before a person looks, and how do we take back anything it got wrong?

InsightKeys answers that with an autonomy dial: four levels, set per agent, per organisation, under a ceiling the deployment fixes. This post explains the levels, the defaults and the reasoning behind them, how every agent action stays reversible and on the record, and what should always stay with a person.

Why “should agents decide?” is the wrong question

Access management is full of small, repetitive judgements. Does this sentence mean the payments database or the payments account? Which six of these two hundred actions does this task need? Is this request low risk given who is on call and which incident is open? Did that session do anything outside what was asked? Has this administrator role been used in the last 90 days?

Each judgement is made today by a person, usually badly, because there are too many of them and the person has other work. The result is the familiar pattern: broad roles because scoping is tedious, rubber-stamped approvals because reading every request is impossible, and standing access that nobody removes because nobody has time to check whether it is used.

Agents are good at exactly this kind of work: read the records, apply a rule, explain the reasoning. They are not good at knowing that exports are frozen during an incident, or that a contractor’s engagement ended yesterday. The design task is to give each agent the authority that matches its kind of judgement, and no more.

There is also an accountability point that boards and regulators will ask about. When an access decision goes wrong, someone has to answer for it. With an autonomy dial the answer is clear at every level: at L1 and L2 the person who acted or approved; at L3 and L4 the people who set the agent to that level, inside a ceiling a named executive agreed. That chain is written down in the settings and the audit trail, not implied.

Finally, autonomy is not all or nothing over time either. An agent can start at L2 while the security team learns how it behaves, move to L3 once its record is good, and drop back to L2 the week a major change lands. The dial is meant to be turned.

Four levels, defined

Level	Name	What the agent does	What a person does
L1	Draft	Prepares the work: a proposal, with its reasons and evidence	Does the work, or not
L2	Ask first	Prepares the decision and asks before acting	Approves or rejects each action
L3	Act and tell	Acts, tells the person, and lets them pull it back	Reviews afterwards; undoes if wrong
L4	Act	Acts on its own; the action is recorded	Audits the record

The levels are set per agent and per organisation, and capped by a ceiling fixed for the deployment. If the deployment ceiling is L3, nobody in the organisation can set any agent to L4, however the settings page is used. That separation matters for governance: the people who agree the risk appetite set the ceiling once; day-to-day settings move only beneath it.

The agents and their defaults

The defaults follow one principle: the more reversible and bounded an action, the higher the default; the more it affects a person’s work in progress or permanently changes the estate, the lower.

Agent	Default	What it does	Why this default
Intake	Not governed	Reads the sentence and drafts the request from the catalogue; never invents a resource	The requester confirms the draft, so a person is always in the loop
Least-privilege scoper	L3	Narrows the permission inside the entitlement’s ceiling	It can only remove permissions, never add; a too-narrow grant is cheap to fix
Risk & approval	L3	Scores; approves automatically when the flow and score allow	Bounded by flows and thresholds the organisation wrote; at L1/L2 its approval is a recommendation the approver sees
Session watch	L2	Flags out-of-scope or sensitive activity; asks security to revoke	Revoking interrupts someone mid-incident; a person should confirm first
Standing-access cleanup	L1	Proposes converting standing admin, escalation paths, unused roles and database superusers to on-request	Removing standing access changes the estate and can break automation
Access reviewer	L3	Pre-fills each review line Keep or Remove, with the reason	The reviewer still decides each line; pre-filling is a suggestion
Copilot	Read-only	Answers questions such as “who has write on prod right now?” from the records	It cannot change anything

Illustrative. The further an action is from easy to undo and narrow in reach, the more a person should see it first.

Worked example: session watch at L2

In the demo organisation, Priya, on call for payments during incident INC-4412, received an automatic one-hour grant (AR-0001) to read the payments-api logs on prod-payments. The scoper had narrowed it to six CloudWatch Logs actions on one log-group pattern. During the grant the session made two in-scope log calls, then called secretsmanager:GetSecretValue on prod/payments/stripe-key. AWS denied the call because the scoped policy did not allow it.

Session watch, which compares activity against the grant’s scope and stated reason, flagged the call as sensitive. At L2 it did not revoke. It put a proposal in the agent inbox: revoke AR-0001, with the event that triggered it, for security to approve or reject.

Why ask first? Because the right answer depends on things the agent cannot see. Perhaps a runbook told Priya to check the key’s rotation date; perhaps Priya’s laptop is compromised. Cutting off an on-call engineer mid-incident has a cost, and a security analyst can weigh it in a minute with a phone call. Notice also what already happened without any agent: the scoped permission meant the secret was never read. Least privilege did the protecting; session watch did the noticing.

An organisation with a mature security operations team might move session watch to L3 for critical resources, so it revokes immediately and tells security, who can re-grant if it was a false alarm. That is a legitimate choice. It is a choice to make deliberately, with the 30-day record in front of you.

At L3 the agent would revoke first and tell security, who could re-grant.

Reversible and on the record

Autonomy is only acceptable if mistakes are cheap to find and cheap to undo. Three properties make that true.

Every action has an inbox entry. At L2 it waits there; at L3 it is there with an undo. Approve, reject and undo are the same three buttons for every agent.

Every action is in the audit trail in words. “Agent applied — Least-privilege scoper: AR-0008: narrow to SELECT on billing.invoices (from SELECT on *.*)”, attributed to agent:scoper with a timestamp. Auditors can sample agent decisions exactly as they sample human ones.

Every agent has a track record. The settings page shows runs in the last 30 days, and how many were applied, approved, rejected and reverted. In the demo, the scoper ran on 8 requests and applied all 8; the risk agent ran 4 times and applied 4 automatic approvals. A rising reverted count is the signal to turn an agent down a level.

The read-only Copilot completes the picture. Security can ask, in plain words, “who has write on prod right now?”, “what did Sam do with yesterday’s grant?” or “which standing admins are left?”, and get an answer from the same records the agents used. It cannot change anything, which makes it the safest way to check whether the other agents are behaving as expected.

What stays with a person

Some decisions should not be delegated whatever the dial says, because they need context that no record holds or because accountability must sit with a named individual.

Decision	Why a person keeps it
Denying with context	AR-0006 was denied by security because exports are frozen during INC-4412. No score knew that.
Approving admin in production	Flow #30 requires two named people (payments.lead and security) plus step-up. The risk agent can recommend, not replace them.
Accepting standing access	Keeping a standing admin needs a written reason someone will answer for.
Final say on access reviews	The access reviewer pre-fills lines; the named reviewer signs off. An auditor expects a person’s attestation.
Setting ceilings, flows and thresholds	These express risk appetite. Agents operate inside them.

Setting the dial in your organisation

Keep reading