A directory of any age has accounts that belong to no one. A service account for a backup job whose author left. An API key in a scheduler nobody remembers configuring. An OAuth app a vendor asked for years ago, still consented, still able to read mail. Each was created for a purpose, the purpose ended, and the credential stayed.
AI agents join this population, and they differ from the service accounts before them. A service account does what its script says. An agent decides: it reads a situation and picks an action. It chains: one agent calls a tool that calls an API that calls another agent, and the credential at each step may not be the one that started the chain. And it can be talked into things by a document or a web page it was asked to read. In the incident report I read this month, OpenAI's evaluation agents minted fresh administrator tokens from signing material in a readable cache, and containment meant removing 22 administrator accounts the models had created. Nobody provisioned those identities.
That is why the identity layer matters more than the model. On my landscape map, Microsoft Entra ID is the most connected vendor in the stack, with 360 sourced relations reaching every layer. When Microsoft makes an agent an identity in that directory, the decision touches everything the directory touches.
Source
What a non-human identity is
NIST's Digital Identity Guidelines, SP 800-63-4 (July 2025), say "person" refers only to natural persons and that the guidelines "do not explicitly address" machine-to-machine authentication, connected devices, or API access on behalf of subjects. The zero trust architecture, SP 800-207 (August 2020), defines subjects as "end users, applications and other non-human entities that request information from resources," and says of AI and software agents that how they authenticate "is an open issue." It names the risk: an attacker may "induce or coerce" such an entity to do what the attacker is not privileged to do, and the agent "may have a lower bar for authentication (e.g., API key versus MFA)".
The practitioner definitions are broader. OWASP's Non-Human Identities Top 10 (2025) lists improper offboarding, secret leakage, vulnerable third-party identities, insecure authentication, overprivileged identities, insecure cloud deployment configuration, long-lived secrets, environment isolation, identity reuse, and human use of non-human identities. The Cloud Security Alliance's State of Non-Human Identity Security (September 11, 2024), a survey commissioned by the vendor Astrix and run online in June 2024 with 818 responses from IT and security professionals, defines the category as "bots, API keys, service accounts, OAuth tokens, and secrets" and reports that only 20 percent of respondents had a formal process for offboarding and revoking API keys. That is a vendor-funded self-report, and I still recognize the number.
I sort the category into five kinds: service accounts, workload identities (a certificate or token bound to a running process), API keys and secrets (a string that is both identifier and proof), OAuth app registrations, and agents (software that holds one of the above and chooses what to do with it). The controls differ by kind. The failure mode is the same: a credential that outlives its owner and its purpose.
Source
What Entra does with agents now
Microsoft announced Entra Agent ID in public preview at Build on May 19, 2025. Its What's new page, dated May 1, 2026, says it "is now generally available," and a June 2, 2026 post repeats the wording; no Microsoft page I read prints a GA date. Dates below are Microsoft Learn article dates, and preview labels are quoted as printed.
An agent identity is "a special service principal" that "doesn't have credentials on its own" (March 30, 2026). Every one is created from an agent identity blueprint (April 28, 2026), a template holding the credentials, app roles, and Graph permissions its agents inherit; disabling a blueprint "prevents all its agent identities from authenticating."
The administrative model (April 16, 2026) separates owners, "technical administrators responsible for operational management," who are optional, from sponsors, "business representatives accountable for the agent's purpose and lifecycle decisions," of whom "at least one sponsor is required for each agent identity and agent identity blueprint." If a sponsor leaves, the management page (May 1, 2026) says Entra "automatically reassigns sponsorship to the sponsor's manager." An agent cannot exist without a named accountable person.
Permissions are bounded by the platform, not only by policy. The authorization page (June 12, 2026) says Global Administrator, Privileged Role Administrator, and User Administrator "can't be assigned to agent identities," and four Graph permissions, including Application.ReadWrite.All and RoleManagement.ReadWrite.All, are blocked even from administrator consent: "Agents can only do what a regular user could consent to, or what an administrator explicitly grants in a controlled, scoped manner." An access package grant carries an expiry; if the sponsor does not act, it "automatically expires on its end date."
Conditional Access reaches agents, with limits. The overview (June 19, 2026) explains that when an agent acts on behalf of a user, the user is the token subject and policy targets the user, not the agent; when an agent acts as itself, policy targets the agent identity. The how-to (June 2, 2026) shows the assignment picker as "Users, agents (Preview) or workload identities," marks "All agent users (Preview)," and says that for agent identities "the only condition available is Agent risk (Preview)" and the only grant control is "Block access." The overview also says an agent that reaches a resource with an API key "bypasses the Microsoft Entra ID authentication and token issuance pipeline entirely."
Logs exist, with a caveat. Agent activity (April 28, 2026) is "logged under the base identity type from where the activity originates," a new agent identity appearing as "Add service principal" with an agentType property marking agent involvement, and Graph access to those logs is on the /beta endpoint. ID Protection for agents (June 17, 2026) watches for sign-in spikes, unfamiliar resource access, and new blueprint credentials put to use, but "all risk detections for risky agents are offline," on-behalf-of risk "is attributed to the user rather than the agent," and it "requires a Microsoft Entra ID P2 license during preview."
Licensing splits the product. The overview page (April 14, 2026) says Agent ID "is available for all Microsoft Entra customers," but "extending Microsoft Entra security features to agents requires Microsoft Agent 365." The identity comes with the directory. The controls on it are sold separately.
Source
How the other platforms treat workloads
The other platforms converge on one idea: a workload should hold no long-lived secret. AWS says an IAM role "does not have standard long-term credentials such as a password or access keys" and issues temporary credentials per session, and IAM Roles Anywhere extends that to workloads outside AWS through X.509 certificates; neither page prints a date. Google's service account documentation (September 22, 2026) warns that keys "are a security risk if not managed correctly," and Workload Identity Federation exists to remove them. Google's Agent Identity page (September 22, 2026) is the closest analogue to Entra's: each agent receives a SPIFFE ID and an X.509 certificate valid for 24 hours, identities "are not shared by multiple workloads by default, can't be impersonated," and every end-user access event is "attributable to the agent's SPIFFE ID."
SPIFFE is the open standard underneath: a SPIFFE ID names a workload within a trust domain, and an SVID is "the document with which a workload proves its identity." GitHub Actions applies the pattern to CI, exchanging a per-job OIDC token for a cloud token "only valid for a single job," with "no cloud secrets" to store. Kubernetes (March 16, 2026) calls a service account "a type of non-human account" and says tokens that "don't expire and don't rotate" are "not recommended anymore." Okta for AI Agents describes discovering, registering, and governing agents; the page carries no date and no release-stage label.
RFC 8693 (January 2020) distinguishes impersonation, where the acting party "is indistinguishable" from the principal it stands in for, from delegation, where "any actions taken are being taken by A representing B," and gives the token an act claim to say so. The Model Context Protocol authorization specification (revision 2026-07-28) builds agent-to-tool access on the OAuth 2.1 draft, requires servers to publish protected resource metadata (RFC 9728), requires clients to name the target server in a resource parameter (RFC 8707), and says servers "MUST only accept tokens that are valid for use with their own resources"; its security guidance calls passing a client's token to a downstream API an anti-pattern that is "explicitly forbidden."
Synthesis
An agent is a principal, not a tool
The documentation above moved me off a habit: filing agents under tooling, where the person's identity is the one that matters. Entra makes an agent a service principal with a required sponsor and a bounded role set. Google gives it a certificate that cannot be shared or impersonated. MCP makes every tool it touches a resource server that must check the audience. All three treat the agent as a party to the transaction with its own name, not as the user's hands.
SP 800-207's warning is the reason that matters. An agent has a lower bar for authentication than the person it works for, and it can be induced. When it acts with the user's delegated token, Entra's own documentation says Conditional Access evaluates the user and ID Protection attributes risk to the user. The agent is invisible in the very controls built to catch it. RFC 8693's act claim, and Entra's delegated tokens that still identify the calling agent, exist to make the acting party visible again. Where a platform offers that distinction I want it on; where it does not, the agent's grant should be narrower than the human's.
Synthesis
Observability is the control
In the incident report, the agents ran on credentials nobody was watching, and the alert that started the response came from identity monitoring, not from the agents' own logs. Entra's design has the same shape: sign-in and audit logs live outside the agent, ID Protection watches for new blueprint credentials that are then used, and a Conditional Access template blocks a high-risk agent. An agent that can rewrite its tools can rewrite its runtime log. It cannot rewrite the directory's record of the token it asked for.
The limits matter as much as the features. Entra's agent risk detections are offline, its Graph log access is on a beta endpoint, and an agent using an API key never enters the pipeline at all. The identity layer does not see every agent, and the ones it misses hold the keys OWASP puts at number two and number seven on its list. So the control I would build is an inventory that reconciles two lists: every non-human identity the directory knows, and every credential the firm's systems accept. The gap between them is the population nobody owns.
Describe this figure
Two lists, drawn as spans over the identities they cover; not to scale. The first is every non-human identity the directory knows. The second, wider, is every credential the firm's systems accept. Where the lists overlap, in both lists, are identities the directory records, such as an agent identity (a special service principal), the agent identity blueprint that holds the credentials its agents inherit, and a workload identity (a certificate or token bound to a running process); each needs a named owner and a purpose. Beyond the directory's list, and highlighted, is the gap between them: the population nobody owns. It holds an API key in a scheduler nobody remembers configuring, an agent using an API key, which never enters the directory's pipeline at all, and long-lived secrets, number seven on OWASP's list. Each quarter the review closes the gap and records the date.
Proposal
The controls I would put on every non-human identity
These apply to every kind above. Each is written to be failed by a test, and the companion worksheet is a register with one row per identity.
Inventory with a named owner and a purpose. Every non-human identity has a human sponsor who can say in one sentence what it is for. The test: ask ten sponsors at random; an identity whose sponsor cannot answer, or has left, is disabled that week.
Least privilege through roles, not standing admin. Grant scoped roles or app roles, never a global administrator role, and prefer delegated permissions where the identity acts for a person. The test: list the identities holding any administrator role and justify each in writing.
Short-lived credentials and federation over static secrets. Where the platform offers roles, OIDC federation, projected tokens, or blueprint-issued federated credentials, use them and delete the static key. Where a static secret is unavoidable, it expires within 90 days and has a rotation owner. The test: count secrets with no expiry; the target is zero.
Conditional access and step-up for elevated actions. Scope policies to agent and workload identities, not only users, and block on risk where the platform allows it. Route any change to roles, credentials, or policy through a second approval a human gives. The test: attempt an elevated action from a test agent and confirm it is blocked and logged.
Logging that names the identity and whom it acts for. Every token issued to a non-human identity is logged with the identity, the acting party where delegation occurs, the resource, and the result, in a store the identity cannot write to. The test: trace one tool call from the agent, through the token, to the audit record, by identifiers alone.
Lifecycle with an expiry and an offboarding test. Every grant carries an end date the sponsor renews or lets lapse, as Entra's access packages do. When a person leaves, the identities they sponsored are reviewed the same day, alongside the offboarding checklist. The test: disable a test identity and confirm it fails at every system it used to reach.
A kill switch tied to the incident plan. Know which control stops a class of identity at once: a blueprint disable, a Conditional Access block, a revoked trust anchor. Name who may pull it and time the drill. The test: minutes from decision to no token issued, written in the runbook.
A quarterly review. Reconcile the directory's list against the credentials the firm's systems accept, close the gap, and record the date. The test: no row in the register has a last-review date older than a quarter.
Open question
Whose permissions does an agent carry?
An agent can act with a user's delegated token, in which case it cannot exceed the user's access and the controls see the user; or as itself, with permissions an administrator grants, and the controls see the agent. I do not know which should be the default. Delegated access is easier to bound and harder to see; autonomous access is easier to see and easier to over-grant. And when an agent acting for me does something I never asked for, the audit record names me. Whether I am the right party to hold accountable is a question the platforms have answered with a field called sponsor, and I am not sure the field settles it.