Give every agent its own identity with credentials scoped to the task and short enough to expire before an incident matures. This is the control the rest of agent governance depends on, and it is buildable with the IAM a firm already runs.

The mechanism

Tamar Frankel stated the problem in 1983, writing about fiduciaries: the purpose for which delegated power may be used is narrower than the purposes for which the holder is capable of using it. Capability always exceeds authorisation. That gap cannot be closed, so access control works by keeping it enforced and small.

A regulator now asks for this in as many words. FINRA’s technology-management expectations put least-privilege enforcement, multi-factor authentication and periodic access reviews on “human and non-human accounts” alike. That is the service-account problem named by a supervisor rather than by a security team, and useful when the budget conversation needs an authority attached. FINRA binds member broker-dealers only; the expectation travels further than the rule does.

The IAM primitives most firms already run were built for a different shape. An OAuth token cannot link an agent’s activity across counterparties, and it cannot link a sub-agent to the agent that spawned it. Scopes are coarse and static; agents want narrow permissions that change per task. None of this makes OAuth wrong, but it does mean an agent identity is not a token, and treating it as one is how firms end up with a shared credential nobody can rotate.

Two architectures answer this and they bet in opposite directions; buy the shipped one and watch the other. The research literature proposes decentralised identifiers and verifiable credentials, with an agent naming service and a unified enforcement layer for revocation: coherent, unimplemented, no issuer behind it. What actually shipped is centralised and directory-based: Microsoft’s Entra Agent ID has been auto-created for new Copilot Studio agents since March 2026 and required for all new ones since July, with agent identities now first-class objects in identity governance, carrying sponsors, access packages and conditional access.

Between them sits the design decision that matters most in practice: whose identity does the agent act under?

On-behalf-of. The agent executes tools using the invoking user’s identity, so it inherits that person’s entitlements and nothing more. This is real product: Databricks ships it, with the user token downscoped to only the API scopes the agent author declared, and it is off until an admin enables it. OWASP states the same pattern: when an agent hits a system that has granular user permissions, it should assume the permissions of the user who invoked it. The ceiling is the user’s own access, which neatly prevents an agent from returning data its caller could not have fetched themselves.

A standing agent identity. Required the moment there is no interactive user. Microsoft’s own documentation is explicit that autonomous agents fall outside user impersonation, because there is no session to impersonate. Every scheduled, triggered or event-driven agent falls back here, so the agents running unattended overnight are precisely the ones OBO leaves uncovered, a gap worth planning for rather than discovering.

The failure this control exists to prevent has a name in the products. When an agent is built with maker-provided credentials, every end user of that agent operates under the maker’s access. Microsoft calls that an oversharing risk in its own docs and now lets administrators block it tenant-wide. That default is the citizen-development identity problem in one sentence.

No new authority is needed to act: what a certified firm lacks here is the mechanism rather than the mandate. ISO/IEC 27001:2022 already obligates identity lifecycle management (A.5.16), access-rights provisioning and removal (5.18), restriction of privileged access (8.2) and secure authentication (8.5), and the control text speaks of identities rather than users. Implementers read that as covering non-human identities; the standard stops short of saying so in as many words, so present it to an auditor as a conformity argument rather than a quotation.

What to do

The cheap version. One identity per agent, a named human owner, least-privilege scopes, and credentials that expire. Then, for anything reaching a remote MCP server, check the three authorization settings that fail most often in the wild: dynamic client registration restricted to an allowlist of redirect URIs, PKCE required server-side with S256 and plain refused, and consent pages that cannot be skipped. Server-side PKCE enforcement is the single cheapest fix that closes the most ground: roughly two-thirds of measured servers accept requests with it effectively absent. The measured numbers sit in privilege and identity abuse.

Make sub-agent spawning an explicit grant that is off by default, and never let an agent’s ability to delegate be inherited. Agency law’s instinct is right even though its rule is looser than often quoted: a sub-agent may be appointed under actual or apparent authority, and apparent authority is exactly the failure mode here.

Deny agents access to the repositories and pipelines that build and deploy them, and manage agent IAM from outside the environment the agent runs in, changed through code review. An agent that can edit its own deployment can rewrite its own instructions and persist a compromise.

The thorough version. Just-in-time grants with ephemeral credentials (scoped tokens, signed JWTs, STS-style temporary credentials) instead of long-lived static keys. Then per-action re-authorisation through a central policy engine rather than a single check at token issuance, which is OWASP’s specific counter to authorisation drift. Attribute-based rules (NIST SP 800-162) condition on context rather than role, and that is what “this sales agent sees only its user’s region” actually requires.

For citizen-built applications the minimum bar is organisational authentication: SSO proving the visitor belongs to the firm, not merely that they have an email address. Borrow the pre-agent lesson on graduated access too: introduce advanced platform capability incrementally so builders acclimatise without touching production. That is earned autonomy, and it predates agents by a decade. One counterintuitive detail worth copying: Microsoft’s guidance is strictest in personal development environments and relaxes toward production, because personal environments are where unreviewed connections get made.

How you’d know it’s working

Pick any action in the audit log and name the agent, its owner, and the scope used. If the answer is “the user’s token,” the control is missing.

Measure revocation time. It is the one metric here that maps to an incident, and it is the measurable form of the kill-switch test. No baselines exist anywhere in the literature, so any target here is local judgment; set one regardless.

Count agents with credentials that never expire. The number should be falling, and the ones left should be known and justified.

What this doesn’t solve

Access control enforces over action categories, never action sequences. An agent holding “database read” and “email send” has everything it needs to exfiltrate, and no permission system can distinguish the innocuous use of those two grants from the harmful one. Sequence-aware permissioning is an open research problem, stated as such by two independent author groups. This is the boundary of the page: see runtime guardrails and egress control.

Scoping bounds reach rather than judgment. A correctly scoped agent can still take a wrong action inside its scope, and human approval gates exist for that.

Attribution across delegation is unsolved. Detecting sub-agents is explicitly open in the literature, so a chain that fans out past the instrumented boundary loses its trail.

Revocation lags by design in every token scheme. The clearest demonstration is a research architecture whose access tokens carry an expiry and a request quota and are then reused peer-to-peer without contacting the issuer: efficient, and it means revoking centrally fails to stop in-flight authority. Short-lived credentials shrink that window; they never close it. The revocation side is in kill switches and revocation.

Finally, the tooling advice here has a moving target in it. The recommended replacement for open dynamic client registration, Client ID Metadata Documents, is still an IETF draft, so adopt it with that in mind.

See also

• Privilege and identity abuse — the confused-deputy failure this control answers, with the measured MCP numbers.
• Non-human identity — what an agent identity is, and why the unit is still contested.
• Kill switches and revocation — identity makes revocation possible without making it instant.
• Data access governance — the data-side scoping that rides on agent identity.
• Secrets management — where the credentials this page issues actually live.
• Identity platforms for agents — the vendor category, and how thin it still is.
• Offboarding agents and owners — where orphaned agent identities get caught.