An AI agent that can read email, update a calendar, edit files, or call business software needs permission to act. The fastest setup is often the most dangerous: give the agent a person’s login, paste in a long-lived API key, and let it operate as if it were the user. That may make a demonstration work, but it also erases an important boundary. A service can no longer reliably tell whether the person acted, the agent acted, or someone stole the shared credential.
In August 2026, the US National Institute of Standards and Technology argued that agents should be treated as first-class digital entities with their own identifiers, credentials, and entitlements. This is less glamorous than a new reasoning benchmark, but it may matter more to everyday adoption. Agents that take actions need an identity and authorization layer designed for software moving at machine speed.
Borrowing a user’s login destroys accountability
Authentication answers who or what is making a request. Authorization answers what that identity may do. Delegation connects the two by recording that a person or organization allowed an agent to perform a defined task on its behalf.
If an agent simply uses a human account, all three ideas collapse into one shared login. Audit logs attribute its actions to the person. Revoking the agent may require changing the person’s credential. Permission settings cannot easily distinguish between actions the user may take directly and the smaller set the agent actually needs.
NIST’s August 2026 identity guidance warns that credential sharing creates security, privacy, legal, and non-repudiation problems. Its preferred direction is a unique agent identity whose rights are bound to the user or system that operates it. The audit trail can then say that a particular agent acted under a particular delegation, rather than pretending the human clicked every button.
An agent identity is not a second human account
Creating a separate username for an agent is a start, not a complete architecture. The identity should describe a software workload and its operating context: who owns it, which service runs it, which version or deployment is active, what task it was assigned, and when its authority expires. A short-lived agent should not inherit a credential that remains valid for months.
The same distinction matters when agents call other agents. Our guide to AI agent protocols explains how systems exchange tools and messages. Interoperability does not establish permission. Every hop needs a verifiable chain showing which identity delegated which authority, resource, and purpose.
NIST launched an AI Agent Standards Initiative in 2026 around secure interoperability, identity research, open protocols, and evaluation. The related NCCoE project is reviewing how existing identity standards can be applied to enterprise agents. The effort is still developing, so product claims about a universal agent identity standard deserve caution.
Long-lived bearer tokens are a poor default
Many integrations use bearer tokens: whoever possesses the token can present it to an API. That simplicity becomes risky when an agent moves across prompts, tools, plug-ins, logs, and network services. A token accidentally written to a configuration file or transcript may be reusable by anyone who finds it.
The problem is magnified by lifespan and scope. A key that can read and delete every file is far more dangerous than a token that can read one folder for ten minutes. An agent may also explore several routes to complete a broad instruction, exposing credentials to more components than its designer expected.
The IETF’s OAuth 2.0 security best practice recommends restricting an access token to the minimum privileges required, limiting it to intended resource servers, and binding it to a particular sender where possible. These are general web security principles, not agent-specific inventions. Agentic systems make them more urgent because one vague instruction can trigger many rapid requests.
Useful authorization describes the task, not just the role
A coarse role such as “editor” or “administrator” is often wider than an automated task requires. Better authorization can name the permitted resource and action: create a draft but do not publish it; read invoices from one account but do not change payment details; schedule a meeting inside working hours but do not invite external guests.
Time, spending limits, data sensitivity, destination, and required review can all be policy inputs. Rights should narrow as a task is delegated through a chain, rather than expanding at each step. When the task ends, its temporary authority should end too. This approach reduces damage from model errors, prompt injection, a compromised tool, or an agent that chooses an unexpected path.
Authorization cannot replace application safety. File services still need recovery, payment systems need fraud controls, and production infrastructure needs change review. Identity establishes who is asking; policy and resilient design determine acceptable consequences.
Proof of possession can limit stolen-token reuse
A sender-constrained token is usable only when the client can also prove control of associated key material. Stealing the token alone is therefore less useful. The IETF’s DPoP standard defines an application-level proof-of-possession mechanism for OAuth tokens. Each relevant request carries a signed proof tied to the client’s key.
This is not a magic shield. If an attacker controls the agent’s execution environment and can use both the token and private key, the protection may fail. Key storage, software isolation, token lifetime, logging, and resource-server checks still matter. Confidential computing can protect some data while it is being processed, but as our confidential AI explainer notes, no single mechanism secures the entire pipeline.
Human approval can become another weak point
Requiring approval before a consequential action is sensible, but asking too often creates consent fatigue. People learn to click allow just to keep work moving, much as repeated authentication prompts can condition users to approve a malicious request. NIST specifically highlights this risk for agents that repeatedly ask for new tools or data.
An approval should therefore present a meaningful transaction: what will happen, which data and destination are involved, how much authority is being granted, and whether the action can be reversed. Routine low-risk work can operate within a preapproved policy. Irreversible, unusual, or high-impact actions can trigger a focused checkpoint. The goal is not maximum prompting; it is useful human control.
What buyers and administrators should look for
A serious agent platform should make separate identities visible in administration and audit tools. It should support short-lived credentials, narrow scopes, explicit resource audiences, rapid revocation, secret-free logs, and a record of the human or service that delegated authority. Administrators should be able to disable one agent without disabling its owner.
Ask whether permissions are checked only when a task begins or again when the agent switches tools and destinations. Check how sub-agents inherit rights, where keys are stored, what happens after a failed action, and whether logs distinguish proposed, approved, attempted, and completed operations. A polished chat interface says little about these controls.
NIST’s 2026 analysis of public comments on agent security found broad agreement that established cybersecurity practices remain relevant but need adaptation for agent systems. That is a useful frame: most building blocks already exist, yet their combination and operational scale are new.
Limitations and what to watch next
Agent identity will not make model outputs reliable, stop every prompt injection, or prove that an action matches a user’s true intent. Standards are still evolving, and consumer services face an especially difficult problem when an outside agent arrives with credentials copied from a user. Cross-company delegation, revocation, liability, and privacy remain unsettled.
The next meaningful signals will be interoperable implementations, not new terminology. Watch for NIST’s practical guidance, tests that compare agent security behavior, standard ways to pass reduced authority through multi-agent chains, and service providers that accept agent-specific credentials without encouraging password sharing. Products should also demonstrate that revocation propagates quickly and that audit records survive across tool boundaries.
An AI agent should be able to act for you without becoming indistinguishable from you. Giving it a separate identity, limited authority, and a traceable delegation chain is the foundation for that difference.
Featured image: AI-generated editorial illustration of agent identity and authorization controls, not a screenshot of a specific commercial system.
Primary sources
- NIST: Why agentic AI needs a strong identity foundation
- NIST: AI Agent Standards Initiative
- NCCoE: Software and AI agent identity and authorization
- IETF RFC 9700: Best Current Practice for OAuth 2.0 Security
- IETF RFC 9449: OAuth 2.0 Demonstrating Proof of Possession
- NIST: Analysis of responses on AI agent security
Leave a Reply