AI agent security is the problem of keeping goal-directed AI systems within the authority that users and organizations intended to give them. The issue becomes more important when an agent can read private data, call APIs, run code, send messages, change records or trigger transactions.
Many security principles are familiar from ordinary software: authenticate identities, minimize privileges, validate inputs and keep logs. AI agents add a new difficulty because model-generated decisions can determine which tool is called and what data is sent to it. Untrusted text can also influence those decisions.
Why AI agents create a different security problem
A normal generative model may produce a wrong answer. An agent can turn a wrong interpretation into an external action. That means the security boundary cannot be the model alone. The surrounding system must enforce what the agent is allowed to see and do.
NIST’s 2026 AI Agent Standards Initiative identifies agent security and identity as core research areas for trusted adoption, including secure human-agent and multi-agent interactions.
1. Agent identity
Organizations need a reliable way to identify which agent is making a request. An agent identity may be tied to an application, service, task, user or delegated role. The important property is that external systems can distinguish one agent from another and apply policy accordingly.
NIST’s identity and authorization concept work asks what metadata an agent identity needs, how identities should be managed and how agent actions can be bound back to human authorization.
2. Authentication
Authentication proves that an agent or service is the identity it claims to be. Credentials should be issued, rotated and revoked like other machine credentials. Long-lived secrets embedded in prompts or code are especially dangerous because an agent may process untrusted input.
3. Authorization and least privilege
Authorization determines what an authenticated agent may do. Least privilege means the agent receives only the permissions required for its task. A calendar assistant may need permission to read availability but not delete every calendar. A research agent may need read-only database access rather than the ability to modify production data.
Dynamic agents make least privilege difficult because their exact future actions are not always known. A practical design uses narrow tools, scoped credentials, explicit policy checks and separate approval for high-impact operations.
4. Delegated authority
Agents often act “on behalf of” a person. Systems therefore need to distinguish the agent’s own identity from the authority delegated by a user. A user may allow an agent to prepare a payment but still require confirmation before money moves.
5. Direct and indirect prompt injection
Prompt injection occurs when instructions from an untrusted source influence model behavior in a way the system did not intend. Indirect prompt injection is especially relevant to agents because they routinely ingest external emails, websites, documents and code repositories.
A malicious page could contain text designed to persuade an agent to reveal data or call a dangerous tool. NIST’s 2026 agent red-teaming work highlights agent hijacking through indirect prompt injection as a real security concern for systems that process external data.
How to reduce prompt-injection impact
- Do not treat retrieved content as trusted system instructions.
- Keep sensitive tools behind policy checks that the model cannot override.
- Limit the data and credentials available to each tool invocation.
- Require confirmation before irreversible or high-impact actions.
- Record tool calls and important decisions for later review.
- Test agents with adversarial content from the same kinds of sources they will process in production.
6. Tool and API safety
A tool should expose the smallest useful capability. “Delete any database row” is harder to secure than a purpose-built tool that can close one approved record type after validation. Structured parameters, server-side validation and allowlists reduce the amount of authority delegated to model-generated text.
7. Memory and data leakage
Agent memory can mix information from different tasks or users if isolation is weak. Systems should define what can be stored, how long it is retained and which identity can retrieve it. Sensitive data should not be copied into long-term memory simply because it appeared in one task.
8. Multi-agent security
In a multi-agent system, one agent may delegate work to another. Each hop can change the security context. The receiving agent should not automatically inherit every privilege of the coordinator. Identity and authorization need to remain explicit across delegation.
9. Auditing and non-repudiation
Security teams need to reconstruct what an agent did, which identity authorized it, which tools were called and what important inputs influenced the decision. NIST’s concept paper specifically raises auditing and non-repudiation as design questions for agent systems.
10. Human approval is a security control
Human-in-the-loop design is not necessary for every action, but it is valuable at risk boundaries. A system can autonomously collect information and draft a change while requiring a person to approve payment, publication, account deletion, credential changes or production deployment.
A practical security model for AI agents
Start by treating the agent as an untrusted decision-maker inside a trusted enforcement layer. The model may recommend what to do, but code outside the model decides whether the requested action is permitted. Combine scoped identity, least privilege, input isolation, approval gates, tool validation and complete logs.
