An agent running under an employee's account is two failures wearing one costume. It is a security failure, because the agent holds every entitlement that person holds rather than the few its task needs. And it is an accountability failure, because from the moment it starts running, nothing in your estate can separate what the person did from what the program did in their name. The second failure is the one that survives remediation: you can narrow a scope next week, but you cannot go back and re-attribute eleven thousand ledger entries.
The criterion this actually lands on. CC6.2 reads: “Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.” An agent is a user whose access you administer. Read the criterion with that in mind and most of this page follows from it.
Plain-English explainer · ISO/IEC 42001:2023 · 2017 TSC with revised 2022 points of focus · OWASP Top 10 for LLM Applications, 2026 edition · Last reviewed August 2026
Holding an authority and holding the authority to delegate that authority to software are two different permissions, and almost no organisation has ever granted the second one explicitly. A finance manager who can post journal entries has been assessed for that: somebody decided she was competent, that the value limits were appropriate, and that her work would be reviewed at close. None of that assessment covered the question of whether a program may post entries at three in the morning at a thousand times her rate, without reading the room, without recognising an unusual case, and without her seeing what was posted. When her personal access token ends up in an agent’s configuration, that second permission is granted silently, by nobody, and it is granted at the widest possible scope because a token carries the whole person.
This page is about closing that gap without pretending it is only a token-hygiene problem. It covers the five patterns by which an agent can hold identity and what each one can actually prove, the fifteen fields that make an action attributable to a principal, how to rewrite a scope so it fits a task rather than a person, the ladder from standing authority to just-in-time minting and what each rung costs, what your joiners-movers-leavers process does to a running agent — which today is usually nothing — and the evidence a licensed CPA firm asks for when it tests the control. Whether your deployment is far enough along the capability curve for any of this to bind is a prior question, answered in when a tool becomes an AI agent.
Key Takeaways
- Authority and authority-to-delegate are separate permissions. A person cleared to approve refunds has not been cleared to grant software the standing ability to approve refunds unattended, at machine rate, against a queue nobody has read.
- An agent on a human credential inverts the audit trail rather than merely weakening it. The record does not become vague. It asserts something false, naming a person who was asleep — and where that person also works in the same system, the two populations can never be separated afterwards by any query.
- Give the agent its own principal, then carry the human separately. Actor and subject are two fields: the identity that authenticated, and the authority being exercised. Systems that can only hold one are a documented scope limit, not a reason to merge them.
- Scope to the task, not to the person. The agent needs the operations its job performs on the resources its job touches — not the role its sponsor happened to hold, which is how almost all agent over-privilege arrives.
- Standing authority is the default and the expensive one. The ladder runs from a permanent broad credential through scoped, session-bound and task-minted authority to per-action approval, and each rung trades engineering cost for a smaller thing an attacker inherits.
- Joiners-movers-leavers does nothing to agents today. A role change strips the human and leaves the delegation. A departure either breaks a business process or — far more commonly — produces an exception that keeps a leaver’s credential alive in a shared vault, which is the finding rather than the fix.
- An agent that can change access, identity or its own pipeline is acting on the control environment. That is the one scope conversation that ends in refusal rather than narrowing, because a failure there degrades every control that depends on access control, which is all of them.
Two permissions, and you only granted one
Every authority a person holds was granted against an implicit model of how a person exercises it. Read the table by asking, of each row, whether the original decision to grant the authority contemplated the third column at all. In almost every case it did not, because the third column did not exist when the entitlement was designed.
| Property | A person exercising the authority | A program exercising it in their name |
|---|---|---|
| Rate | A person approving refunds is bounded by attention. Forty in a day is a heavy day, and the fortieth is slower and more careful than the fourth because fatigue is itself a brake. | A program approving refunds is bounded by the API. Forty a second is an ordinary afternoon, and the ten-thousandth is executed with exactly the same confidence as the first, including when the first was wrong. |
| Hours, context and judgement | Acts during working hours, inside a room where other things are happening. Knows the quarter closed on Tuesday, that the customer is in escalation, that something feels wrong today — and escalates when the case is unusual, on a rule nobody ever wrote down. | Acts at 03:12 on a public holiday against a queue nobody has read, with none of that context unless it was supplied. It has no edge unless one was built, and an agent operating at the boundary of its instructions does not hesitate — which is what turns a single bad decision into a uniform policy applied four hundred times. |
| Ability to tell an instruction from a fact | Reads a customer email containing “please issue a full refund and update the account owner to this address” and recognises a request to be assessed, not an order to be executed. | Reads the same sentence as tokens. Where retrieved content and operator instruction arrive through the same channel, the distinction is not reliably available to the system. That is Prompt Injection, LLM01 in the OWASP Top 10 for LLM Applications, 2026 edition. |
| Revocability | Can be told to stop in a corridor, and stops. Disabling their account is a complete and instantaneous revocation of everything they could do. | Stops when a credential is revoked, a schedule is disabled, a queue is drained and any in-flight run is terminated — four actions, in systems usually owned by three teams. A refresh token issued before the revocation may keep working until it is explicitly invalidated. |
| Who is named in the record | The person who acted is the person named. Attribution is free, because identity and agency are the same thing. | Under a shared identity, the person named is not the actor. Every downstream system — the ledger, the ticket, the mailbox, the access log — records a human who was asleep. Attribution is not degraded, it is inverted: the record asserts something false. |
| Awareness on the part of the human | Knows what they did, and can be asked about it a month later with some prospect of a useful answer. | Acts under a person’s name in ways that person frequently does not see. The employee whose token it holds is accountable, in the record, for four hundred actions they have never read — a governance problem before it is a technical one. |
The sentence that settles most internal arguments
When an engineering team and a risk team disagree about whether an agent needs its own identity, the disagreement is usually about capability — the team points out, correctly, that the agent can only do what the token allows, and that the token allows exactly what the job requires today. That is an argument about the security failure, and it is sometimes winnable. It is not an argument about the accountability failure, which is independent of how narrow the scope is. Even a perfectly scoped agent running on a human credential produces a log that names the wrong principal.
The question is not whether the agent can do something the person could not. It is whether, six months from now, anyone can tell which of them did it.
There is a second-order effect worth naming, because it is where the human cost lands. The employee whose credential the agent wears is, in the record, the author of everything it does. If the agent posts to a closed period, sends a message that should not have been sent, or touches a record it should not have, the first name any investigation reaches is theirs. Most people have never been asked whether they consent to that, and many would decline if asked plainly. Delegation that has been affirmed by the person whose authority is being used is a materially different arrangement from a token somebody generated in forty seconds — and the affirmation is cheap, which is the argument for doing it rather than a reason it gets skipped.
Five ways an agent can hold identity, and what each one proves
These are not five options of equal standing. They are a progression, and most organisations are somewhere in the first two while believing they are in the third. Read the third column first: the question a pattern answers is not “is this secure” but “what can the record establish afterwards”, and those come apart more often than people expect.
| Pattern | How it authenticates | What the record can prove | Where it breaks | When it is the right answer |
|---|---|---|---|---|
| P0 — Shared human credential | The agent holds the employee’s password, session cookie or long-lived personal access token and authenticates as that human. Multi-factor authentication is either bypassed by the token type or satisfied once and reused indefinitely. | Nothing about the agent. Every record names the employee. Where the employee also works in the same system, the two populations are permanently merged and cannot be separated after the fact by any query. | Attribution, offboarding, scope, and the credential-hygiene rules you already have. It also makes the human’s multi-factor enrolment a single point of failure for a production process, and turns a routine password rotation into an outage. | Nothing in production. A time-boxed proof of concept in a non-production tenant, with an expiry date recorded at the point of creation, is the outer limit of its defensible use. |
| P1 — Delegated user token | The user completes an authorisation flow and consents to a scoped grant. The application holds an access token issued for that user and refreshes it. This is the standard consent model behind most connector-based assistants. | That the request carried a token issued for that user, and — where the resource records it — which client application presented it. The client identifier is the only thing separating the agent from the person, and many downstream logs do not retain it. | Grants outlive attention. A consent given in March for an interactive session is still funding unattended activity in November. Scopes are usually coarse because they were designed for applications, not tasks, and refresh tokens frequently survive events the user believes ended their session. | Attended, interactive, user-scoped retrieval — an assistant answering a question about documents the person could already open, in a session the person is watching, with no write path. |
| P2 — Dedicated service identity | The agent is its own principal in the directory, with its own credential — ideally a certificate or a federated workload credential rather than a secret — and its own consent grants, held independently of any employee. | That the agent acted, and which agent. It restores the first half of attribution and survives every human lifecycle event. It does not, on its own, record whose authority was being exercised. | The why. You can prove the reconciliation agent posted the entry, but you cannot prove from the record alone that anyone authorised that class of entry, or for whom. Standing privilege is the second failure — a service identity with permanent scopes is a permanent target, and it is the identity an attacker most wants. | Unattended work in a bounded domain where the authority is organisational rather than personal: reconciliation, triage, monitoring, scheduled maintenance inside an allowlist. |
| P3 — Dual principal, actor and subject | The agent authenticates as itself and additionally carries an assertion naming the human or role on whose behalf it is acting. The resource sees two principals: the actor that presented the credential, and the subject whose authority is claimed. The standardised form is OAuth 2.0 Token Exchange, RFC 8693, whose act claim names the acting party alongside the subject — delegation rather than impersonation. Note that Microsoft’s on-behalf-of flow is not this: it yields a user-subject token with the agent present only as a client application id, which is P1 attribution wearing a P3 name. | Both halves. The record can state that agent-reconcile-02 posted the entry under authority delegated by the Financial Controller role, holder named, under delegation grant DEL-114 which expires on a date. That is the sentence an investigator needs and almost never gets. | Downstream support. The pattern is only as good as the last system in the chain, and most line-of-business applications have exactly one actor field. Where the subject cannot be carried, it has to be recorded at your own boundary instead and correlated by task identifier. | Agents that act for individuals at scale — mailbox, calendar, ticket, approval queues — and any case where the authority genuinely belongs to a person or an office rather than to the organisation at large. |
| P4 — Per-task minted credential | No standing credential exists. A broker mints a short-lived credential per run, narrowed by a resource-level condition or a session tag to the records that run needs, with a lifetime no longer than the run is expected to take and the run identifier bound into the credential itself. The agent’s durable identity is used only to ask the broker, never to touch the resource. | The task. Because the credential is bound to a run identifier, the entire chain of calls collapses into one story with a beginning and an end, and a credential found outside that window is self-evidently anomalous rather than merely suspicious. | Your calendar. It requires a broker you operate, a task model the work actually fits, and downstream systems that accept short-lived credentials. Retrofitting it onto an agent already running in production is a project, not a configuration change. | High-consequence unattended work — anything that moves money, changes access, deploys, deletes at scale or publishes externally — and any agent whose compromise you would have to disclose. |
Two things about this table are worth stating explicitly, because they are the points people take away wrongly. A service identity is necessary and not sufficient. Moving from P0 to P2 fixes attribution of the actor and fixes the lifecycle problem entirely, which is most of the value on this page. It does not answer whose authority was being exercised, and for a large class of agents — anything acting for an individual rather than for the organisation — that question is the one an investigator actually needs answered. P3 exists because both halves matter.
And the consent grant is the thing to enumerate, not the token. Credentials are what the security tooling shows you, but the durable exposure is the grant — the record saying this application may read all files and send mail as any user, agreed once by somebody who may have left. It is the input to the connector and permission review rather than an output of it, and how to export it is in the discovery table further down.
What to ask your platform team
P3 and P4 are the destinations, and both depend on capabilities your identity platform either has or does not. These are the questions that establish which, before a control description commits you to something the platform cannot do.
For P3 — dual principal
- Does the authorisation server implement OAuth 2.0 Token Exchange (RFC 8693), and will it issue a token carrying both a subject and an act claim?
- Do the resource servers we care about read the act claim, or do they read the subject and discard the rest?
- Does the resource’s own audit log persist both principals, or only the one it authenticated?
- Where the answer to the last two is no, what identifier can we propagate that the resource will store — and will it survive into the export we hand an auditor?
For P4 — per-task minting
- Can we mint a credential per run rather than per agent, and what is the shortest lifetime the platform supports?
- Can the minted credential be narrowed at issue by a resource-level condition or a session tag, so the scope is the records this run touches rather than the class it belongs to?
- Can we bind the run identifier into the credential, so one seen outside its own run window is anomalous by construction rather than by inference?
- How does the agent authenticate to the broker — mutual TLS, a private key assertion, or a federated workload credential? If the answer is a shared secret, the broker has recreated the problem it exists to solve.
A note on why P0 persists in organisations that know better. It is almost never a decision. It is a four-week queue in front of the team that creates service principals, against a forty-second path to a personal access token, at a moment when somebody is trying to demonstrate that an idea works. The remedy that actually holds is the same one that works for shadow AI: make the sanctioned path faster than the unsanctioned one. A self-serve request that returns a scoped, expiring agent identity within a business day removes the driver entirely. An additional policy prohibiting personal tokens, with the queue unchanged, removes nothing.
Fifteen fields that make an action attributable to a principal
A log that says an entry was posted at 03:14 by a user identifier is not an audit trail for an agent. It is an audit trail for a person, being used to describe something that was not a person. The list below is the minimum set that lets somebody who was not there reconstruct what happened and say who is answerable for it. The first three are the ones this page is about, and the rest are what make those three usable.
| Field | What it holds | Why it is load-bearing, and how it fails |
|---|---|---|
actor_principalprincipal id · identity provider | The identity that authenticated to the resource. For an agent, its own directory object or workload identity — never a human, and never a group. | The field that makes the log true rather than merely populated. Every downstream claim about who did what rests on it, and a shared credential silently falsifies it. Fails as: A group, which names a set rather than an actor. A display name two principals share. A human. |
subject_principalprincipal or role id · nullable · IdP | The human or named role whose authority is being exercised. Empty is legitimate — it means the authority is organisational — but empty must be distinguishable from unrecorded. | It answers “under whose authority” without answering “who typed it”, and it is what makes a departing employee’s delegations findable at offboarding. Fails as: A schema where empty and unrecorded serialise identically. That one ambiguity voids the field for testing. |
delegation_idregister key · delegation register | The grant that authorised this actor to act for this subject — not the token, which is an artefact, but the decision, which is the control. | A token proves the agent could act. A delegation record proves somebody decided it should, names them, and says when that decision expires. Auditors test the second, while monitoring shows you the first. Fails as: Free text nobody can resolve, or a ticket reference rather than a register row, which cannot be sampled as a population. |
delegation_expires_attimestamp · copied at issue | The delegation’s expiry as it stood when the action was taken, copied onto the action rather than only resolved from the register. | It makes “was this action inside its own delegation” a comparison between two fields on one row, rather than a test of today’s register against last March’s action. Fails as: Omitted because delegation_id resolves to it — true until somebody extends an expiry, at which point every historical action retroactively becomes compliant. |
authority_basisenum · standing | approved-request | human-elevated-run | How this action was authorised. Read the third value carefully: it is a run executing under a human’s break-glass elevation, held by the subject and expiring with the ticket. An agent never elevates itself — the absolute stated in the edge cases below. | It turns one log into three populations you can test separately. Elevated runs with no ticket, and standing-grant actions in a class that required approval, are each one query away. Fails as: A value named plainly “break-glass”, which reads as the agent holding emergency authority and will be tested as though it does. |
agent_deployment_iddeployment id · deployment registry | Which build of which agent, with the model, the system prompt version and the tool manifest version resolvable from it. | Behaviour changes when any of those three change. Without it, an incident on 14 March cannot be tied to the prompt revision shipped on 12 March. Fails as: The agent’s name rather than its build, so every incident spans every version that ever ran under that name. |
task_iduuid · minted at run start | The unit of work. Every tool call, retrieval, approval and side effect in one run carries the same identifier. | Investigation is reconstruction. Without a correlation identifier, forty log lines across six systems are forty unrelated events. With one, they are a narrative you can hand to somebody else. Fails as: Minted per tool call rather than per run, producing correlation identifiers that correlate nothing. |
parent_task_iduuid · nullable · orchestrator | The run that spawned this one, empty where a human or a schedule started it directly. | When a sub-agent does something unexpected, the immediate question is which orchestrator asked it to. Without a parent pointer that is answered by reading timestamps and guessing. Fails as: Present only on the first hop, so a three-deep chain looks like two unrelated trees. |
delegation_depthinteger · incremented per hop | How many delegations deep the run sits. Human-triggered is zero, and a sub-agent the orchestrator spawned is one. | Your design states a maximum. This field makes “depth exceeded the declared design” a query rather than an incident. Fails as: Absent, so the declared maximum is an intention with no detection behind it. |
triggerenum + source id · scheduler, queue, gateway | What started the run — schedule, webhook, queue message, human prompt — with the triggering item’s identifier and, where a human started it, their principal. | An agent that ran because a cron fired and one that ran because an inbound email arrived are different risks. Both are unattended, but only one is externally reachable. Fails as: The word “automated”, which collapses the externally reachable triggers into the safe ones. |
tool_and_argumentsstring + json or digest · agent runtime | The tool invoked and its arguments, or a digest of them where they carry personal or customer data, with the digest algorithm recorded. | The tool without the arguments tells you the agent sent an email, not to whom. Arguments in clear create a second copy of the data under different retention. The digest survives both objections. Fails as: A digest with no algorithm recorded, which cannot be recomputed and therefore proves nothing. |
approval_refapproval id + digest · nullable · workflow | The human approval this action consumed, if any: who approved, when, what they were shown, and whether the approved item is byte-identical to the executed one. | An approval that does not reference the exact action executed is not an approval, it is a coincidence. This is where “a human reviewed it” becomes testable. Fails as: A pointer to a queue item with no digest of what was displayed, so drift between shown and executed is undetectable. |
targettenant · environment · record id | The resource acted upon, qualified by tenant, environment and record identifier. Environment is not optional. | Blast radius is computed from this field. An incident response that cannot enumerate targets ends in a notification decision made on a guess. Fails as: A bare record identifier with no environment qualifier, so every incident call opens with twenty minutes establishing which system was touched. |
outcome_and_reversalstatus + compensating action + window | What happened, and what undoes it: the compensating action, who can perform it, and whether the window has passed. | Reversibility decays. Recording at the moment of action how long the undo path stays open is the difference between a two-hour containment and a customer conversation. Fails as: Success or failure only, leaving the undo path to be reconstructed under pressure by whoever is awake. |
timestamp_and_clockRFC 3339 with offset · stated source | An event time with a stated source and offset, in one timezone discipline across every system in the chain. | Ordering is the whole of causation. Two systems five seconds apart will reverse the apparent order of a cause and its effect, and an investigator who notices late has already written the wrong conclusion. Fails as: Local time with no offset, which is indistinguishable from correct until the clocks change. |
One action, populated
Field definitions are easy to agree and hard to apply, so here is the 03:14 ledger posting from the worked example further down this page, with all fifteen fields filled. Read it for the shape of an answer rather than the content. Two values are empty and both are empty deliberately, which is the distinction the schema exists to preserve.
actor_principal | svc-agent-reconcile-02 · Entra ID object 8f31c0…, workload identity, no interactive sign-in enabled |
subject_principal | role:financial-controller, held by the incoming Controller from 24 June 2026. Not the departed holder. |
delegation_id | DEL-114 |
delegation_expires_at | 2026-09-30T23:59:59+05:30 — ninety-three days after the action, so the action is comfortably inside its own grant |
authority_basis | standing |
agent_deployment_id | recon-agent@2026.06.24-3 · model pinned, prompt revision 11, tool manifest hash 4c9a… |
task_id | run-2026-06-29-0301 |
parent_task_id | (empty — the scheduler started this run directly) |
delegation_depth | 0 |
trigger | schedule · cron job ledger-recon-nightly, fired 03:01:04+05:30. No externally reachable input on this path. |
tool_and_arguments | ledger.entry.create · arguments digested, SHA-256 a11f… (the entry carries counterparty data). Digest recomputable from the ledger row. |
approval_ref | (empty — this entry is below the per-entry value ceiling that routes to a human) |
target | tenant acme-prod · environment production · ledger entry GL-2026-06-114882 · account set RECON-4 |
outcome_and_reversal | posted. Reversal is a compensating journal by the Controller. The window closes when the June period closes on 7 July. |
timestamp_and_clock | 2026-06-29T03:14:22+05:30 · source: agent host, NTP-disciplined, drift under 50 ms at write |
Now read the same action as the other two systems hold it, because the gap between them is the whole subject of this page. The agent’s own run log has everything above and one thing more — the reasoning trace and the retrieved rows that produced the match. The ledger’s native log has one line: GL-2026-06-114882 created 03:14:22 by svc-agent-reconcile-02. That is all it can hold, because the ledger has one actor field and no concept of a subject. The Controller’s authority, the delegation, the expiry and the value ceiling exist only in your record — which is exactly why corroboration means matching the agent side to the resource side on task_id and target, and why a system description that claims the ledger carries dual-principal attribution is claiming something an auditor will disprove in one screenshot.
What a shared identity costs you, stated precisely
The loss is easy to underestimate because it is invisible while everything works. Consider a ledger in which one human posts entries during the day and an agent posts entries at night, both as the same principal. Four questions arrive eventually, and the shared identity answers none of them.
Which of these entries did the agent post?
Unanswerable from the ledger. You can enumerate the agent’s side from its own run logs, but you cannot confirm the ledger side, so the reconciliation is by timestamp correlation — persuasive, not conclusive, and a working paper that says so is the honest output.
Did the agent act outside the hours it was scheduled for?
Unanswerable, because human activity and agent activity occupy the same series. The anomaly detection you would normally run — this principal acted at an unusual hour, at an unusual rate, against an unusual resource — is defeated by construction, and this is the detection you most needed.
When the person’s entitlement was removed in April, did the agent stop?
No, and you will not notice. A token issued before the change continues to carry the authority it was issued with until it is explicitly revoked, so the entitlement change is effective for the human and ineffective for the software acting as them.
Can we produce this for the auditor as evidence of who acted?
You can produce it. It will be tested, and the test is a single question — how do you know this population is the agent and not the individual — for which there is no answer available. Expect this to land as a deficiency in the attribution of activity rather than as a finding about AI.
Note the asymmetry that makes this urgent rather than merely untidy. Every other defect on this page is remediable going forward: a scope can be narrowed next week, a credential can be replaced tomorrow, a stop mechanism can be built and tested. Attribution cannot be retrofitted. The period in which the agent ran under a human identity is permanently ambiguous, and if that period is your observation period, the ambiguity is in the report. That is the argument for fixing identity first and everything else second. What to do with the records once the principals are distinct is covered in monitoring and audit logs for agents.
What delegation_id resolves to
Every action carries a delegation identifier, and an identifier that resolves to nothing is decoration. The register is the artefact an auditor samples from, the thing a delegating principal reads before affirming, and the only place the word “authorised” is cashed out into a scope, a name and a date. Twelve fields, of which two are almost always missing — what the person was actually shown when they agreed, and what a running agent does the moment the grant lapses.
| Field | What a good value holds | How it fails |
|---|---|---|
delegation_id | A stable key referenced by every action taken under the grant, and by the approval that created it. | A row number. Registers get re-sorted, and every historical action then points at somebody else’s grant. |
delegating_principal | The person or named office whose authority is being lent, with the entitlement written as the operations it covers rather than as the role name it came from. | A role name alone. Roles are renamed and re-scoped, so the register stops describing what was actually delegated. |
agent_identity | The actor: one directory principal, one agent. The same value that lands in actor_principal on every action. | A team, a platform or an orchestrator that fronts several agents — the point at which the register stops resolving to anything testable. |
scope_set | Operations, resources and limits, in the three-part form set out below. This is the field the approver actually approves. | A single role name, which is how almost all over-privilege arrives, in one line nobody queried. |
basis | Standing, per-request or time-boxed — matching the rung the agent sits at, so the register and the ladder cannot drift apart. | Unstated, so every grant is read as standing by default, which is the widest reading available. |
approver | A named individual who is neither the requester nor the agent owner. The constraint belongs in the form, not in the guidance note. | The agent owner approving their own agent — requester and approver in one account, which no auditor accepts for human access. |
granted_at · expires_at | Both dates, with expires_at mandatory and bounded. An open-ended delegation is not a delegation, it is a transfer. | A blank expiry, or one so distant it will outlive the agent, the approver and the entitlement. |
reaffirmation_due | The date the delegating principal must renew, set ahead of expiry so a lapse is a decision rather than an outage. | Set equal to expiry, so the only signal arrives when the agent has already stopped. |
lapse_behaviour | What a running agent does when the delegation lapses mid-run: fail and raise, complete the in-flight unit then stop, or block at the next consequential call. Stated per grant, because the right answer differs between a mailbox agent and a ledger agent. | Unspecified, which in practice means the agent keeps running on a credential the delegation no longer supports — the exact defect the expiry existed to prevent. |
withdrawal_route | Where the delegating principal goes to revoke, and the fact that it needs no change window and no ticket queue. | A route that runs through the agent owner, which makes withdrawal a negotiation with the person who benefits from the grant. |
what_the_principal_was_shown | A digest or copy of the scope statement as displayed at the moment of affirmation. | Absent, so a later dispute about what was agreed is settled by whoever remembers it more confidently. |
status | Active, lapsed, withdrawn, reassigned or superseded — with the date and the reason on every transition. | Active and inactive only, which cannot distinguish a grant that expired from one somebody revoked in anger at 2am. |
Two design notes worth settling before the first row is written. The approver constraint belongs in the form. If the register will accept a row where requester and approver are the same account, that row will eventually exist, and it will be the one sampled. And lapse_behaviour is a per-grant decision, not a platform default — a mailbox agent that stops mid-thread is an inconvenience, a ledger agent that stops half-way through a posting run is a reconciliation problem, and the right answer differs. Deciding it in advance is what stops somebody choosing “renew silently” at three in the morning.
Standing authority, and the rungs above it
Standing authority means the agent holds its power when it is not working. It is the default because it is the easiest thing to build, and it is the reason a compromised agent is worth so much: an attacker who reaches it inherits a job description rather than a job. Each rung below narrows what is inheritable, and each one costs more to operate. Pick the rung by consequence, not by enthusiasm — an agent that files tickets does not need per-task minting, and an agent that moves money is not adequately served by a scoped standing credential.
| Rung | What it holds between runs | What it costs to operate | What a compromise yields | How it is evidenced |
|---|---|---|---|---|
| L0 — Standing broad | A durable credential carrying a role a human holds: finance writer, repository admin, mailbox full access. It is live at 04:00 on a Sunday whether or not the agent is running. | Nothing to operate, which is exactly why it is where most agents start and stay. The cost is deferred entirely to the day something goes wrong. | Everything the role can reach, for as long as it takes somebody to notice — and the noticing is hard, because the credential is being used legitimately most of the time. | A scope list and an approval. Nothing about the scope list changes between the first and last day of the period, which is itself what an auditor will remark on. |
| L1 — Standing scoped | A durable credential carrying only the operations the agent’s task class requires, on only the resources that class touches. Still live at 04:00 on a Sunday, but considerably less interesting to hold. | A scope-design exercise once, and a review cadence thereafter. The review is the part that decays: scopes are added during incidents and never removed afterwards. | The task class, on the allowlisted resources. Real damage, bounded damage, and a blast radius you can describe to a customer in a sentence. | The scope list at two dates inside the period, the review record with a named reviewer, and the change record for every scope added between them. |
| L2 — Session-scoped | Nothing between sessions. A credential is issued when the agent starts and expires when it stops or after a fixed interval, whichever comes first. | An issuance path and a decision about what happens to a run that outlives its credential — which must be “it fails and raises”, never “it silently refreshes”. | One session’s worth of authority. A credential stolen from a log or a memory dump is usually dead before it is useful. | Issuance records with lifetimes, and a failed-refresh case in the log that shows the expiry is real rather than nominally configured. |
| L3 — Task-scoped, just in time | Nothing at all. A broker mints a credential per run, narrowed to the specific resources that run has been asked to touch — this customer, this period, these accounts — and it expires with the run. | A broker, a task model, and downstream systems willing to accept short-lived credentials. This is the rung with a genuine engineering bill attached. | One task, on one set of records, inside one window. The attacker inherits the agent’s current job rather than its job description. | Minting records tied to run identifiers, the scope computed for each, and the correlation that shows every action in the run used the credential minted for it. |
| L4 — Per-action approval on top of L3 | Nothing, and the minted credential is not sufficient on its own: each consequential action additionally consumes a human approval that references that exact action. | Human attention, which is the scarcest input in the system and the one that degrades fastest under volume. Applied everywhere it produces approval fatigue and becomes a formality. Applied to the consequential minority it stays real. | Nothing without a human also being deceived or coerced, which raises the cost of the attack rather than eliminating it. | Approval records carrying the approver, the timestamp and a digest of what was shown, plus a demonstrable population of rejections — an approval step with a hundred per cent approval rate is a rubber stamp with a log. |
The step changes are worth reading deliberately. L0 to L1 is design work done once in exchange for a blast radius you can describe in a sentence — the cheapest improvement available, and the one most often skipped in favour of monitoring the broad credential more closely. L1 to L2 buys an issuance path and loses the permanently valid secret, which removes the commonest way a credential leaks: a secret that sat in a configuration file long enough for somebody to copy it elsewhere. L2 to L3 buys a broker and a task model — a genuine engineering programme — and in exchange the credential stops describing the agent and starts describing one job. L4 buys nothing technical at all. It buys a human, which is why it belongs only where a human decision is worth its cost.
Six failures, and what each one looks like in an export
Naming a failure mode is cheap. What makes one governable is a signature — a query a reviewer can run against data you already hold, returning rows rather than opinions. The last row below is the standard the others are written to meet: an approval step with a hundred per cent approval rate is a rubber stamp with a log, and that is findable in one line. The design that keeps a human checkpoint real is covered in human-in-the-loop that actually means something.
| Failure mode | How you find it | What the query needs |
|---|---|---|
| Refresh-token survival past an entitlement change | Actions by a principal whose entitlement-removal or termination date precedes the action timestamp. Join the HR feed or the directory change log to the action record on subject_principal and compare dates. | subject_principal, timestamp_and_clock, and a directory change log retained as long as the action log |
| Silent refresh mid-run | A second credential issuance inside a run that already has one, or any action in a run whose timestamp falls after the stated expiry of the credential that run was minted with. | task_id on issuance records, and issuance lifetimes recorded rather than assumed |
| Delegation depth exceeding the declared design | Runs where delegation_depth is greater than the maximum your design states. One query, run on a schedule, against the field rather than against an architecture diagram. | delegation_depth and parent_task_id, propagated through every hop |
| Scope creep under incident pressure | Scope additions with no corresponding change record, and additions whose change record cites an incident ticket — the second set is the population to re-review once the incident is closed, and almost nobody does. | Two scope exports from dates inside the period, and change records keyed to the agent identity |
| Orphaned non-human identities | Directory non-human principals with no inventory row, and inventory rows marked retired whose consent grants or credentials are still live. The second direction is the one teams forget, and it is where the retired-but-authenticating agent shows up. | A directory extract and an inventory extract from the same date, reconciled both ways |
| Approval fatigue at L4 | An approval population with no rejections in it. This is the signature every other row on this table should be measured against: specific, queryable, and impossible to argue with. | approval_ref with outcomes, and a rejection count somebody actually looks at |
The silent refresh deserves its own sentence because it is the one that quietly undoes everything above L1. An agent whose credential expires mid-run and which obtains another without anyone deciding has converted a session-scoped design back into a standing one. The rule is that a run outliving its credential fails and raises, and that the failure is visible to a person — which is also why a failed-refresh case in the log is better evidence that the expiry is real than any amount of configuration.
One clarification before anyone cites this ladder in a control description. No standard prescribes these five rungs, and none requires a particular one for a particular class of agent. The scheme is ours, and it exists so that the control you write is proportionate and legible. What a service auditor tests is the control you stated, against the population it applies to — so state the rung, state which agents sit at it, and make sure the two lists agree.
Scope to the task, not to the person
Almost all agent over-privilege arrives in one line, at the moment somebody answers the question “what access does it need?” with the name of a role rather than a list of operations. The role was designed for a human doing a varied job across a long career. The agent does one thing. The exercise below is mechanical and takes an afternoon: write down the operations the job performs, the resources it touches and the limits that bound it, then ask for exactly that.
| What was asked for | What the task actually needs | What the narrow grant costs | What the broad grant costs on a bad day |
|---|---|---|---|
| The role the human holds — “finance writer”, because that is what the sponsoring manager had | ledger.entry.create only, restricted to the reconciliation account set, per-entry and per-run value ceilings, current open period only, no ability to post to prior periods or to close one. | One afternoon mapping the operations the job actually performs, and a genuine possibility that the agent fails on a case nobody anticipated — which is information you wanted anyway. | An agent that can post to any account in any period, including closed ones, at machine rate, under a name that is not its own. The remediation after that is a restatement conversation, not a configuration change. |
| Mail send permission across the tenant, because the agent needs to reply to a customer | Send only from the shared support address, only to recipients already present on the originating thread, only from a draft created inside the current run, with external recipients outside that thread routed to a human. | A send path that has to be built rather than granted, and a handful of legitimate cases that now require a person. | An agent that can email anybody in your address book and anybody outside it, under a real employee’s name, with the recipient having no way to tell. The first thing an injection attempt asks an email-capable agent to do is send something. |
| Write access to the repositories, because the agent opens pull requests | Branch creation and pull-request opening on branches matching an agent prefix, no force-push, no modification of workflow definitions or branch-protection settings, no merge to a protected branch, no access to repository secrets. | Two allowlists and a policy exception process for the rare repository that genuinely needs different treatment. | An agent able to alter the pipeline that reviews it. Once the agent can edit workflow files it can approve its own changes, and every downstream control that assumed a reviewed pipeline is now assuming something untrue. |
| The same production credential used in the test environment, because the test tenant has no data | A separate identity per environment, with the production identity unable to authenticate from the build network at all, and test data that is synthetic rather than a copy. | Two sets of credentials to manage and a seeding job for test data. | Every developer with access to the test configuration holds production authority. The agent is not the vulnerability here. The shared credential is, and the agent simply gave it a reason to exist. |
Reach is the union of two things people assess separately
A scope review that reads only the tool manifest understates reach, and one that reads only the directory entitlements understates it differently. What the agent can actually do is the intersection of the tools it is offered and the authority of the identity it presents. A read-only tool held by an identity with tenant-wide document access has enormous reach. A powerful tool held by an identity scoped to nine records has very little. Neither fact is visible from the other side of the pair, which is why the review looks at both together and why architecture diagrams are a poor substitute for exported grants.
“The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives.”
Read the two concepts named at the end of that criterion against an agent. Least privilege is the whole of the table above. Segregation of duties is the refusal list below it: an identity that can both perform an action and alter the controls over that action has had two duties combined, and the fact that the identity is a program rather than a person changes nothing about why that is a problem. This is also where access control as a discipline meets agent governance: the concepts are not new, the population is.
The form that makes it mechanical
Three parts, filled in before anybody is asked to approve anything. This is what goes into the scope_set field of the delegation register, and it is what the approver approves — because an approver shown a role name is approving a word, and words do not constrain anything.
Operations
The verbs the job performs, named as the API or platform names them, one line each. Not the role that contains them.
Worked: ledger.entry.create. Nothing else — not read, not amend, not close, not post-to-prior-period, all of which the finance-writer role carries and the job never uses.
Resources
The allowlist, expressed the way the platform can actually enforce it: an account set, a sensitivity label, a repository prefix, thread membership, a tenant and an environment.
Worked: Account set RECON-4, current open period only, tenant acme-prod, environment production. The agent cannot authenticate from the build network at all.
Limits
The ceilings, per call and in aggregate: per run, per day, a value ceiling, a period, an environment. These are the constraints the prompt cannot enforce and the platform can.
Worked: A per-entry value ceiling that routes anything above it to a human, a per-run entry count ceiling, and a hard stop outside the scheduled window.
And the operations you decline rather than narrow
These are scattered through the rest of this page as they arise, and collected here so they can be pasted into a scope approval as a standing condition. Every one of them is a refusal rather than a negotiation, because each gives the agent a path to the control environment rather than to the work.
| Identity and group write | A system that can grant access can grant itself access, and every control downstream of access control degrades at once. |
| Security configuration | Changing the thing that constrains you is not a permission, it is an exit from the control environment. |
| Pipeline and branch-protection definitions | An agent able to edit the workflow that reviews it can approve its own changes. Every control assuming a reviewed pipeline is then assuming something untrue. |
| Secret read | A secret read is a credential the log never sees used. It converts one scoped identity into whichever identity the secret belongs to. |
| Audit-log write, export deletion or purge | The record of what the agent did must not be within the agent’s reach, for the same reason a cashier does not hold the till tape. |
| Any write to its own scope or delegation row | Self-amendment makes the register describe what the agent allowed rather than what a person approved. |
| Break-glass elevation | Elevation is a human act with a ticket, a second approver and an expiry. An agent that can elevate itself is unconstrained by everything downstream of the elevation. |
Expect the narrow grant to fail on a case nobody anticipated, and treat that failure as a finding about the task rather than as a reason to widen the grant. A capability added under incident pressure and never removed is the standard mechanism by which a scoped agent becomes a broad one over eighteen months — which is why every scope addition is a change with a record, the subject of tool approval and capability change.
Joiners, movers and leavers does nothing to an agent
Your joiner-mover-leaver process is probably mature, and it is entirely about humans. An agent is a user whose access you administer, so every row in it should have an equivalent — and in most organisations none of them do. Read the third column as a description of the present, not as a caricature: this is what happens today in organisations with good identity governance for people.
| Event | What happens to the human | What happens to the agent today | What the control should do | What evidences it |
|---|---|---|---|---|
| Joiner — a new agent is stood up | A person is registered, authorised and issued credentials before they touch anything, and somebody owns that decision. | An agent acquires a token during development, usually the developer’s own, and the token becomes production by the ordinary process of nobody revisiting it. No registration, no authorisation record, and frequently no inventory row. | The agent identity is registered and authorised before credentials are issued, with a sponsoring owner, a delegating principal where one applies, a declared scope set, an expiry date on the delegation and an inventory row created at the same moment. | The creation record and the authorisation that precedes it, in that order, with dates that are the right way round. An authorisation dated after the first use is the finding we hit most often on this control in readiness work. |
| Mover — the sponsoring human changes role | Entitlements are recalculated against the new role, and the leaving team’s access is removed. In a mature shop this happens, but in most it happens partially. | Nothing happens to the agent. Its scopes were derived from the human’s old role and persist unchanged, so an authority that has been removed from the person remains exercisable by software acting in their name. | A role change on a delegating principal triggers a re-affirmation of every delegation they hold. Unaffirmed delegations lapse on a stated deadline rather than persisting by default. | The trigger record linking the HR event to the delegation review, and at least one delegation that lapsed or was reassigned during the period — a review that has never changed anything invites the question of whether it runs. |
| Leaver — planned departure | The account is disabled on the last day, and the offboarding checklist is signed. | One of three things. The agent stops mid-run at 18:01 and a business process silently fails. Or it keeps running on a refresh token that survived the disablement. Or — the worst and the most common — the account is deliberately kept alive because the reconciliation depends on it, and a leaver’s credential is moved to a shared vault. | No business process depends on a human account. Offboarding enumerates the delegations held by the departing principal and either reassigns them to a named successor or terminates the agents that rely on them, as a blocking step rather than a follow-up. | The offboarding record showing the delegation enumeration ran, the reassignment or termination decision with its approver, and confirmation that the human credential was actually revoked rather than parked. |
| Leaver — immediate, for cause | Access is cut within minutes, and the speed of that cut is the whole point of the control. | The design is tested for the first time under the worst possible conditions. If a revenue-critical agent runs on the departing person’s credential, somebody will argue for a delay, and the argument will be about business continuity rather than about security — which is what makes it persuasive and dangerous. | Because agents hold their own identities, cutting a human is always safe. This is the real argument for separate identities, and it is worth making in these terms to a board: the design exists so that no future conversation about disabling an employee is also a conversation about an outage. | A documented test, or a real event, in which a principal was disabled without degrading an unrelated automated process. |
| Contractor or third-party engagement ends | The engagement closes and directory access is removed, usually on a date somebody in procurement knows. | Agents built during the engagement outlive it, under credentials tied to identities that no longer exist or, worse, that still do. Nobody inside the organisation can explain what the agent does, because the person who could has been paid and has gone. | Agents built by third parties are registered with an internal accountable owner from the first day, and the engagement’s closure checklist includes agent transfer or retirement as a named item with a named receiver. | The internal owner recorded at creation and not at closure, plus the transfer record with an acceptance by the receiving owner. |
| The agent itself is retired | Not applicable — and that is the gap. There is no HR event for a decommissioned program. | The schedule is disabled and the work stops, so the retirement is considered done. The identity, its consent grants, its secrets and its inventory row all remain, and an identity nobody monitors with scopes nobody reviews is a better foothold than most. | Retirement is a defined lifecycle state with its own checklist: revoke grants, delete or rotate secrets, remove the identity, close the inventory row with a date and a reason, and confirm no schedule or webhook still references it. | The retirement record with each item confirmed, and a reconciliation of the directory’s non-human principals against the inventory showing no orphans. |
The immediate-departure row is the one to take to a board, because it converts a technical preference into a business argument in a single sentence. If an agent runs on a human credential, then every future decision to remove someone’s access immediately is also a decision to break a process — and that argument will be made, under pressure, by people acting in good faith, at exactly the moment speed matters most. Separate identities exist so that conversation never happens. Which agents exist at all is a question for the AI system and agent inventory, and the inventory and the directory should reconcile — the reconciliation is the test that finds every orphan in one query.
What escalation actually means, hour by hour
“Escalates to the owning function’s head” is a sentence that settles nothing at two in the morning. The column that matters here is the fifth: what the agent is permitted to keep doing while the escalation is open. Notice that it is not the same answer in every row, and that the differences are principled — an unowned agent is an accountability gap and keeps running, an orphaned principal is an unexplained credential and does not.
| Trigger | Day 0 | The deadline behind it | Who decides | What the agent may still do | Where it is recorded |
|---|---|---|---|---|---|
| Owner field resolves to a departed identity | Automated notice to the owning function’s head naming the agent, its scopes and its blast radius | Day 20 — suspended: credential disabled, schedule stopped, inventory row marked unowned | Owning function’s head accepts or reassigns, and the identity administrator executes | Runs normally. There is no evidence the agent is misbehaving, only that nobody is answerable for it. | Inventory row and the monthly validation record |
| Delegation past expires_at | The agent behaves as its lapse_behaviour states, and the delegating principal and agent owner are both notified | Day 14 — the register row moves to lapsed and the scopes derived from it are removed | Delegating principal renews. Nobody else can renew on their behalf | Nothing consequential. A lapsed delegation is not a degraded state to be worked around. | Delegation register, with the transition date and reason |
| Delegation lapses mid-run | The run fails and raises, or completes the in-flight unit and stops — whichever the grant specified in advance | Same day — the responder confirms whether in-flight work needs reversing | Responder, without an approval chain | Nothing. A run that silently obtains a second credential is the failure this whole rung exists to prevent. | Run log and the incident queue if anything was left half-done |
| Orphan principal found in reconciliation | Credential disabled the same day. An unowned, unregistered non-human principal has no claim to keep working. | Day 10 — deleted if nobody has claimed it, with the claim window recorded | Identity administrator disables, and the security lead approves deletion | Nothing — it is disabled first and discussed afterwards, which is the opposite of the owner-departure case and deliberately so | Reconciliation record and the retirement checklist |
| Agent found holding a scope it was never approved for | Scope removed, and the change record for the addition retrieved — or its absence noted, which is the more serious finding | Day 5 — the scope approver decides whether the operation is needed at all, and it is re-requested properly if so | Scope approver, never the agent owner | Runs without the scope. If that breaks the job, the job was doing something nobody approved. | Change record, scope review, and the exception register if it has to stay |
One rule pre-settles the business-continuity argument, and it has to be written down before the night it is needed: a dependency on a human credential is never a reason to defer disabling that credential — it is a reason to raise an incident against the dependency. The deferral may still be granted, because sometimes it must be. What changes is that the exception has an owner, a compensating control, an expiry and a re-review at that expiry, rather than becoming the permanent arrangement the composite below describes.
The controller left in May. The agent did not.
An illustrative composite, not a client. A 180-person logistics software company, Security and Confidentiality, Type 2, observation period 1 January to 30 June 2026. Read the two middle rows together: the entitlement was removed from the person in April and remained exercisable by software in her name until June.
| Build | 3 Feb 2026 | A finance systems analyst builds an invoice-reconciliation agent. It reads the bank feed, matches entries against open invoices and posts the matched ones to the ledger. It authenticates with a personal access token belonging to the Financial Controller, because she holds the posting role and generating the token took forty seconds. Nobody is being careless. There is no non-human identity path in this organisation, and creating one would have required a conversation with a team that has a four-week queue. |
| Go-live | 17 Feb 2026 | The agent runs nightly and posts between two hundred and eight hundred entries a night. The Controller continues to post entries manually during the day, in the same ledger, under the same identity. From this date the two populations are indistinguishable in the record, and no query written afterwards can separate them. |
| The mover event | 6 Apr 2026 | The Controller moves to a corporate-development role. Her ledger-posting entitlement is removed from her profile the same week, correctly and promptly. The personal access token, issued before the change, keeps working. The agent posts eleven thousand entries over the following six weeks using an authority its delegating principal no longer holds, and every one of them is recorded under her name. |
| The leaver event | 22 May 2026 | She leaves the company. Offboarding runs, and the account disablement is deferred by the finance team because the nightly reconciliation depends on it. A dated exception is raised — which is better practice than most organisations manage — and the credential is moved to a shared vault with three people holding access. The exception is granted for thirty days and is still open at period end. |
| Detection | 11 Jun 2026 | The quarter-close variance review finds forty-one entries posted to a period that closed on 31 March. The question “who posted these” returns a departed employee. The question that actually matters — was this the agent or was it a person using the vaulted credential — has no answer available anywhere in the estate. |
| Scoping | 11–19 Jun 2026 | Eight days to establish what could not be established. The agent’s own run logs exist and are good, so its actions can be enumerated from its side, but the ledger cannot confirm them from the other side, because both populations carry the same principal. The reconciliation is done by matching timestamps, which is persuasive rather than conclusive, and the working paper says so. |
| Remediation | 19 Jun – 24 Jul 2026 | A non-human identity is created for the agent with posting rights restricted to the reconciliation account set, the current period only, and a per-run entry ceiling. A delegation register goes live on 24 June with four entries, each carrying a named approver and an expiry. The vaulted credential is revoked and the departed account disabled on 3 July, which takes eleven minutes once nothing depends on it. The period-boundary check that should have rejected the forty-one entries is added to the agent and, separately, to the ledger, because a control living only inside the thing it constrains is not a control. |
Three failures are worth separating, because they get merged in the retelling and carry different lessons. The scope failure is ordinary and fixable in an afternoon: the agent held a posting role rather than a posting operation. The lifecycle failure is structural: an entitlement change correctly applied to a person had no effect on software acting as her, because a token carries what it was issued with. The attribution failure is the one that cost eight days, because it could not be fixed at all — not in June, and not ever. The working paper says the reconciliation is by timestamp correlation, which is the honest description of what the evidence supports, and honesty there is worth more than a confident sentence that would not survive a follow-up question.
At fieldwork in July the populations are small and legible, which is typical for these controls. The delegation register is a new control, live from 24 June: four entries, all four tested for a distinct approver and an expiry — design, and operation from its implementation date to period end, which is all the population supports. The five months before it are covered by the exception narrative rather than by the register, and saying so is the difference between a stub operating period and an overstated one. One offboarding exception, tested end to end — and that is where the auditor spends the time, because an exception raised, dated, approved and then left open past its own expiry tells a more complete story than any control that operated normally. The identity change in June is a mid-period control change and belongs in the system description with the date it took effect. The forty-one entries are an incident inside the observation period, which is not automatically an exception and frequently reads as evidence that detection works.
The register as it stood at period end
Four rows, six days old. Read DEL-116 first: its delegating principal is deliberately empty, because fetching a bank statement is an organisational authority and nobody’s personal one. That empty value is a decision recorded, not a field somebody skipped — and the register has to be able to tell those apart.
| ID | Delegating principal / agent | Scope set | Approval, expiry, lapse |
|---|---|---|---|
| DEL-114 | role:financial-controller · incoming holder from 24 Jun 2026svc-agent-reconcile-02 | ledger.entry.create · account set RECON-4 · current open period only · per-entry and per-run value ceilings | Approved by the Finance Director, 24 Jun. Expires 30 Sep. Re-affirmation due 31 Aug. Lapse: fail and raise. Status active. |
| DEL-115 | role:accounts-payable-leadsvc-agent-invoice-triage | invoice.read, invoice.classify · supplier set AP-ALL · no write to the ledger, no payment release | Approved by the Financial Controller, 25 Jun. Expires 31 Dec. Re-affirmation due 30 Nov. Lapse: block at next call. Status active. |
| DEL-116 | (empty — organisational authority, no personal delegation)svc-agent-bankfeed | statement.fetch on two named accounts · read only · no ability to initiate or amend a payment instruction | Approved by the Head of Treasury, 25 Jun. Expires 31 Dec. Re-affirmation due 30 Nov. Lapse: fail and raise. Status active. |
| DEL-117 | role:financial-controllersvc-agent-close-checklist | task.create, message.send restricted to the finance close channel · no external recipients | Approved by the Finance Director, 26 Jun. Expires 30 Sep. Re-affirmation due 31 Aug. Lapse: complete in-flight, then stop. Status active. |
The exception, as the working paper records it
This is the document the auditor spends longest on, and it is worth reading the last two rows together. The organisation did almost everything right — raised it, dated it, had two executives approve it, attached compensating controls, bounded it to thirty days. Then nothing watched the boundary.
| Exception reference | EXC-2026-041 |
| Raised | 22 May 2026, by the Finance Systems Lead, on the day offboarding ran |
| What is being excepted | Deferral of account disablement for a departing employee, because the nightly reconciliation authenticates as her |
| Approved by | CFO and Head of IT, jointly, 22 May 2026 |
| Compensating controls | Credential moved to a vault with three named holders, vault access logged, daily review of the reconciliation output by the incoming Controller |
| Granted until | 21 June 2026 — thirty days |
| Actual closure | 3 July 2026, when the vaulted credential was revoked and the account disabled |
| Open past expiry | Twelve days, of which nine fall inside the observation period |
| Why it was missed | The exception register had no owner-level re-review at expiry. The only date it tracked was the one it was raised on |
Then the arithmetic, which is where small populations bite. The register is a population of four. The auditor tests all four — there is no sampling at that size — for a distinct approver and a bounded expiry. All four pass, so the delegation control has no deviations in its stub operating period. Had one row carried the agent owner as its own approver, the deviation rate would be a quarter, with no sample size to absorb it and no basis for arguing the exception was isolated. The offboarding exception is a separate population of one, and it fails: open twelve days past its own expiry, nine of them inside the period. One deviation in a population of one is not a rate at all, which is why exceptions get tested end to end rather than sampled.
Disabling the account took eleven minutes once nothing depended on it. It had been impossible for six weeks for the same reason it took eleven minutes: nobody had ever decided that a business process could run on a person.
What the CPA firm actually requests
Teams expect to be asked for an architecture description. What they are asked for first is a population of non-human identities, because a sample drawn from an incomplete list proves nothing about the list it came from. On this control the population question is unusually hard, and being unable to answer it is itself the first finding.
How to answer the population question
No single console holds this list, which is why the honest answer takes a week rather than an afternoon. Run all seven sources, keep a source column on every row so a later completeness argument has something to stand on, and expect the last two to produce the surprises. The right-hand column is the question the export cannot answer for you.
| Source | What it reliably finds | What it structurally misses | The question to ask about each hit |
|---|---|---|---|
| Identity provider — service principals, workload identities, app registrations | Every non-human object the directory knows about, with its credential type and, usually, its creation date. On Entra ID this is Enterprise applications plus App registrations. Other providers expose an equivalent listing under a different name. | Anything authenticating without a directory object at all: a raw API key issued by a SaaS product, a database user, a token minted by a system you federated years ago. | Which of these is an agent, which is a legacy integration, and who would notice if it stopped? |
| Enterprise-application consent grants | The durable exposure rather than the credential: which application may read all files or send mail as any user, which scopes were granted, who consented and when. Exposed on Entra ID through Enterprise applications, then Permissions, and through the Microsoft Graph oauth2PermissionGrants collection. | Whether the grant is still used. A grant consented to in 2024 by somebody who has left looks identical to one granted last week for a live agent. | Who consented to this, are they still here, and would they consent again knowing what it reaches today? |
| Long-lived personal access tokens | The P0 population directly. GitHub classic and fine-grained tokens, GitLab personal and project tokens, Atlassian API tokens — each carrying a named human’s entitlements into whatever is holding it. | Where the token is being used from. The platform shows you that a token exists and when it was last active, not which pipeline or agent holds it. | Is this a person’s convenience or a production dependency, and if it is the second, which one? |
| Cloud IAM | AWS IAM users holding long-lived access keys, as distinct from roles that are assumed. GCP service-account keys and any domain-wide delegation. Azure managed identities and their role assignments. The key-versus-assumed-role split is the one that matters — the first is a standing secret, the second is not. | Federated workload credentials in use without a key, which is the good pattern and therefore the one least visible in a key-hunting exercise. | Why does this need a standing key rather than an assumed role, and what breaks if we take it away? |
| SaaS bot tokens versus user tokens | The distinction most inventories collapse: Slack bot tokens against Slack user tokens, Salesforce connected apps against integration users. A user token carries a person, but a bot token does not. | Products with no service tier at all, where the only available answer is a licensed identity used exclusively by the agent — the constraint described in the edge cases below. | Is this acting as the workspace or as a named person, and was that a decision or a default? |
| Secret stores and CI variables | What is actually held, which is the population the directory cannot see. The useful output is a secret-to-principal map: for each secret, which principal it authenticates as and which pipeline reads it. | Secrets held outside the store — in a configuration file, an environment variable set by hand, or a developer’s machine. | Which principal does this secret resolve to, and is that principal in the directory extract we already pulled? |
| Schedulers, webhooks, queue consumers and mailbox grants | The things that invoke agents rather than the things agents authenticate with — cron entries, webhook registrations, queue consumers, and mailbox delegate or application-access grants that let one identity act in another’s mailbox. | Agents invoked interactively, which leave no scheduled trace and are found through the gateway or the assistant console instead. | Which principal does this run as, and does anything still reference an identity we thought we retired? |
Then the step that turns seven exports into a population: reconcile the union against the agent inventory in both directions. Directory principals with no inventory row are unregistered agents or legacy integrations, and each needs a disposition. Inventory rows whose principal no longer exists are stale entries. And inventory rows marked retired whose credentials or consent grants are still live are the finding that matters most, because somebody has already told you that agent was decommissioned. State the count from each side and enumerate every difference — a reconciliation that reports agreement without showing its two counts is an assertion.
The five requests, and what gets sent back
| The request | What satisfies it | What gets rejected |
|---|---|---|
| Evidence each agent identity was authorised before credentials were issued | For each identity in the population, an authorisation record naming the sponsoring owner, the delegating principal where the authority is personal, the requested scopes and an approver who is not the requester — dated before the creation timestamp on the identity itself. | An approval dated after first use — in our experience the most frequent defect here. An approval by the person who built the agent. A ticket that says “as discussed” with no scope list attached. |
| Evidence scopes were reviewed and least privilege considered | The granted-scope list at two dates inside the period, a review record with a named reviewer and a date, the change record for every scope added between the two extracts, and at least one instance of a scope being removed or refused. | A screenshot of current permissions taken during fieldwork, which evidences today and says nothing about the period. A review with no output. A scope list that has grown with no corresponding change records. |
| Demonstrate attribution for a selected action | For a sampled action, a record that names the acting principal, the authority under which it acted, the run it belonged to, the tool and target, and the approval it consumed if any — corroborated from the resource’s own log rather than only from the agent’s. | A log line naming a human where a program acted. An agent-side log with no corroboration at the resource. A correlation identifier that exists in one system and not in the next one along the chain. |
| Evidence of removal on retirement and on owner departure | Retirement records showing grants revoked, secrets rotated or deleted, the identity removed and the inventory row closed, plus a reconciliation of directory non-human principals against the inventory showing no orphans at period end. | A disabled schedule offered as a retirement. An inventory row marked retired while the identity and its consent grants remain live in the directory — the reconciliation is exactly the test that finds this. |
| Evidence delegations expire and are re-affirmed | A delegation register with scope, approver, delegating principal and expiry, plus evidence that expired entries were closed or re-approved during the period, and at least one lapse that actually took effect. | Open-ended delegations with no expiry. A register where every entry was re-approved in a single batch on one day near period end. Requester and approver as the same account. |
What the auditor is establishing about every export is its completeness and accuracy, and the artefact class has a name — information produced by the entity, usually shortened to IPE — which is why the query, the filter, the date range and the record count have to travel with the result. Populations here are small, and smallness changes the arithmetic rather than softening it, as the composite above works through. How that plays out is covered in sampling and sample sizes and evidence collection.
Two other regimes ask about the same subject matter in different registers, and it is worth knowing the difference before you build one evidence set for all three. ISO/IEC 42001:2023 is an AI management system standard, certifiable by an accredited certification body, and the questions it raises here are management-system questions: who is accountable for this agent, what roles were assigned, is the inventory current, was an impact assessment done proportionate to what the agent can reach. The role your organisation occupies determines which of those obligations are yours at all. The EU AI Act — Regulation (EU) 2024/1689 — matters here through human oversight: Article 14 requires high-risk systems to be designed so that natural persons can effectively oversee them, and oversight assigned to a person who cannot see what was done under their own name is oversight in the organisation chart only. Its high-risk phasing moved: the Digital Omnibus on AI, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026, deferred stand-alone Annex III obligations from 2 August 2026 to 2 December 2027, and AI embedded in Annex I products to 2 August 2028. That is more time to build the control, not an exemption from it, and most internal agents are not high-risk systems in any event.
The crosswalk: requirement, field, artifact
This is the table to have open when somebody asks which requirement the delegation register serves. The middle column is why the register and the action record have the fields they have, while the right-hand column is what is actually handed over. Clause and criterion references are as published — check them against your own copy of the standard rather than against a summary, including this one.
| Requirement | Reference | Which fields carry it | The artifact that satisfies it |
|---|---|---|---|
| Registration and authorisation before a credential is issued | SOC 2 — CC6.2, 2017 Trust Services Criteria (2022 revised points of focus) | delegation_id, agent_identity, approver, granted_at | The authorisation record, dated before the creation timestamp on the identity itself, with an approver who is not the requester and the scope list attached rather than referenced. |
| Least privilege and segregation of duties | SOC 2 — CC6.3 | scope_set, the refusal list | Scope exports from two dates inside the period, the change record for every addition between them, and at least one scope refused or removed — the refusal is what makes the review credible. |
| Accountability and assigned roles for AI systems | ISO/IEC 42001:2023, clause 5.3 and NIST AI RMF 1.0, GOVERN 2.1 | Agent owner and deputy, delegating_principal | The monthly owner-validation run with its exceptions and the disposition of each — reassigned, retired or suspended. A named person, never a team. |
| Operational control over how AI is used | ISO/IEC 42001:2023, clause 8.1 | basis, expires_at, reaffirmation_due, lapse_behaviour | The re-affirmation cycle records for the period, including at least one delegation that actually lapsed. A register where nothing has ever lapsed invites the question of whether the expiry is enforced. |
| Recording of event logs | ISO/IEC 42001:2023, Annex A.6.2.8 | The fifteen action fields, in full | A sampled action corroborated from the resource’s own log rather than only from the agent’s, with the correlation identifier present on both sides. |
| Decommissioning and phasing out safely | NIST AI RMF 1.0, GOVERN 1.7 | status, the retirement checklist | The retirement record with grants revoked and secrets destroyed, plus the directory-to-inventory reconciliation showing no orphans at period end. |
| Human oversight, where the system is in scope | EU AI Act — Regulation (EU) 2024/1689, Article 14 | subject_principal, what_the_principal_was_shown | The feedback path that shows the delegating human what ran under their name, and the withdrawal route they can use without a ticket queue. Oversight assigned to someone who cannot see the activity is oversight on paper. |
| Detecting and responding when an agent acts outside its bounds | SOC 2 — CC7.2 through CC7.4 | The failure-signature queries | The queries themselves, their schedule, and one instance worked through to a documented conclusion. A detection with no worked instance is a query, not a control. |
One caution about the middle column. Nothing in it was written with a non-human principal acting for a named human in mind — the SOC 2 criteria predate agents, the AI standards govern the management system rather than the identity architecture, and Article 14 is about oversight rather than attribution. The crosswalk works because the underlying concepts transfer cleanly, not because any of these instruments contemplated the case. Say that in the control description rather than implying a mapping that is tighter than it is.
Tranquility Cybersecurity does the readiness, the control design, the evidence preparation and the coordination on both sides of that line. Certificates are issued by accredited certification bodies and SOC reports by licensed CPA firms, and the separation is what makes their output worth something. Where you need a named accountable owner for agent identity whose job is not also to build the agents, that is what a fractional CISO or DPO engagement is for.
Five roles, and the one everybody forgets
The forgotten one is the first. Organisations appoint agent owners, they have identity administrators, and they know who approves things. Almost nobody has asked the person whose authority is being exercised whether they agree to it, or given them a way to see what has been done in their name. The third column is the test that matters: a role somebody holds but cannot act on within an hour is a title rather than a control.
| Role | What they decide | What they must be able to do within the hour | How it commonly fails |
|---|---|---|---|
| Delegating principal | Whether their authority may be exercised by software at all, over what scope, and for how long. This is a decision a person makes about their own authority, and it is the decision most organisations have never asked anybody to make. | See what has been done under their name in the last thirty days, and withdraw the delegation without needing a change window or a ticket queue. | The delegation is inferred from the fact that somebody used their token. Nobody asked, the person cannot enumerate what runs under their name, and they discover the arrangement during an investigation. |
| Agent owner | What the agent does, when it runs, what it may call, and whether a proposed capability change is still within the authority the deployment was approved under. | Describe the agent’s purpose, its blast radius and its stop procedure from memory, and name the person who would respond if it misbehaved tonight. | Ownership sits with a team rather than a person, which means it sits with nobody at two in the morning. Team-level ownership is fine for a service, but it is not sufficient for an authority. |
| Identity administrator | Nothing about the agent’s purpose, and everything about how its principal is created, credentialed, reviewed and destroyed. The separation is deliberate: the person who operates the lifecycle should not be the person who benefits from a shortcut in it. | Revoke a specific principal’s credentials and consent grants, and confirm the revocation took effect at the resource rather than only in the directory. | Non-human identities are created by whoever needs one, in whichever console is open, with no common process — the state in which the population question cannot be answered at all. |
| Scope approver | Whether the requested authority is proportionate to the task, and whether anything in the request touches the control environment — access, identity, security configuration, pipeline definitions — which is a refusal rather than a negotiation. | Explain why each granted scope is necessary, in terms of the operations the agent performs rather than the role it inherited. | The approver approves the role name rather than the operation list, because the role name is what the request contained. Most over-privilege arrives this way, in a single line nobody queried. |
| Responder | At the moment it matters, whether to stop the agent, and accepts that stopping a healthy agent unnecessarily is the cheaper error. | Execute the stop without an approval chain, know what happens to in-flight work when they do, and reach someone who can reverse the agent’s recent actions if the answer is that they must be reversed. | The stop procedure exists as a paragraph and has never been executed. The first test is the incident, and the first discovery is that revoking the credential does not drain the queue. |
Two of these must be different people, and the separation belongs in the control rather than in intent. The scope approver cannot be the agent owner, because an owner approving their own agent’s permissions is requester and approver in one account. And the identity administrator should not be the agent owner either, because the person who operates a lifecycle should not be the one who benefits from skipping a step in it. Everything else can be combined in a small company, provided the combination is deliberate and stated. Why naming a team is not the same as naming a person is the subject of control ownership.
A cadence is not a control until it has a number
“Reviewed periodically” cannot be tested, and a control that cannot be tested cannot be relied on. The numbers below are defaults rather than requirements — no standard sets them, and your risk appetite and agent population should move them. What is not optional is that each cell in the second and fifth columns holds a number once you have decided. Note which rows are event-driven as well as periodic: a ninety-day re-affirmation that ignores a role change on day four is a calendar, not a control.
| Control | Trigger or frequency | Owner | The output it must produce | What happens when it is late | What the auditor samples |
|---|---|---|---|---|---|
| Delegation re-affirmation | Every ninety days, and immediately on any HR role change affecting the delegating principal | Delegating principal, chased by the agent owner | A renewal or a lapse, recorded against the register row with a date | Fourteen days after the due date the delegation lapses and the agent behaves as its lapse_behaviour says | Every re-affirmation in the period, plus at least one lapse that actually took effect |
| Scope review, L0 and L1 agents | Every six months, and on every scope addition | Scope approver, who is not the agent owner | The exported scope list, the diff against the prior export, and a decision on each addition | Thirty days late, the agent is flagged to the owning function’s head. Sixty days, it is suspended | Two exports from dates inside the period and the change record for every scope added between them |
| Directory-to-inventory reconciliation | Monthly | Identity administrator | A count from each side, an orphan list, and a disposition for every orphan | One missed month is an exception with a named remediation date. Two is a control failure | Two to five monthly reconciliations, with the source counts visible on each export |
| Owner-field validation against the directory | Monthly, alongside the reconciliation | Identity administrator | The list of agents whose owner resolves to a departed or disabled identity | Day 5 the owning function’s head is notified. Day 20 the agent is suspended, not merely flagged | The validation run with its exceptions and the disposition of each — reassigned, retired or suspended |
| Consent-grant export review | Quarterly | Identity administrator with the security lead | Every grant confirmed as still needed, narrowed, or revoked — with at least one revocation expected | One quarter late is an exception. The grants continue, which is why the review matters more than the deadline | Two quarterly reviews, and evidence that something was actually revoked |
| Personal-token sweep | Quarterly, and on every departure | Platform engineering | Long-lived personal tokens enumerated and correlated against secret stores and pipelines | Any hit found outside a scheduled sweep is treated as a finding about the sweep, not only about the token | The sweep output and the replacement record for each hit — replacement, not rotation |
| Stop-mechanism test | Twice a year per agent at L0 or L1, annually above that | Responder rota, observed by the agent owner | A dated test record naming what was stopped, how long it took, and what happened to in-flight work | An untested stop mechanism is disclosed as untested rather than described as a control | The test record, and ideally one real invocation inside the period |
The fifth column is the one teams write last and auditors read first. A review with no consequence for lateness runs late, then runs quarterly instead of monthly, then stops — and the control description still says monthly, which is now a statement that will be tested against evidence that contradicts it. Whatever the consequence is, it has to be something that actually happens without anyone choosing to make it happen.
The cases that produce genuine disagreement
The design above covers the common eighty per cent. These are the situations where engineering, security and legal reach different answers in good faith, and where settling the question in advance is worth several days later.
The agent that genuinely must act as the user
Some work is irreducibly personal. An assistant that files a person’s expenses, drafts from their mailbox or holds their calendar exercises an authority belonging to them and nobody else, and a service identity with mailbox-wide access is the worse answer, not the better one — it converts a personal authority into an organisational one. The correct shape is P3: the agent authenticates as itself and carries an assertion naming the person, so the record holds both. Where the platform cannot represent two principals, record the pair at your own boundary, propagate a correlation identifier into everything you control, and state the limitation in the system description rather than letting an auditor find it. A control described with its scope limit is testable, but one described as complete and discovered to be partial is an exception.
Delegation chains and sub-agents
An orchestrator that spawns sub-agents is delegating a delegation, and one rule keeps it tractable: authority narrows at every hop and never widens. A sub-agent inherits at most the intersection of what the orchestrator holds and what its own task requires. Two failure modes recur. The sub-agent that authenticates independently with its own broad standing credential, so the chain is a fiction and the narrowing never happened. And the orchestrator whose identity is used for every downstream call, which makes the fleet indistinguishable in the log — you know the orchestrator acted four thousand times and cannot tell which sub-task did what. Propagate task_id through every hop and record delegation_depth, so a chain three deep against a design that says two is found by query rather than by incident.
The SaaS product with no concept of a non-human user
Many business applications have per-seat licensing, no service-account tier, and an API that authenticates only as a named user. The vendor’s terms sometimes prohibit shared accounts, so the options are a seat for a fictitious employee — awkward, and occasionally a terms breach of its own — or running the agent as a real person and accepting the attribution loss. The workable position is a licensed identity used exclusively by the agent, never used interactively, with interactive sign-in blocked at the identity provider so exclusivity is enforced rather than promised. Record that the constraint is the vendor’s, raise it at renewal, and make it a scored question in supplier due diligence. It is a genuine constraint and worth documenting as one.
Personal API keys and the developer’s own token in a pipeline
The fastest way to get an agent working is to put a developer’s personal token in a secret store, and it is the origin story for most problems on this page. The token carries the developer’s full entitlements rather than the task’s. It is invisible to any review of application permissions, because it is not an application. It survives their role change. And when they leave, the pipeline breaks in a way nobody connects to the departure for days. Search for this population rather than waiting to meet it: enumerate long-lived personal tokens, correlate them against secret stores and pipeline configurations, and treat every hit as an identity to be replaced rather than a credential to be rotated. Rotation preserves the defect.
Break-glass, and the agent that can grant access
Two rules here, both absolute rather than graduated. An agent does not hold break-glass authority — elevation is a human act, with a ticket, a second approver and an expiry, and an agent that can elevate itself is constrained by nothing downstream of the elevation. This is why authority_basis names a human-elevated run rather than a break-glass agent. And an agent that can change access, group membership, security configuration or pipeline definitions is acting on the control environment itself: a failure there does not cause one bad outcome, it degrades every control that depends on access control, which is all of them. Where automation must touch entitlements — joiner provisioning is the honest example — the agent raises a request and a separate, differently-privileged mechanism effects it, with neither identity able to impersonate the other.
The executive’s agent
When a founder or an executive runs an agent on their own credential, the design is void for everyone below them, and staff notice long before an auditor does. It is also the highest-value identity in the organisation and usually the least scoped, because nobody has wanted the conversation. The answer is the one that works for privileged access generally at small companies: no informal exemption, a documented exception with an expiry where there is genuinely a reason, and somebody independent enough to raise it — an audit committee member, a non-executive director, an external advisor — who sees the delegation register. An exception that is written down is survivable, but one that is merely understood is not.
Agents that authenticate into a customer’s tenant
Once your agent holds credentials in a customer’s environment, their joiners-movers-leavers process and yours are coupled, and neither party notices until an engagement ends. Three things follow. The credential should be theirs to revoke unilaterally without needing you to act, which means a federated or customer-issued credential rather than a password they gave you. The scope belongs in the engagement documentation in operational terms rather than as a role name, so somebody who was not present when it was granted can check it. And your own offboarding should enumerate customer-side credentials held by a departing engineer, which most offboarding checklists do not contemplate at all. Expect this in the customer’s security questionnaire before it appears in yours.
Machine identities are a population nobody owns
Counts of non-human principals are contested — published ratios range from single digits to dozens per employee, depending entirely on what the counter treats as an identity — and agent deployments push the number up sharply, because each deployment tends to create several. The number is not the governance consequence. The consequence is that the population is unowned: a population with no owner field cannot be reviewed, because review means asking somebody a question. Make owner mandatory at creation, validate it against the directory monthly, and give the validation teeth — a dated suspension behind it, because a flag nobody is obliged to clear becomes a permanent feature of the report. Agents make non-human identity governance urgent in organisations that had been getting away with not having any.
A thread runs through all eight: the defensible position is almost never the one claiming complete coverage. Where a vendor platform, a customer environment or a legacy application forces a compromise, state the compromise and the compensating measure — an auditor tests what you said rather than what you wished. Where the constraint is the vendor’s, it belongs in supplier due diligence as a scored question at renewal rather than as a footnote in your own architecture. And once the population runs to dozens rather than a handful, delegation stops being a per-agent decision and becomes a matter of inherited risk classes, which is the subject of governing hundreds of agents. The related problems of what an agent may spend and how it is stopped are covered in spending and transaction limits and kill switches and circuit breakers.
What buyers push back on and the answer
These seven now appear in enterprise security reviews, and the second one is newer than the rest — it separates the organisations that have thought about attribution from the ones that have only thought about capability.
“Under whose account does your AI agent access our data?”
Answer with the principal, not the product. The good answer names a dedicated identity used only by that agent, states the operations it can perform in your tenant rather than the role name it holds, says whether a human authority is being exercised through it and whose, and states how long its credentials live. The answer that ends a deal is “our engineers access it through the platform” when the questioner has already worked out that a program is doing the accessing. If the honest answer is that a named person’s credential is in use because the platform offers nothing else, say so with the compensating controls attached — buyers accept constraints they can see and price, and do not accept discovering one later.
“Can you prove an action in our tenant was taken by a person and not by an agent?”
This is appearing in enterprise security reviews now, and it is a good question because it separates the organisations that have thought about attribution from those that have thought about capability. The answer is yes only if the acting and authorising principals are different fields and both survive into the resource’s own log. Where they do, show the shape of the record. Where they do not, describe the correlation you maintain and be precise about what it establishes. A vendor who says “we correlate by timestamp, which is persuasive rather than conclusive” is more credible than one claiming certainty they cannot demonstrate.
“What happens to the agent when the employee who built it leaves?”
The answer should be “nothing, because it does not run on their credential”, and if that is true it is the strongest sentence you can offer here. If it is not yet true, the honest version is a date. What you should not do is describe the offboarding checklist as though it covers this: a checklist that disables a human account does not enumerate delegations, does not revoke consent grants held by applications the person authorised, and does not find the personal access token in a pipeline secret. Those are three separate steps, and a buyer asking this usually knows that.
“Is the agent a sub-processor?”
The agent is not a party, but the vendors behind it may well be. What matters to the questioner is which third parties process their data and under what terms, and an agent architecture typically introduces at least a model provider and sometimes a tool or retrieval service. Those belong on the sub-processor list where their processing touches customer personal data, with the usual change-notification commitment. Where the model runs inside your own tenancy under an enterprise agreement, say so and say which terms govern retention and training — answering from the vendor’s current documentation rather than an internal summary written at procurement.
“Do you use shared service accounts?”
Distinguish two things that sound identical. A shared account used interactively by several humans is a control weakness, and the right answer is no. A dedicated identity used exclusively by one automated process is not shared at all, and the right answer is yes with the specifics. The question is usually asked in the first sense and answered in the second, which is how a true answer becomes an argument later. Say which you mean, and where a vendor platform has forced a single licensed identity, name that constraint rather than letting it read as a choice.
“Can the agent grant itself more access?”
The answer must be no, and it must be structural rather than behavioural. Structural means the acting identity has no write path to identity, group membership, security configuration or the pipeline definitions governing its own deployment, and that a capability change is effected by a different principal. Behavioural means you told it not to, which is not an answer — an agent instructed not to modify permissions is one injected instruction away from trying. This is Excessive Agency, LLM03 in the OWASP Top 10 for LLM Applications, 2026 edition, up from LLM06 in the 2025 edition — a re-ranking that tracks exactly this class of production incident.
“Who approved the agent’s permissions, and when were they last reviewed?”
A mechanical question with a mechanical answer, and the one most likely to come from an auditor rather than a buyer. Produce the authorisation record with an approver who is not the requester, dated before the identity was created, with the scope list attached. Then the review, with a named reviewer, a date inside the period, and an output — something added, removed or explicitly confirmed. A review with no output reads as a review that did not happen, and the cheapest way to make this credible is to point at a scope you refused.
How these land in a written questionnaire rather than a call is covered in SOC 2 and security questionnaires.
Ninety days, in the order that works
The order is not arbitrary and one dependency drives all of it: attribution cannot be retrofitted, so every day an agent runs on a human credential is a day permanently lost. That argues for migrating first and governing afterwards — except that you cannot migrate what you have not found, and you will not migrate anything at all if the sanctioned path is still slower than the unsanctioned one. Hence the sequence below, where discovery and the paved road overlap deliberately. The last column is the one that repays the most attention.
| Days | Step | Who owns it | Deliverable that must exist at the end | The wrong way to do it |
|---|---|---|---|---|
| Days 1–10 | Enumerate the non-human population | Identity administrator, with platform engineering on tokens and secrets | One list with a source column on every row, drawn from the seven discovery sources, reconciled against the agent inventory in both directions. | Running the directory export alone because it is the easy one. The population you cannot see is the population the first evidence request is about. |
| Days 5–20 | Build the paved road before you ban anything | Identity administrator, sponsored by the CISO | A self-serve request that returns a scoped, expiring agent identity inside one business day. It asks for the three-part scope, the sponsoring owner, the delegating principal where the authority is personal, and the intended lifetime. It is approved by a scope approver who is not the requester. It mints the principal and writes the register row in the same transaction. | Publishing the prohibition first. A policy against personal tokens, with the four-week queue unchanged, moves nothing — it only makes the same behaviour undocumented. |
| Days 15–35 | Open the register and back-fill what is already running | Agent owners, one row each. The governance lead runs the queue | A register row for every agent already in production, with the delegating principal asked to affirm rather than assumed to have agreed. | Back-filling from the builder’s memory. The affirmation is the control. A row the delegating principal has never seen is documentation of an assumption. |
| Days 20–45 | Re-issue the highest-consequence agent off its human credential | The agent owner, with the identity administrator | One agent — the one that moves money, deploys or publishes — running on its own principal with a scoped grant, and the human credential it used actually revoked rather than parked. | Starting with the easiest agent to migrate. The easy ones teach you nothing about the constraints, and the hard one is the reason the programme exists. |
| Days 30–60 | Wire the lifecycle hooks | HR systems and IAM jointly, with the offboarding process owner | A role change on any delegating principal triggers re-affirmation of every delegation they hold. Offboarding enumerates delegations as a blocking step. Retirement exists as a lifecycle state with a checklist. | Adding a line to the offboarding checklist that says “check for agents”. A checklist item with no enumeration behind it produces a tick, not a list. |
| Days 60–90 | Run the first reconciliation and the first stop test | Identity administrator, responder rota for the stop test | A dated reconciliation with counts from both sides and a disposition for every orphan, and one stop test with a time-to-stop and a note on what happened to in-flight work. | Treating a clean reconciliation as the goal. The first one should find things. If it finds nothing, the two extracts are probably drawn from the same source. |
What is deliberately absent from that plan is a policy document. Write one eventually, because an information security policy that is silent on non-human identity is incomplete. But a policy published before the paved road exists describes a state nobody can reach, and the first thing it produces is a population of quiet exceptions. Build the path, migrate the agent that scares you most, then write down what you did.
Frequently Asked Questions
What does delegated authority mean for an AI agent?
Why can an agent not just run under the employee’s account?
What is an on-behalf-of flow, and when should we use one?
Should every AI agent have its own identity?
What happens to an agent when the employee who set it up leaves?
Is there a SOC 2 criterion for AI agent identity?
Does ISO 42001 require agents to have their own identity?
Does the EU AI Act say anything about whose identity an agent acts under?
How long should an agent’s credentials live?
How do we prove which principal actually took an action?
Related reading: the ten questions that govern any AI agent, when a tool becomes an AI agent, the AI system and agent inventory, MCP server security governance, prompt injection once tools are connected, coding agents and production access, oversharing and permission hygiene, classifying an AI incident, and the ISO 42001 hub.
Related Reading
MCP Server Security and Governance
An MCP server is closer to a privileged integration than a browser extension. What review it deserves.
Read moreApproving MCP Tools and Handling Capability Change
Read-only search and destructive admin actions must not share a blanket approval.
Read morePrompt Injection Once Tools Are Connected
Injection stops being a content problem and becomes an action problem. The controls that reduce blast radius.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more