AI Agent Identity and Authorization: A Practical Least-Privilege Design
A practical framework for agent identity, action-level permissions, approval boundaries, untrusted content isolation, and auditable tool execution.
4 分钟阅读
Once an AI agent can read email, access repositories, or call a cloud API, security is no longer just about whether the model produces a wrong answer. The operational questions are: whose identity is it using, which resources can it touch, who approved the action, and can the full chain be reconstructed afterward?
In May 2026, NIST published its analysis of responses to a request for information on AI-agent security. Respondents broadly agreed that established cybersecurity principles still matter, but must be adapted for autonomous planning, external data, and tool use. A related NIST identity and authorization concept paper highlights identification, authentication, authorization, auditing, and non-repudiation. The practical conclusion is simple: a prompt is not an access-control system, and a model’s judgment cannot replace server-side authorization.
Start with three separate identities
An auditable system should distinguish the human who requested the task, the agent that planned it, and the workload that invoked the tool. Sharing one long-lived API key across all three is convenient, but it makes the audit trail unable to answer who an action represented. Prefer short-lived, revocable, task-scoped credentials. At the tool boundary, validate the user, agent, task, and target resource together.
Design permissions around actions, not apps
| Action | Default | Additional control |
|---|---|---|
| Read public web content | Automatic | Domain, rate, and response-size limits |
| Read a private repository or customer record | Task-scoped | Field redaction, short-lived credential, access log |
| Edit files or create a branch | Allowed in a sandbox | Directory scope, retained diff, rollback |
| Send email, publish, or pay | Human approval before execution | Show destination, content, amount, and consequence |
| Delete, deploy to production, or elevate privilege | Deny by default | Two-person approval or an independent policy service |
The goal is not an approval prompt for every click. It is a reliable checkpoint at the side-effect boundary. An approval dialog must expose the actual arguments rather than ask only whether to continue. OWASP likewise recommends least privilege, per-tool authorization, and an execution component that verifies scope and approval independently of the model.
Treat external content as data
A webpage, email, PDF, code comment, or tool response may contain instructions aimed at the agent. NIST’s red-team work describes this indirect prompt-injection risk as agent hijacking: the model reads attacker-controlled text during an otherwise legitimate task and is induced to take an unintended action. A system prompt saying “ignore malicious instructions” is not a security boundary.
- Give the component that parses untrusted content no write tools by default.
- Validate tool arguments, ranges, and resource ownership in trusted code.
- Re-bind high-risk operations to the original user intent.
- Keep credentials outside model context and redact secrets from logs.
- Set hard limits on loops, spend, and outbound data volume.
What evidence should one action leave?
Each tool call should record a task identifier, user identity, agent version, tool and parameter summary, policy decision, approving principal, execution result, and resource version. Logs should establish authorization and outcome without storing unnecessary prompts, customer text, or secrets. For write operations, retain a before-and-after record or commit hash so rollback is real rather than aspirational.
This is why the desktop-agent market will not be decided by model capability alone. Enterprise buyers need controlled execution: explicit boundaries, recoverable state, reliable audit evidence, and meaningful human control. For more context, see our analysis of agent permission boundaries and the broader desktop-agent direction.
Seven checks before production
- Inventory every data source and tool the agent can access.
- Separate read, write, outbound communication, payment, and deletion.
- Issue task-scoped credentials and test revocation.
- Validate resource ownership at the service, not in the prompt.
- Parse untrusted content in a tool-free quarantine.
- Show exact arguments before approving consequential operations.
- Regression-test injection, privilege escalation, and retry behavior with harmless instrumented tools.