An AI agent becomes a security principal when it can call tools, read business data, or change production systems. At that point, a shared API key and a broad role are not shortcuts. They erase the answer to three incident questions: which agent acted, whose authority it used, and whether that exact action was allowed.
The right time to answer those questions is before connecting the agent to production tools. This guide gives technology and security leaders a practical access design: one identity per agent, permissions bounded to the task, and a delegation record that survives every hop.
The February 2026 NIST NCCoE paper on software and AI agent identity and authorization is a draft concept paper, not a finished implementation standard. It frames the core problems—identification, authentication, dynamic authorization, delegation, logging, and non-repudiation—and proposes demonstrating how existing standards can be applied. NCCoE's later summary of public comments reports strong interest in contextual authorization, least privilege, and preserving accountability through delegation chains. The architecture below turns those questions into decisions you can implement now while the standards work continues.
Start with three separate identities
Do not treat “the agent” as a single identity. Record three principals for every run:
- Initiating principal: the person or service that requested the outcome.
- Agent identity: the specific deployed workload performing the task.
- Runtime identity: the verified environment in which that agent is executing.
The initiating principal establishes where authority came from. The agent identity distinguishes one agent, version, or specialist from another. The runtime identity helps prevent a credential issued to a trusted deployment from being replayed elsewhere.
Give each deployed agent its own managed, revocable workload identity. Do not reuse a developer login, a generic “AI” service account, or one credential across a fleet. Prefer short-lived credentials issued to an authenticated runtime over long-lived secrets stored in prompts, configuration files, or tool definitions.
This separation also improves operations. You can disable one agent without stopping every workflow, compare behavior by version, and attribute a tool call even when several agents collaborate. Pair it with the controls in our guide to observing AI agents without leaking sensitive data.
Define authority as a task envelope
Traditional role-based access often grants a standing bundle of permissions. An agent needs a narrower envelope that describes the current task. At minimum, bind authorization to:
- the initiating principal and agent identity;
- the approved purpose and workflow;
- allowed tools, operations, resources, and destinations;
- data classifications the agent may read or disclose;
- maximum transaction value, volume, or spend;
- issue and expiry times;
- actions that require human approval;
- whether further delegation is allowed.
Consider an accounts-payable agent asked to investigate invoice 4821. “Finance contributor” is too broad. A useful envelope might permit this agent to read that invoice and its purchase order for 15 minutes, propose a discrepancy code, and create a draft note. It would deny access to other suppliers, payment release, bank-detail changes, and outbound email.
Make the policy enforcement point deterministic and external to the model. The model can propose create_draft_note(invoice=4821), but a gateway or application service must verify identity, task, resource, operation, limits, and current policy before executing it. A persuasive prompt or confident model response must never expand the envelope.
This is a practical application of zero trust: authorization is evaluated for the requested resource and action, not inferred from network location or a successful login. It complements a broader operating model for controlled agent autonomy.
Make delegation narrower at every hop
Multi-agent systems create a common failure mode: a coordinator passes all of its access to every specialist. That turns delegation into privilege multiplication.
Instead, require each child agent's authority to be a subset of its parent's current task envelope. A research agent may delegate document parsing to a specialist, but that specialist should receive access only to the selected files and a read-only extraction tool—not the coordinator's email, ticketing, or publishing permissions.
For each delegation, record:
- parent and child identities;
- the initiating principal;
- the purpose and task identifier;
- the exact capabilities transferred;
- the capabilities explicitly withheld;
- the policy and approval that authorized the hop;
- expiry, depth limit, and expected return value.
If a child needs a capability the parent cannot delegate, stop and request a new authorization. Do not accumulate permissions gathered by earlier steps. NCCoE's public-comment summary specifically highlights concern about agents aggregating rights across task chains and describes scope attenuation—each downstream agent having fewer permissions—as an important direction.
Distinguish acting as the agent from acting for a user
Use the agent's own authority for system-owned work such as reading a shared knowledge base or writing an internal processing record. Use delegated user authority when the action is genuinely performed on behalf of a person, such as accessing that person's calendar or creating a ticket in their name.
Never collapse the two into a shared bearer credential. The resource service should be able to determine both the agent and, when applicable, the human principal. The effective permission must be the intersection of:
- what the user may do;
- what the agent is allowed to do;
- what this task authorizes now;
- what the target resource policy permits.
Require fresh approval when the destination, side effect, data sensitivity, or transaction value differs from what the user approved. Approval screens should display the specific action and affected resource, not a vague request to “let the agent finish.”
Preserve an audit chain, not just a chat transcript
A model transcript does not prove which credential was used or what a target system accepted. Build a structured event trail at the enforcement layer. For every consequential call, capture:
- run, task, and correlation identifiers;
- initiating, agent, runtime, and delegated identities;
- normalized tool, action, resource, and destination;
- authorization inputs, policy version, and decision;
- approval identity and the exact approved operation;
- result, side effect, error, and rollback reference;
- delegation parent and child when another agent is involved.
Protect the trail from ordinary agent writes, synchronize timestamps, and redact secrets and unnecessary personal data. Test whether an investigator can reconstruct a run without trusting the agent's own narrative. Our AI agent incident-response guide explains how these records support containment and recovery.
Use a production access review
Before connecting an agent to a production tool, require evidence for seven questions:
- Does this deployment have a unique, managed, revocable identity?
- Is the initiating principal preserved separately from the agent?
- Is authority limited by task, resource, operation, destination, and time?
- Are policy checks enforced outside the model for every consequential action?
- Can delegation only reduce scope, with a bounded depth and expiry?
- Can high-impact actions obtain specific, fresh approval?
- Can an investigator reconstruct who authorized, attempted, approved, and completed each action?
If any answer is no, keep the workflow read-only, in shadow mode, or fully supervised. Do not compensate for a missing identity boundary with better prompting.
The goal is not to invent an entirely new identity stack for every agent. It is to apply managed identities, short-lived credentials, policy enforcement, scoped delegation, and reliable audit records to a new kind of software actor. When authority remains explicit from human intent to final side effect, agents can become more useful without becoming anonymous administrators.