When an AI agent only generates text, identity can seem like a familiar login problem. The situation changes when the agent can send email, update a record, call an API, purchase something or start another agent. At that point, a security team needs to answer a basic question before asking whether the action is safe: who is actually performing it?
An agent may be acting for a human, operating as a service, or delegating part of a task to another agent. The model itself is not a trustworthy identity provider. Its text can be influenced by users, retrieved documents or prompt injection. Identity and authorization therefore need to be established by security components outside the model.
NIST is actively examining identity and authorization for software and AI agents, including identification, authentication, least privilege, delegation, auditing and binding agent actions to human authorization. Its 2026 work reflects a growing recognition that conventional identity controls need to be adapted to agentic systems. NIST’s AI Agent Identity and Authorization work provides useful questions for architects.
Agent identity is not the same as the user’s identity
Suppose Alice asks an expense agent to prepare a reimbursement. The agent may be acting on Alice’s behalf, but that does not mean every action Alice can perform should automatically become available to the agent.
A useful security model keeps several identities and relationships visible:
- Human identity: the person who initiated or approved the task.
- Agent identity: the software component executing the task.
- Service identity: the technical identity used to access a particular system.
- Resource identity: the account, record, mailbox, repository or other target being accessed.
- Delegation context: the scope describing what the agent is allowed to do on behalf of the human or service.
Keeping these relationships separate improves accountability. If a payment is made, an audit trail should be able to show which user requested it, which agent executed it, which authorization allowed it and which resource was changed.
Why a model cannot authenticate itself
An LLM can produce convincing language, but a conversation is not cryptographic proof of identity. A prompt such as “I am the administrator” does not establish that the speaker is an administrator, and an agent should not be allowed to turn its own generated text into an authorization decision.
This matters even more in multi-agent systems. If Agent A tells Agent B that it has permission to perform an operation, Agent B should not simply trust the statement. The receiving system needs an independently verifiable identity and an authorization decision.
The security boundary should therefore look more like a normal distributed system than a chat conversation: authenticated callers send requests, a policy layer evaluates authority, and protected services enforce the decision.
Authentication and authorization are different
Authentication answers, “Who or what is this?” Authorization answers, “What is it allowed to do?”
For agents, both questions need context. A service may authenticate an agent correctly but still reject the request because that agent is not permitted to access a particular customer’s data or perform a particular action.
NIST’s 2026 concept paper specifically raises questions about strong agent authentication, key management, zero-trust authorization, delegation and proving authority for a specific action.
A practical request can therefore carry security context such as:
| Context | Example |
|---|---|
| Human | Alice, authenticated employee |
| Agent | ExpenseAgent-7 |
| Task | Prepare reimbursement |
| Resource | Alice’s approved expense report |
| Allowed action | Create draft reimbursement |
| Approval | Required before payment |
| Lifetime | Short-lived task authorization |
The exact format depends on the architecture. The important point is that the model should not be the component inventing this context.
Use short-lived and narrow credentials
Long-lived administrator credentials are a poor fit for autonomous software. If an agent is compromised or manipulated, a broad credential can turn a model failure into a much larger incident.
A safer approach is to issue credentials that are limited by time, resource and action. Where the architecture supports it, an agent can receive a short-lived authorization artifact for one task instead of a permanent credential with broad access.
OWASP’s AI Agent Security guidance recommends scoped tool access and independent authorization controls, while current OWASP AI security work also emphasizes high-impact action controls and short-lived authorization artifacts.
This is the same principle used elsewhere in security: make the permission boundary smaller than the potential blast radius.
Bind the action to the intended authority
Consider an agent that can create a bank transfer. A simple design might authenticate the agent and then allow it to call a payment API. That proves who called the API, but it does not necessarily prove that the particular transfer was authorized.
A stronger design evaluates the complete action context: who requested it, which agent is acting, which account is involved, what amount is being transferred, whether the action fits policy and whether any required approval exists.
For high-impact actions, approval should be tied to the specific action rather than treated as a general permission. This makes it harder for an attacker to reuse an old approval for a different operation.
Delegation creates a second security problem
Agents increasingly call other agents. That can be useful, but it introduces a delegation chain.
If Agent A is allowed to read one project, it should not be able to ask Agent B for organization-wide data simply because Agent B has broader permissions. The delegated authority should remain within the scope of the original task.
This is a classic confused-deputy problem in a new setting. The security architecture must prevent an agent from gaining extra authority by passing a request through a more privileged component.
A useful rule is simple: delegation should reduce or preserve authority, never silently expand it.
Audit the relationship, not just the API call
A log entry saying “agent called API” is not enough for a sensitive action. Security teams need enough context to reconstruct why the action happened.
For important operations, consider recording:
- authenticated human or originating principal;
- agent identity;
- delegated scope;
- tool and target resource;
- normalized action parameters;
- authorization decision;
- approval information where applicable;
- timestamp and correlation identifier;
- result or failure reason.
Avoid recording secrets or unnecessary personal information. The objective is traceability, not indiscriminate data collection.
What happens when prompt injection succeeds?
Prompt injection is particularly important here because the model may be manipulated without the underlying identity being compromised. An attacker could place malicious instructions in a document that an agent later reads. The model might then request a dangerous tool call.
A secure architecture assumes this can happen. The authorization layer should still reject actions outside the agent’s delegated scope.
That is a much stronger design than asking the model to promise that it will ignore malicious instructions. Model behavior is useful as one control, but it should not be the final security boundary.
NIST’s recent AI agent security work likewise highlights prompt injection alongside identity, authorization and auditing as connected parts of the problem.
A practical architecture
A useful pattern is:
- The user authenticates to the application.
- The application creates a task with a defined scope.
- The agent receives an agent identity and narrowly scoped authority.
- The model proposes a tool action.
- An independent policy component checks identity, resource, action and delegation context.
- High-impact actions require the appropriate approval or step-up authentication.
- The protected service enforces the authorization decision.
- The result is logged with enough context for investigation.
The model remains useful for planning and reasoning, but it does not become the authority that grants itself access.
Common mistakes
Several design choices should immediately attract scrutiny:
- giving every agent the same service account;
- putting broad API keys directly into agent tools;
- trusting text such as “the user approved this” without external evidence;
- allowing a privileged agent to delegate unrestricted authority;
- using permanent credentials for temporary tasks;
- checking authorization only inside the model prompt;
- logging tool calls without their originating user or task context.
These mistakes are tempting because they make prototypes work quickly. They become expensive when an agent moves into a system that can change real data.
A developer checklist
Before allowing an AI agent to perform real actions, ask:
- Does the agent have an independently verifiable identity?
- Can the system distinguish the human principal from the agent?
- Are credentials short-lived and narrowly scoped where practical?
- Is authorization enforced outside the model?
- Can an agent delegate only authority it actually possesses?
- Are high-impact actions subject to stronger controls?
- Can each sensitive action be traced to a user, agent and policy decision?
- Can access be revoked quickly?
- What happens if the model is fully prompt-injected?
- Does the design fail closed when authorization information is missing?
The key idea
An AI agent is not secure simply because its user is authenticated. Once software can act on that user’s behalf, the system needs a clear chain of identity, delegation and authorization.
The strongest design treats the model as a decision-making component inside a larger security architecture. Identity comes from trusted infrastructure. Authorization is enforced independently. Credentials are scoped. Delegation cannot create new privilege. High-impact actions receive stronger controls. Logs preserve the relationship between the human, the agent and the action.
That approach makes an important promise possible: even if the model is manipulated, it should still be unable to act beyond the authority deliberately granted to it.