Governing AI agents: keep the record, expire the access
In plain words: Give every AI helper a named person who answers for it, and keys that stop working as soon as each job is done. Identity and access, explained simply
In short
- In Is an AI agent just another non-human identity? I said an agent's route decides whether governance can see it. This note is about what to do once it can.
- My claim: govern an agent as two things, not one. A record that lasts as long as the agent does, and access that lasts as long as a task. Most of what goes wrong comes from letting access live as long as the record.
- Then each programme has one job: identity governance keeps the record honest, access reviews look at what grants were used for, and privileged access management decides which grants need an administrator's controls.
- None of this works on a borrowed human login, because there is no record to hang it on.
The record
I would give the record five fields, and refuse to create an agent without them:
- Sponsor. A named person who answers for the agent's purpose and decides whether it lives on. Microsoft's Entra Agent ID separates the sponsor, "accountable for the agent's purpose and lifecycle decisions, including access reviews and agent retention", from the owner, who runs it technically, and requires at least one sponsor per agent.
- Purpose. One sentence a reviewer can test usage against. "Drafts replies to claims correspondence" can be checked; "assists the claims team" cannot.
- Route. Own credentials, delegated or borrowed.
- Risk tier. Set by what the agent can do (below).
- End date. Agents are cheap to start and nobody stops them. NIST SP 800-53 already asks for accounts to be disabled when they have expired, are no longer associated with a user, or have been inactive for a set time (AC-2(3)). An end date that the sponsor must extend makes the first of those happen by default.
The agent must outlive its sponsor's job. In Entra ID Governance, when a sponsor leaves, "sponsorship of the agent identities is automatically transferred to their manager". Whatever the tool, a leaver process that does not touch the agents a person sponsored will create orphans.
The access
Access should exist only while the agent is doing what its record says. Three mechanisms remove standing access:
- Workload identity instead of stored keys. SPIFFE gives a running workload a certificate it never has to keep: "all private keys (and corresponding certificates) are short lived, rotated frequently and automatically", and the application "need not co-deploy any authentication secrets".
- Delegated tokens for a task. Where a person is behind the work, OAuth token exchange (RFC 8693) issues a token that names the user as subject and the agent in an
actclaim. Nestedactclaims record earlier agents in a chain. But the RFC calls those earlier actors "informational only", not for access decisions, so the chain helps the log more than the gate. - Expiring entitlements. For access that cannot be a token, grant it with an end date. Entra's access packages can be assigned to an agent with an expiry; the sponsor is warned, and if they do nothing "the agent identity loses access". The Cloud Security Alliance's June 2026 research note asks for "just-in-time credentials scoped to a specific task with automatic expiration" and zero standing privilege for agents.
Reviews by use, not by calendar
Asked quarterly whether an agent still needs an entitlement, the honest answer is usually "I can't tell". The CSA note recommends reviews that are "usage-based rather than calendar-based". My reading of what that means in practice is a review triggered by an event (a new tool, a jump in volume, a sponsor change, an approaching end date) with four pieces of evidence in front of the reviewer:
- The record: sponsor, purpose, route, tier, end date.
- What the agent holds, and which of it went unused in the period.
- What it did: actions grouped by task, with the people it acted for.
- Anything outside the purpose: a new system, data it had not touched before, an error spike.
Unused access goes without discussion, and the reviewer judges only what was used, which is what AC-6(7) asks: review privileges "to validate the need for such privileges".
Which agents are privileged
An agent is privileged if it can change other identities, change configuration or code that runs in production, move money or approve transactions, read or export bulk sensitive data, or start other agents with its own authority. That list is my reading, not a standard's. Those agents get what administrators get: just-in-time elevation, approval for the riskiest actions, and privileged functions logged (AC-6(9)). In CSA's survey, 74% of practitioners agree agents often receive more access than necessary; the note says it is AI-assisted and not formally reviewed, so I read its numbers as a direction.
Logs that trace back
SP 800-53's AU-3 asks every audit record to establish the identity of "any individuals, subjects, or objects/entities associated with the event". For an agent that means four identifiers on every action: the agent's record, the person it acted for, the task, and the grant it used. NIST's NCCoE concept paper (a draft for comment) asks to "link specific AI agent and software systems actions to the identity of the non-human entity".
Two examples
An insurer's claims agent. It drafts replies to claims correspondence for a handler to approve. Route: delegated, carrying the handler's authority and its own identity. Tier: standard, because it reads and drafts but cannot pay. Grant: read access to the claim in hand, for the run. Review: triggered when someone asks to let it send replies itself, which would also move it to privileged.
A hospital's or retailer's operations agent. It restarts failed services overnight with no person behind each action. Route: its own workload identity. Tier: privileged, because it changes production. Grant: just-in-time, for the affected service, approved automatically within its runbook and by a person outside it. Logs: each change names the agent, the alert that started it and the grant.
What breaks on the borrowed login
Put the claims agent on a handler's own session and all of this disappears. There is no record, so no sponsor and no end date, and when the handler leaves the agent stops without anyone knowing it existed. The review certifies the handler's access without knowing an agent uses it. The handler's just-in-time elevation becomes the agent's. Every log line names the handler. CSA reports that 31% of organisations let agents run under a human user's identity. That is the first thing I would change.
What to do on Monday
- Refuse to create an agent without a sponsor, purpose, route, risk tier and end date.
- Add "agents I sponsor" to the leaver and mover process.
- Replace stored keys with workload identity or task tokens, and give every remaining entitlement an expiry.
- Trigger reviews on change, and show reviewers use, not only entitlements.
- Tier agents by what they can do, and give privileged ones administrator controls.
- Log agent, person, task and grant on every action.
Sources
- Microsoft, Owners, sponsors and managers in Microsoft Entra Agent ID and Governing agent identities with Microsoft Entra ID Governance (vendor documentation, 2026).
- NIST, SP 800-53 Rev. 5, controls AC-2(3), AC-6(7), AC-6(9) and AU-3 (2020, last updated August 2025).
- NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization (concept paper, draft for comment, February 2026).
- Cloud Security Alliance, Non-Human Identity Management for Agentic AI: Extending IAM Beyond Humans (research note, AI-assisted and not formally reviewed, June 2026).
- IETF, RFC 8693: OAuth 2.0 Token Exchange (2020).
- SPIFFE, SPIFFE Concepts (project documentation).
Personal work and my own view, not my employer's. Sources are public.