# AI agent security

> AI agent security protects agents that plan and use tools from hijacking, misuse and data loss. This map pairs OWASP's ten agent risks with controls.

Source: https://www.honeyhive.ai/learn/ai-agent-security (updated 2026-11-05)

AI agent security is the work of keeping an agent from doing harm when its input is hostile, its instructions are ambiguous or its model simply gets it wrong. A chatbot can say something bad. An agent can send, delete, buy and share, so the controls shift from checking text to limiting powers, approving risky steps and recording what happened. Below are the threats, with the controls from OWASP, Google and NIST in one map.

## What changes when the model acts

Google's [paper on secure agents](https://services.google.com/fh/files/misc/google_approach_for_secure_ai_agents.pdf) (May 2025) names two main risks: rogue actions, which it defines as unintended, harmful or policy-violating actions, and sensitive data disclosure. It also states the tension plainly: the autonomy and power that make an agent useful "correlate directly with increased risk."

OWASP draws the same line between its two lists. Its LLM Top 10 [owns the risk](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/LLM00_Preface.md) while the model is a component inside an app. When the model has tools, memory and downstream consequences, it points readers to the Agentic Top 10. For the model-level list, see [LLM security risks](/learn/llm-security) and the [OWASP Top 10 for LLM applications](/learn/owasp-llm-top-10).

## The threats: OWASP's ten agent risks

The [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) was published on December 9, 2025, with input from more than 100 experts. The entry names below come from OWASP's [mapping appendix](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/Appendix_A_Related_Framework_Mappings.md), which maps each one to the LLM risks behind it.

| ID | Risk | How it happens |
|---|---|---|
| ASI01 | Agent Goal Hijack | Injected input redirects the agent's goals. |
| ASI02 | Tool Misuse & Exploitation | Injected input drives an unauthorized tool call. |
| ASI03 | Identity & Privilege Abuse | The agent acts with the user's elevated credentials and does what the attacker could not. |
| ASI04 | Agentic Supply Chain Vulnerabilities | MCP servers and tool registries, [per OWASP](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/LLM04_SupplyChain.md). |
| ASI05 | Unexpected Code Execution (RCE) | Shell, file-system or cloud API access turns an injection into command execution. |
| ASI06 | Memory & Context Poisoning | A poisoned memory or RAG store taints every later session that reads it. |
| ASI07 | Insecure Inter-Agent Communication | Weak trust between agents that message each other. |
| ASI08 | Cascading Failures | Tool outputs re-enter the context and chain effects. |
| ASI09 | Human-Agent Trust Exploitation | An injection gets past human confirmation. |
| ASI10 | Rogue Agents | Agents acting outside their intended behavior, for example falsifying task completion. |

OWASP's [excessive agency entry](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/LLM03_ExcessiveAgency.md) says that in agentic systems it can show up as ASI02, ASI03 and ASI08. The separate [AI Agent Security cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) adds two threats the list does not name as entries: decision and approval manipulation, such as altering risk scores or approval thresholds, and denial of wallet, where unbounded loops drive up cost.

The root is usually one flaw. NIST [describes](https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations) agent hijacking as attackers placing instructions in content an agent processes, such as an email, file or website, because the system does not clearly separate trusted instructions from untrusted data. It calls this a type of indirect prompt injection. See [prompt injection](/learn/prompt-injection) for the attack itself.

## How often attacks work

NIST's CAISI tested agents in the AgentDojo framework with the UK AI Security Institute. Its [write-up](https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations) (January 2025, updated December 2025) reports that new adaptive attacks raised the success rate from 11% for the strongest baseline attack to 81%. Across five injection tasks the average was 57%, and trying each attack 25 times lifted it to 80%. The test used one model family from that period, so treat the numbers as evidence that fixed tests understate risk, not as a rate for any current agent.

## The control map

Google's [three principles](https://services.google.com/fh/files/misc/google_approach_for_secure_ai_agents.pdf) make a workable frame: agents need well-defined human controllers, their powers must be carefully limited, and their actions and planning must be observable. The table sorts the controls from OWASP's cheat sheet, Google, Anthropic and OpenAI under them. The last column is a reading of which OWASP risks each control bounds, not OWASP's own mapping.

| Principle | Control | Source | Bounds |
|---|---|---|---|
| Human controller | Explicit confirmation before critical or irreversible actions such as bulk deletion, large payments or security changes | [Google](https://services.google.com/fh/files/misc/google_approach_for_secure_ai_agents.pdf) | ASI09, ASI01 |
| Human controller | Approvals bound to the actor, tool, target, normalized parameters and expiry, with replay protection | [OWASP cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) | ASI09 |
| Human controller | Tool approvals so users can review "every operation, including reads and writes" | [OpenAI](https://developers.openai.com/api/docs/guides/agent-builder-safety) | ASI02 |
| Limited powers | Only the tools a task needs, scoped per tool, with unknown tools denied | [OWASP cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) | ASI02, ASI05 |
| Limited powers | Permissions aligned to purpose and intent at run time, no self-escalation, scoped OAuth tokens | [Google](https://services.google.com/fh/files/misc/google_approach_for_secure_ai_agents.pdf) | ASI03 |
| Limited powers | Memory validated before storing and isolated between users and sessions | [OWASP cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) | ASI06 |
| Limited powers | Trust boundaries between agents, and authorization enforced at the receiver | [OWASP cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) | ASI07, ASI08 |
| Limited powers | Stopping conditions such as a maximum number of iterations, and tools designed so mistakes are harder ("Poka-yoke your tools") | [Anthropic](https://www.anthropic.com/engineering/building-effective-agents) | ASI08, ASI10 |
| Limited powers | Untrusted input passed through user messages, and fixed output formats between steps | [OpenAI](https://developers.openai.com/api/docs/guides/agent-builder-safety) | ASI01 |
| Observable | Logs of inputs, tools invoked, parameters, outputs and, where possible, intermediate reasoning, with sensitive data protected | [Google](https://services.google.com/fh/files/misc/google_approach_for_secure_ai_agents.pdf) | all |
| Observable | Cost per session or user, approval drift, repeated bypass attempts and abnormal tool frequency | [OWASP cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) | ASI08, ASI10 |

The deeper treatment of tool limits is in [AI agent guardrails](/learn/ai-agent-guardrails), of credentials in [AI agent identity](/learn/ai-agent-identity), of tool servers in [MCP security](/learn/mcp-security) and of approvals in [human-in-the-loop AI](/learn/human-in-the-loop-ai). Agents that call each other add the [A2A protocol](/learn/a2a-protocol) and [multi-agent systems](/learn/multi-agent-systems) to the surface.

## Deterministic controls first, model-based checks second

Google [argues](https://services.google.com/fh/files/misc/google_approach_for_secure_ai_agents.pdf) for a hybrid. Its first layer is a policy engine that sits outside the model's reasoning, intercepts each tool call and allows it, blocks it or asks the user. Its example blocks purchases over $500 and asks for confirmation between $100 and $500. Such rules are testable and set hard limits, but they are hard to scale and lack context: sending an email after reading a document can be a summary or an exfiltration.

The second layer uses models: adversarial training, guard models that classify inputs and outputs, and analysis of the agent's plan. Google [says](https://services.google.com/fh/files/misc/google_approach_for_secure_ai_agents.pdf) these are non-deterministic, cannot give absolute guarantees and "must work in concert with deterministic controls." OWASP's [cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) agrees in its own terms: fail closed when risk classification, approval validation, policy lookup or audit logging fails.

OpenAI describes its guardrails the same modest way, as ["an effective first wave of protection"](https://developers.openai.com/api/docs/guides/agent-builder-safety), and says structured outputs reduce injection risk without removing it.

## Where NIST is heading

NIST's [AI Agent Standards Initiative](https://www.nist.gov/caisi/ai-agent-standards-initiative) was launched in February 2026. It has three pillars: industry-led standards and voluntary guidelines, community-led protocols, and research on agent authentication and identity infrastructure and on security evaluations. The page also points to an NCCoE concept paper on software and AI agent identity and authorization. These are guidelines in progress, not requirements, so build to the OWASP and provider guidance above and watch NIST for the formal wording.

## Test before and after release

Anthropic [recommends](https://www.anthropic.com/engineering/building-effective-agents) extensive testing in sandboxed environments along with the appropriate guardrails. OWASP's [cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) gives a concrete shape: an abuse-case matrix covering prompt override, tool misuse, privilege escalation, memory poisoning, data exfiltration, recursive tool abuse, approval bypass and multi-agent chaining, run as adversarial suites in CI with regression tests for past failures. It also says to block a release when a high-risk policy changes without updated tests.

NIST's results back the retry point: test each attack more than once, because attackers can. See [AI red teaming](/learn/ai-red-teaming) and [testing AI agents](/learn/testing-ai-agents).

## Watching agent behavior in HoneyHive

Observability is Google's third principle, and the signals OWASP lists are measurable on traces. HoneyHive's docs say guardrail results and custom metrics can be [logged from your application code](https://docs.honeyhive.ai/v2/tracing/client-side-evals) onto the trace, so a blocked call, a missing approval or a policy decision sits on the span where it happened. [Online evaluations](https://docs.honeyhive.ai/v2/monitoring/onlineevals) score production traces, and [alerts](https://docs.honeyhive.ai/v2/monitoring/alerts/alerts) can fire on quality and cost metrics, which covers runaway loops. Traces hold full prompts and tool arguments, so protect them as Google asks for logs. See [agent observability](/learn/agent-observability).

## FAQ

### What is AI agent security?

It is the practice of limiting what an agent can be tricked or tempted into doing, and what it can reach when that happens. Google's agent paper [names two main concerns](https://services.google.com/fh/files/misc/google_approach_for_secure_ai_agents.pdf): rogue actions, meaning unintended, harmful or policy-violating actions, and sensitive data disclosure.

### How is AI agent security different from LLM security?

LLM security treats the model as a component of an app. OWASP's 2026 LLM list [says](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/LLM00_Preface.md) the risk moves to its Agentic Top 10 once the model has tools, memory between sessions and downstream consequences. See [LLM security risks](/learn/llm-security).

### What are the biggest AI agent security risks?

The [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) (December 9, 2025) lists ten, starting with agent goal hijack, tool misuse and identity and privilege abuse.

### Can a filter on the model's output secure an agent?

Not by itself. Google says relying only on the model's judgment is [insufficient](https://services.google.com/fh/files/misc/google_approach_for_secure_ai_agents.pdf) because current LLMs remain susceptible to manipulations like prompt injection. OWASP's cheat sheet lists relying on model output alone for authorization as something to avoid.