AI agent security: risks, frameworks and defenses

AI agent security is the set of measures that stop an agent (a language model able to read content, call tools and act on data) from doing anything its owner has not authorized. The risks come from the untrusted text the agent reads, the permissions it holds and the trust placed in its outputs. The starting references are the OWASP Top 10 for LLM Applications 2025, OWASP's work on agentic applications and the MITRE ATLAS matrix.

What are the main risks of AI agents?

The ten categories of the OWASP Top 10 for LLM Applications 2025 make the best reading plan. For an agent that acts, five of them dominate in practice.

• LLM01, prompt injection. Text received by the agent changes its behavior. In its indirect form, the instruction hides in an email, a document or a web page. See the prompt injection page and the article on prompt injection in RAG systems.
• LLM02, sensitive information disclosure. The agent reveals data it holds in context: customer data, secrets, content from other sessions. The article on chatbot data leaks gives examples.
• LLM05, improper output handling. The model's output is passed as is to a browser, a database or an interpreter. Unvalidated output then turns into a classic injection (XSS, SQL, system command).
• LLM06, excessive agency. The agent has too many tools, too many rights or too much autonomy. It multiplies every other risk, because it sets the impact of a successful injection.
• LLM07, system prompt leakage. Internal instructions, sometimes holding business rules or identifiers, get extracted and make the next attack easier.

The other five categories complete the picture: LLM03 (supply chain: models, libraries, third-party MCP servers), LLM04 (data and model poisoning, see data poisoning and model corruption), LLM08 (vector and embedding weaknesses), LLM09 (misinformation) and LLM10 (unbounded consumption).

Why is an agent riskier than a simple chatbot?

A chatbot answers; an agent acts. As soon as a model can send an email, edit a record, run a query or trigger a payment, a successful injection no longer yields just a bad answer. It yields a real action, often with a legitimate user's rights.

Three properties explain the increase:

• Tools turn text into effects. The article on the attack surface of function calling details this step.
• Context mixes trust and external content. The model cannot reliably tell the developer's instruction from an instruction hidden in a document.
• The chain is long. An agent relies on a model, an orchestrator, plugins, MCP servers and APIs. Any link can be compromised, as supply chain incidents reported around MCP servers show, for example the npm worm tied to postmark-mcp.

What do OWASP's agentic work and MITRE ATLAS say?

OWASP extends its LLM Top 10 with work on agentic applications, covering risks specific to agents: goal hijacking, tool misuse, identity impersonation, poisoned memory and agent-to-agent communication. A dedicated Top 10 for the MCP protocol is also under development. Both documents serve as a reading grid for an audit.

MITRE ATLAS is a knowledge base of adversary behavior against AI systems, modeled on MITRE ATT&CK. It describes tactics and techniques that were observed or demonstrated, so a finding can be tied to a recognized technique and discussed in the same language as a detection team. A red team report gains credibility when each finding cites its OWASP category and the matching ATLAS technique.

What should a company check before putting an agent into production?

A company should be able to answer yes to eight questions before go-live.

1. Inventory: do we know every tool the agent has, with its permissions and arguments?
2. Minimal rights: is each tool limited to what the task requires, read-only when possible?
3. Human approval: do irreversible or sensitive actions (external send, deletion, payment) require approval?
4. Untrusted content: do we know where each text the agent reads comes from, and do we treat it as untrusted?
5. Customer isolation: can one user or tenant reach another's data through the agent's tools?
6. Outputs: is model output validated before it reaches a browser, a database or another system?
7. Logging: is every tool call traced with its trigger, arguments and result?
8. Offensive test: has the agent been attacked by someone other than its designer?

Our exposed agent page helps place an agent against these points.

How do you defend an AI agent in production?

Effective defenses are structural: they limit what the agent can do whatever the quality of the model. Instructions written into the prompt help, but an attacker can get around them.

Apply least privilege to tools

Give each agent only the tools and rights it needs, with narrow, short-lived tokens. A support agent that reads tickets does not need to write to the customer database. Keep agents that read external content apart from those holding write rights.

Require human approval on sensitive actions

Any irreversible, external or financial action goes through an approval, showing the real action clearly (recipient, amount, data sent). Avoid bulk approvals that lead people to click without reading.

Isolate untrusted content

Treat all external content as data rather than as instructions: clear delimiting in the context, processing in an agent without sensitive tools, filtering of links and images rendered in the interface (a frequent leak channel). Research such as CaMeL proposes separating trusted instructions from untrusted data by design.

Validate outputs before use

A model's output is untrusted input for the next system. Validate schemas, escape before display, use parameterized queries, and never run model-produced text directly.

Log and monitor

Keep tool calls, arguments and session identifiers, with alerts on unusual patterns: read volumes, new recipients, rare tool sequences. Without logs, an incident cannot be reconstructed.

Control the supply chain

Pin versions of libraries and MCP servers, review their tool descriptions and rights, and follow security advisories. Several recent incidents hit ecosystem components, such as the command injection in a LiteLLM component or the agent hijacked through a pull request comment.

Which agent flaws show up most often in engagements?

Red team engagements surface recurring patterns, most of which come less from the model itself than from how the agent is wired. The most frequent ones follow.

• Writes without guardrails: the agent stores personal data through a tool call with no validation, no idempotency and no read-back, so a false or injected value is accepted.
• Reads without authentication: a read API sitting behind the agent (session read-back by identifier, lookup by plate or by number) answers anyone, even though the agent is supposed to be the only door.
• Isolation by a bare parameter: the customer is selected by a URL parameter or an identifier with no token, which lets others be enumerated.
• Soft guardrails: the model refuses to recite a piece of data but reveals its length, a prefix or its existence, because the data stays in its context.
• Chatty error messages: an error trace on an unknown customer exposes paths, libraries or storage names.
• Claimed actions: the agent says it performed an action it did not perform, or the reverse, which skews human checks.

These findings are most often fixed on the application and rights side, before the prompt is touched. That is why an agent test includes the host application in its evidence scope. The AI agent red teaming page describes how an engagement runs.

How do you map each risk to a concrete response?

Each OWASP risk is handled by a small set of controls. This mapping works as a roadmap for a team getting started.

• LLM01 prompt injection: isolate untrusted content, limit the tools reachable while processing external content, validate sensitive actions.
• LLM02 information disclosure: put in context only the data needed for the current request, and filter output channels.
• LLM03 supply chain: pin versions, review MCP tool descriptors, follow security advisories.
• LLM04 poisoning: check the provenance of training data, fine-tuning data and indexed documents.
• LLM05 outputs: validate and escape before any use by another system.
• LLM06 excessive agency: minimal rights, bounded autonomy, human approval.
• LLM07 system prompt: put no secret in it, and assume it will be read.
• LLM08 vectors and embeddings: partition indexes per customer and enforce access rights at retrieval.
• LLM09 misinformation: require verifiable sources before any action that depends on a claim by the model.
• LLM10 unbounded consumption: quotas, cost ceilings, limits on tool loops.

For a detailed reading of each category, see the OWASP LLM guide 2026 and the article on AI-generated applications.

Prompt guardrails or structural controls: which one to choose?

The two combine, but they do not give the same level of assurance.

• Prompt guardrails (instructions, classifiers, filters): easy to deploy, useful against common cases, bypassable by rephrasing. They lower the odds of abuse without capping the impact.
• Structural controls (minimal rights, human approval, isolation, allow-lists of actions): costlier to design and independent of the model, they cap the impact even when the injection succeeds.
• Monitoring and logging: prevent nothing, but allow detection and reconstruction. Essential in both cases.
• Offensive testing: measures the real gap between intent and behavior. It is the only way to learn which of these controls hold.

How do you test the security of an AI agent?

A serious test attacks the agent the way a stranger would: planting instructions in the sources the agent reads, attempting tool abuse, extracting data, crossing boundaries between customers. Research benchmarks such as InjecAgent and AgentDojo show that this evaluation has to run on the complete agent with its real tools, because the isolated model gives an overly optimistic picture.

CleanIssue runs this test as an engagement: the Agent Red Team Express at €1,900 in 5 days for one agent, or a custom red team on quote for a wider scope. For agents that expose MCP servers, the MCP security page details the checkpoints. The method describes the full sequence.

Where does CleanIssue's Shield stand?

The Shield is the planned software layer between the agent that proposes an action and the system that authorizes it, built to block unauthorized actions. It is under development and not available today. Until then, the controls above can be put in place with the orchestrator, APIs and rights you already control.

Who owns AI agent security inside a company?

Ownership usually sits between the team that builds the agent and the person who answers for the data it touches. In a small company that is often the founder or the CTO. Name one owner for the agent's tool list and permissions, and review that list whenever a tool, a model or a content source changes. A short written inventory, kept up to date, answers most customer security questionnaires and speeds up any later test.

Where to go next

Start with a free 30-minute discovery meeting to place your agent against these risks. Term definitions are in the glossary, and prices are on the pricing page.