On Thursday 2 July 2026, Couchbase announced general availability of its AI Data Plane: persistent agent memory, an agent catalogue and an enterprise-supported MCP server, running as one architecture across Capella, self-managed clusters and the edge. The same day IBM introduced an Agentic Control Plane in watsonx Orchestrate, with policy management for runtime rules, credential health monitoring and an overview of which agents can reach which integrations. On Friday 3 July, Zenphi, an automation vendor for Google Workspace, released a Claude Text Agent that runs Anthropic’s models as a configured step inside Workspace workflows, with every run scoped, logged and metered by token. Three launches in two days, each selling the word governed. Gartner’s press release of 26 August 2025 predicted that 40 percent of enterprise applications would be integrated with task-specific agents by the end of 2026, up from less than 5 percent; the first week of July suggests the vendors intend to make the number.
Read the three announcements for the one control that matters most and it is absent. Couchbase gives the agent memory. IBM gives it a dashboard and a policy. Zenphi gives it a log. None says who the agent is in your directory, who owns it, what it is entitled to, or how it is retired. Identity is the agent control no vendor ships across vendors, for a structural reason: your directory is yours, and an agent built in one platform is not a principal in another unless you make it one. That work falls to the platform team, and it is not new work. It is the discipline the identity team already applies to people.
A prompt is not an identity
Most agents in production today are identified by their instructions. A system prompt says that the model is the reconciliation assistant for the finance team, that it may read the ledger and must not post entries, and its authors feel they have defined who the agent is. They have defined what they would like it to be. A prompt is a request to a model; an identity is a fact about a system. The difference is five questions an auditor asks of a person and a prompt cannot answer: can a third party verify it, can it be revoked, can it be listed with every other principal of its kind, can it be attached to a record of what was done, and can entitlements be assigned to it and removed without rewriting it?
OWASP’s Top 10 for Agentic Applications, released on 9 December 2025 with more than a hundred contributors, ranks Identity and Privilege Abuse third of its ten risks. Microsoft’s mapping of those risks, published on 30 March 2026, describes it as “exploiting delegated trust, inherited credentials, or role chains,” which is what a prompt-identified agent on a shared API key makes possible. The key in the environment file is the textbook case: an identity with no owner, no expiry and no attribution. Even the policy engine in Microsoft’s Agent Governance Toolkit, which decides in under 0.1 milliseconds at the 99th percentile whether an action is allowed, needs a stable subject to decide about, and a prompt is edited, forked and pasted.
What a principal is
A principal is a directory object with five properties: an owner, a lifecycle, credentials, entitlements and an audit trail. People and service accounts have had all five for twenty years. In the past fourteen months three different answers have shipped for agents.
The directory answer. Microsoft announced Entra Agent ID in preview at Build on 19 May 2025 and moved the platform to general availability in April 2026. The design has three object types: a blueprint, which is a reusable template; an agent identity, which is the instance; and an agent user account, for agents that need user-oriented services. Each identity and blueprint must have at least one sponsor at creation, and sponsors are business people rather than engineers: they can disable or soft-delete the agent but cannot re-enable it or touch its credentials. Owners, who are optional, are the technical administrators and can do both. That separation is the most important idea in the product: the person entitled to say the agent should not exist is not the person who can change what it can do.
The workload answer. Amazon Bedrock AgentCore went generally available on 13 October 2025, and AgentCore Identity treats an agent as a workload identity with agent-specific attributes, held in a directory the documentation compares to a Cognito user pool. Every agent gets an ARN with a hierarchical path. The object carries a name, the ARN, OAuth return URLs and timestamps; it does not carry a sponsor, a review date or a reason to exist. Those fields, and the mapping between the AWS object and your directory, are the first things a platform team has to build.
The cryptographic answer. Microsoft open-sourced its Agent Governance Toolkit on 2 April 2026 under the MIT licence. Its Agent Mesh gives each agent a decentralised identifier with Ed25519 keys, an inter-agent trust protocol, and a trust score from 0 to 1,000 in five behavioural tiers that moves with conduct. It can be verified and signed against, but it is not an identity in the sense a directory means: nothing in a DID says who in the organisation sponsors the agent. The toolkit governs what agents do to each other and to tools, not who is accountable for them.
An enterprise will have all three at once. The platform decision is which one is authoritative, and my answer is the directory, because it is the only one with a human attached. Figure 1 is drawn on that assumption.
Credentials that expire with the task
The second property of a principal is that it holds credentials, and what separates a governed agent from an ungoverned one is what those credentials look like. The ungoverned pattern is a long-lived key, shared by every copy of the agent. The governed pattern is a credential issued for one task, scoped to what the task needs, expiring when the task does.
SPIFFE is the clearest statement of the pattern, and it predates agents. A workload connects to a local Workload API and receives its SPIFFE ID, a private key, a short-lived certificate and a trust bundle, without holding any secret beforehand; the specification says keys are “short lived, rotated frequently and automatically.” In SPIRE, the reference implementation, the default lifetime of an X.509 identity document is one hour and of a JWT document five minutes. A post from Riptides on 20 April 2026 lays out the limits: SPIRE needs each workload registered before it can be attested, which is awkward for sub-agents spawned at runtime, and a workload identity says what the agent is, not whose authority it carries. Microsoft’s identity-spiffe repository, created on 26 May 2026, is a research prototype that joins the two worlds: on every call a Go sidecar checks mutual TLS against the SPIFFE certificate, a role rule, an OAuth token, and a Conditional-Access-style policy evaluated against live Entra attributes. Its README says it is “not to be run unchanged as production,” but the pattern is right: a workload identity for the transport and a directory identity for the authority.
AWS has productised the credential side. AgentCore Identity keeps OAuth tokens, client credentials and API keys in a token vault encrypted with KMS keys and releases them only to an agent that presents proof of its workload identity. It supports the client-credentials grant for an agent acting as itself and the authorisation-code grant for an agent acting for a user. On 30 April 2026 AWS made on-behalf-of token exchange generally available in fourteen Regions: an agent exchanges the token it holds for a scoped-down token carrying both the user’s identity and its own. On 1 June 2026 credential providers gained the ability to reference secrets the customer already manages in Secrets Manager, under the customer’s own keys and rotation schedules, which matters because a finance team’s secrets are governed by finance, not by the agent platform.
The rule we apply is that no credential outlives the task that requested it; a task that runs for a day renews rather than extends. The consequence is what makes identity the enterprise kill switch. A principal disabled in the directory cannot obtain its next credential, and within an hour, or five minutes, it has nothing. That stop works for an agent on a vendor’s cloud that your runtime cannot reach, and it is the one I would drill first.
Joiner, mover, leaver
The third property is a lifecycle, and the human-resources vocabulary fits. A joiner has a requisition, a sponsor and a start date. A mover changes role and loses the old role’s access. A leaver is disabled on the day, revoked, and deleted after a retention period. An agent needs all three, and two are routinely skipped.
Joiner. Who sponsors it? Entra’s answer is that nobody may create an agent identity without naming a sponsor, and that a person making a delegated creation request becomes the sponsor by default if they name nobody else. I would add three fields the directory does not force: the purpose in one sentence, the review date, and the budget line, because an agent with no cost centre is an agent nobody will retire.
Mover. The transition that catches organisations out is not the agent moving but its sponsor. Microsoft’s answer went generally available in May 2026: a lifecycle workflow that, when a sponsor leaves, transfers sponsorship of their agent identities to their manager and notifies co-sponsors in advance. Before it existed, orphaned agents were the norm, and in every other platform they still are. An agent can also move in its own right, when the process it serves changes; that is a re-scope, which is why the review arrow in Figure 1 returns to scope, not to run.
Leaver. Retirement is not the same as switching the agent off; a disabled principal with live tokens is not retired until they expire, which is another argument for short lifetimes. The full sequence is: the sponsor disables; the owner revokes credentials and removes the access packages; the memory the agent accumulated is archived for the audit retention period, since it is evidence; the object is soft-deleted; and after retention it is purged. What no product does is tell you the agent should be retired. That signal comes from the review.
Delegation chains
The fourth property is entitlements, and for agents the hard part is delegation. An agent acting for a user holds some of the user’s authority; an agent calling another agent passes some of its own. Who authorised what has to be recorded at every hop, or the audit trail breaks exactly where an incident would begin.
An agent acting for a user. The clean form has two identities in one token: the user as subject, the agent as actor. AWS’s on-behalf-of exchange produces precisely that. Entra ships separate Conditional Access templates for autonomous agents, which have no user context, and for on-behalf-of agents, which do. The rule is that an on-behalf-of agent may never hold more than the user it acts for, and the token should say so: entitlement shrinks along the chain, which is the only direction it should move.
An agent acting for an agent. This is where the Governance Toolkit does its real work: its inter-agent trust protocol signs agent-to-agent calls with the caller’s Ed25519 key, and the trust score is an input to whether a call is accepted. OWASP lists Insecure Inter-Agent Communication as its seventh risk, and the scenario under the third is the confused deputy: a low-privilege agent relays a plausible instruction to a high-privilege one, which carries it out on its own authority. The defence is the same as for people. The high-privilege agent acts on the authority of the original subject, which it can only do if that subject is in the token it received.
Recording who authorised what. Three authorisations sit behind any delegated action, and the log should name each: the standing one, the sponsor approving the access package; the runtime one, the user’s consent for a three-legged flow or the policy decision for a two-legged one; and the hop, the policy that allowed agent A to call agent B. A log with the action and the agent’s name records what happened. A log with all three records why it was allowed, and only that kind can be reviewed.
Attribution in logs
The fifth property is the audit trail, and the failure here is specific: an action taken by an agent is logged as an action taken by its owner. The quickest way to get an agent working is to give it a token the developer obtained for themselves, or to let it drive a session the user is already signed into, and every downstream system then records the human. In an access review, the controller appears to have queried the ledger four hundred times at three in the morning. Nothing can correct that afterwards, because the systems that wrote the logs had nothing else to write.
The fix is structural, and it is why the agent user account exists in Entra: an agent that must reach user-oriented services gets its own account, with its own sign-in logs, and from June 2026, in preview, its own Conditional Access treatment, including policies keyed on agent risk. AgentCore logs every identity operation with its context, and the on-behalf-of token lets the resource see both the user and the agent, so it can log both. The standard I hold the platform to is that every log line carries the actor, which is the agent principal; the subject, which is the user if there is one; the task identifier; and enough to derive the sponsor. The test is practical: pick a random agent action from last week and reconstruct, in five minutes, who authorised it and under what entitlement. If the answer is a person who was asleep, the logs are wrong.
What the standards and products cover, and what they leave to you
None of the products above is wrong, and none is sufficient, and the useful exercise is to say which part of the lifecycle each covers. The Governance Toolkit covers enforcement and agent-to-agent trust: policy in YAML, Rego or Cedar, DIDs with Ed25519 keys, execution rings modelled on CPU privilege levels, a kill switch, SLOs and error budgets, and evidence collection against all ten OWASP agentic risks. It leaves you the directory, the sponsor and the audit retention. Entra Agent ID covers the directory, with blueprints, required sponsors, access packages, sponsor succession and Conditional Access, and documents sidecar and federation patterns for agents on AWS Bedrock and Google Cloud; it leaves you the question of which object is authoritative when the same agent exists in another vendor’s directory. AgentCore Identity covers credentials, consent and token exchange; it leaves you ownership, review and retirement. SPIFFE and SPIRE cover workload identity and rotation; they leave you registration of dynamic agents and all delegated user authority. Table 1 puts these against the onboarding steps.
A worked onboarding: the finance reconciliation agent
Here is the process applied to one agent, the kind most companies will build this year: it reads the overnight bank statement, matches it against the ledger, writes mismatches to an exceptions queue, and posts nothing.
Directory. The financial controller is the sponsor; a platform engineer is the owner. The owner creates an agent identity from a blueprint called finance-reconciler-readonly, which fixes the authentication method and the allowed resources, and the object carries the purpose, a review date ninety days out and the finance cost centre. Because the agent runs on AWS, a workload identity is created in the finance path of the AgentCore directory and the Entra object records its ARN.
Entitlements. Three access packages, each approved by the controller: read on the bank feed, read on the ledger API, write on one exceptions queue. There is no package for the payments system, so there is nothing to deny. The packages are assigned to the autonomous identity, since no user is in the loop; if the controller later wants to question it interactively, that is an on-behalf-of assignment with its own package and template.
Credentials. The agent holds no secret. At each run it attests to the runtime and receives a workload credential with a one-hour life, which it exchanges for a scoped token for the ledger API. The bank feed needs an API key, so the key lives in finance’s Secrets Manager under finance’s KMS key and rotation schedule, referenced by an AgentCore credential provider and released only to this workload identity. The owner never sees it. If the directory object is disabled, the next attestation fails and the agent has nothing within the hour.
Budget. A token cap per run and per day, and a cap on sub-tasks, set in the same ticket as the entitlements. At the cap the identity is disabled, not warned.
Review. At ninety days the controller receives an access review listing the three packages, a sample of the agent’s actions reconstructed from the logs with actor, subject and task on each line, the spend against budget, and the trust score. She attests, narrows, or declines. If she has moved roles by then, the lifecycle workflow has already made her successor the sponsor and told them the review is due.
Retirement. The ERP migration absorbs reconciliation a year later. The controller disables the identity. The owner revokes the credential providers, removes the three packages, and exports the agent’s memory store to the finance archive for the retention period the audit committee sets. The object is soft-deleted, deletion removes its credentials and assignments, and it is purged when retention ends. An incident review, had there been one, would have found a sponsor, three packages, a budget and a log that names the agent, not the controller.
Recommendations
- Make the directory authoritative, and make it yours. Every agent, in every vendor’s platform, is a principal in one directory you control, with the vendor’s identity mapped to it.
- Require a sponsor who is not an engineer. Copy Entra’s rule where Entra is absent: no agent without a named business owner, a one-sentence purpose, a review date and a cost centre.
- Issue credentials per task and let them expire. No shared keys, no standing secrets in agent code, and the business’s secrets in the business’s vault.
- Carry the subject through every hop. An agent acting for a user holds a token that names both; an agent calling an agent passes the original subject on. Entitlement only shrinks along a chain.
- Log the actor, never the owner. Actor, subject, task and sponsor on every line. Run the five-minute reconstruction test monthly on a random action.
- Automate sponsor succession. When the sponsor leaves, the agent gets a new one that day, by workflow, not by discovery during an incident.
- Write the retirement before the first run. Disable, revoke, remove, archive, soft-delete, purge. An agent with no exit is a contractor with no end date.
- Drill revocation as the kill switch. Disable a principal on purpose and time how long until it can do nothing. That number, not the vendor’s dashboard, is your stop.
The vendors will keep shipping control planes, data planes and governed steps. What they cannot ship is the fact that the reconciliation agent belongs to the controller, is entitled to three things, and will be gone in a year. That fact lives in your directory or nowhere. Gartner’s 40 percent is arriving on schedule; the identity practice to receive it is the one part of the stack a platform team cannot buy.
