Securing AI Agents with Identity and Least Privilege

A common shortcut is to give an agent a user’s token or a broad application credential and trust the prompt to keep its behavior narrow. That design collapses several identities into one. The resource server cannot reliably distinguish the employee from the agent, one agent instance from another, or a permitted task from an unrelated action.

A stronger design gives the agent a distinct workload identity and preserves the identity of the human or organizational principal that authorized the task. The access decision can then consider both. This is consistent with zero-trust architecture, where authentication and authorization are explicit decisions tied to the resource rather than implied by network location or ownership.

The distinction also supports accountability. If an agent changes a record, the audit trail should identify the agent instance, the sponsoring principal, the policy used, and the delegated task. Logging only the user account makes an automated action look like a human action. Logging only the agent loses the chain of responsibility.

TDG recommends expressing each agent task as a compact authority envelope. The envelope is not a natural-language promise. It is the set of machine-enforceable conditions that every tool and resource call must satisfy.

This model prevents a user’s broad access from becoming an agent’s ambient access. A procurement analyst might be permitted to view an entire contract repository, while an agent preparing a market-research summary receives read access only to the approved solicitation workspace, only for the assigned task, and only until the job ends.

The September 2026 NIST NCCoE summary on agentic identity describes a useful direction: stable trust anchors paired with ephemeral credentials, explicit scope attenuation, and independent revocation. The summary reflects public feedback and emerging implementation work, not a final standard, but it reinforces established identity and least-privilege practices.

In practice, an agent should exchange its registered workload identity and task context for a short-lived token containing only the scopes necessary for the next operation. If the agent delegates a subtask, the child credential should be narrower than the parent credential. A research sub-agent may retrieve selected sources; it should not inherit permission to send the finished memorandum or change the source repository.

Credentials should expire at task completion or timeout, be bound to the intended audience where supported, and be revocable without disabling unrelated workflows. Secrets should not be placed in prompts, long-term memory, tool output, or general-purpose logs.

Agents interpret instructions and context probabilistically. Authorization must remain deterministic. Before every consequential tool call, a policy enforcement point should evaluate the agent identity, originating principal, task, requested action, target resource, current context, and approval state. If the request does not match the authority envelope, the tool call should fail closed.

This separation matters when the agent encounters untrusted content. A document, email, webpage, or tool response may contain instructions that conflict with the approved task. A model-only guardrail can be influenced by the same content it is being asked to judge. An external execution control can deny a request even when the agent’s reasoning concludes that the action is useful.

The useful question is not whether a human is “in the loop.” It is whether a qualified person or independent control can stop the action that changes risk. Reading approved public guidance may require no additional approval. Sending an external communication, changing access, updating a system of record, releasing funds, deleting information, or deploying code may require explicit approval or a separate control path.

The approval screen should describe the exact proposed action, target, affected data, and consequence. It should not ask a user to approve a vague goal such as “continue the task.” Approval should expire if the proposed action changes, the data changes materially, or the task exceeds its time window.

Organizations should also preserve separation of duties. The agent that prepares a change should not be able to approve the change using the same identity or credential. High-impact actions should require an independent principal, policy service, or workflow stage.

An investigation should be able to reconstruct the originating request, sponsoring principal, agent and model version, delegated authority, policy decision, approval event, tool call, target resource, result, and any downstream delegation. The record should also show when authority was denied, expired, or revoked.

More logging is not automatically better. Prompts, retrieved records, tool responses, and reasoning traces may contain sensitive information. Define the minimum evidence required for accountability and incident response, protect it as a controlled data set, restrict who may query it, and apply retention and deletion requirements. CISA’s secure-by-design guidance on high-quality audit logs is a useful operational reference, but log content still needs privacy and mission boundaries.

Before production release, test the complete control path:

1. A permitted task succeeds with the expected agent identity, scope, and evidence.
2. The same agent is denied access to an unrelated record, tool, method, or data field.
3. A user with broad access cannot cause the agent to exceed the agent’s approved function.
4. A malicious instruction in retrieved content cannot bypass the policy enforcement point.
5. A delegated sub-agent receives less authority than its parent and cannot reuse the parent credential.
6. An expired or revoked credential fails immediately according to the documented requirement.
7. A consequential action stops at the required approval gate and records the approver’s decision.
8. An auditor can reconstruct the chain of authority without unrestricted access to sensitive prompts or records.

Repeat these tests after changes to models, prompts, tools, connectors, identity providers, policies, deployment environments, or delegation logic. Each new tool changes the agent’s possible impact, even when the model is unchanged.

• Question 01Can every agent and agent instance be distinguished from the human or service that authorized it?
• Question 02Is authority limited by task, resource, action, duration, and context rather than inherited from a broad user account?
• Question 03Does deterministic policy evaluate every consequential tool call outside the model?
• Question 04Which actions require independent approval, and can the approver see the exact proposed consequence?
• Question 05Can credentials be narrowed, expired, and revoked without interrupting unrelated work?
• Question 06Can an investigator connect an action to the agent, sponsoring principal, delegated authority, policy decision, and approval?