AI Agent Security: A Control for Each OWASP Agentic Risk

An AI agent differs from a chatbot in one way: it acts. It calls APIs, writes to databases, sends emails, runs code and passes work to other agents. Each action is a path an attacker can use, often by planting instructions in content the agent reads. In December 2025, OWASP published its first Top 10 for Agentic Applications, which names the risks. Most teams still lack a list of which control addresses each risk and who owns it.

An AI agent is only as safe as the narrowest set of permissions, tools and data it can use, because any instruction it reads, including one hidden in an email or web page, may end up directing those permissions.

This article maps each of the ten OWASP agentic risks to an engineering control, an owner and a way to test it, with examples from delivered projects. It does not cover model training security, and it is not a product comparison.

Key takeaways

• The OWASP Top 10 for Agentic Applications, released on 9 December 2025, lists ten risks, numbered ASI01 through ASI10, beginning with agent goal hijack and tool misuse.
• Three principles cover most of the list: give agents the least autonomy the task needs, give each agent its own identity and permissions, and require human approval for actions that are hard to undo.
• Treat everything the agent reads, including documents, emails, web pages, tool results and memory, as untrusted input.
• Put a tool gateway between the agent and your systems, so permissions, rate limits and logging are enforced outside the model.
• Run agent-generated code in a sandbox with no access to credentials or the production network.
• Real incidents, including a data leak flaw in Microsoft 365 Copilot and a malicious MCP server that copied outgoing emails, show these risks are already exploited.

Three principles behind every control

Least agency. This extends the familiar idea of least privilege: an agent should have only the autonomy, tools and permissions its task needs. An agent that summarizes support tickets does not need the ability to issue refunds.

Separate identity. Each agent gets its own service identity with scoped credentials, so its actions are logged under its name and its permissions can be limited and revoked without affecting people or other systems.

Human approval for consequential actions. Payments, deletions, external messages, permission changes and production deployments wait for a person to approve them, and the approval screen shows exactly what will happen.

The risk-to-control matrix

The risks and their numbering come from the OWASP Top 10 for Agentic Applications. The controls, owners and tests are a practical starting point for an engineering team and should be adapted to how your organization assigns responsibilities.

How the main controls work

A tool gateway between the agent and your systems

The most effective single control sits outside the model. Instead of giving an agent direct API keys, route every tool call through a gateway that checks who the agent is, which tool it wants, whether the parameters are allowed and whether the action needs approval. The gateway logs every call and enforces rate limits. Because the checks run in ordinary code, a successful prompt injection cannot talk its way past them.

Design tools narrowly. A tool called "update order status" with a fixed list of allowed statuses is far safer than a general "run SQL query" tool, even if both would work.

Separating instructions from content

Prompt injection cannot be fully prevented at the model level, so the design has to assume it will sometimes succeed. Practical measures include marking external content clearly as data in the prompt, processing untrusted content in a step that has no tools with side effects, and checking the agent's planned actions against the original task before they run.

Sandboxes for code execution

Agents that write and run code, whether for data analysis, automation or software development, need an isolated environment: a container or virtual machine with no stored credentials, no access to the production network, limits on time, memory and disk, and a fresh state for each task. Outputs leave the sandbox only through a defined channel that is checked before use.

Memory with an audit trail

Long-term memory and retrieval indexes are a slow-acting attack surface, because a poisoned entry can influence decisions weeks later. Record where each memory entry came from, limit which agents and users can write to it, let entries expire and give administrators a way to inspect and remove them.

Monitoring and a kill switch

Log every prompt, tool call, approval and result with the agent identity and a trace ID. Alert on unusual patterns, such as a spike in tool calls, access to records outside the normal scope or repeated failed actions. Every agent in production should have a tested way to suspend it in seconds.

Our guide on what MCP is and how it changes AI integration covers the controls specific to MCP servers in more detail.

These risks are already exploited

• EchoLeak (June 2025). Researchers disclosed CVE-2025-32711, a zero-click flaw in Microsoft 365 Copilot in which a crafted email could lead the assistant to send internal data to an attacker. Microsoft fixed it on the server side. It is a clear case of goal hijack through content the agent reads.
• Amazon Q Developer extension (July 2025). As BleepingComputer reported, a malicious pull request inserted instructions telling the coding agent to wipe local files and cloud resources. Amazon said the code was not functional, but the release reached an extension with over a million installs.
• A malicious MCP server (September 2025). An npm package posing as an email integration for the Postmark service worked as an MCP server and secretly copied every outgoing email to an attacker, the first malicious MCP server reported in the wild.
• An agent deleting a production database (July 2025). A coding agent on the Replit platform deleted a company's production database during a code freeze, despite instructions not to make changes. Permissions, not instructions, are what stop an agent.

Controls in delivered projects

Sandboxed AI-assisted development. For a US cybersecurity media company, a .wrk team of six to eight engineers built a threat intelligence platform that scrapes open sources, extracts entities with LLMs and stores them as a graph. The team worked with an AI coding assistant using project-specific skills and security sandboxing, with automated code review in CI and smoke tests before every production rollout. The pipeline itself used rate limits, a processing ledger and a dead-letter queue, so failures stayed contained instead of spreading. Read the NEXUS case study.

Narrow scope and handoff. For a telecom operator, a voice agent handles only the 15 most common subscriber requests, such as balance checks and SIM blocking, and hands everything else to a live agent. It runs on-premise, and results reach the CRM through defined webhooks rather than direct database access. Read the on-premise voice AI case study.

Human review by design. At Brandon J. Broderick, a US personal injury law firm, five specialized AI assistants draft legal opinions from case files, and attorneys review every opinion before it is used. The output highlights key conclusions so reviewers can check them quickly. Read the BJB legal document processing case study.

A pre-launch checklist for AI agents

• Each agent has its own identity and the narrowest permissions that let it do its task.
• Every tool call passes through a gateway that validates parameters, applies rate limits and logs the call.
• Destructive, financial and external actions require human approval that shows exactly what will happen.
• External content is treated as data, and steps that read it cannot call tools with side effects.
• Generated code runs only in a sandbox without credentials or production network access.
• Tools, MCP servers and plugins come from an approved list with pinned versions.
• Memory and retrieval indexes record sources and can be inspected and cleaned.
• Step limits, spending limits and circuit breakers stop runaway loops.
• Logs capture prompts, tool calls, approvals and results with trace IDs.
• A kill switch has been tested, and someone knows who uses it and when.
• Red-team tests with planted instructions have run against the agent before launch.

For the wider process of moving an agent into production, see our guide on how to implement AI agents, and for the policies that sit above these controls, our AI governance framework.