Security guardrails for AI agents, layer by layer

An assistant that only answers questions can get things wrong or reveal information. An agent that also queries systems, reads email and takes actions can do real damage if someone manages to manipulate it. The difference is the tools: each one you connect widens what an attacker can achieve through the model.

No single control makes an agent secure today. Prompt injection, the first risk in the OWASP Top 10 for LLM Applications 2025, has no known complete solution. That is why the practical approach is defense in depth: assume some layer will fail and design the others so that the failure does not turn into an incident. In the CISO and AI we placed these risks in the NIST CSF 2.0 functions; here we move down to the concrete design of the agent.

A four-layer model with a cross-cutting axis

We propose looking at the path of each request in four layers: what enters the agent, the model and its instructions, the tools it can use and what goes out to people or other systems. A fifth element, monitoring and logging, cuts across all of them.

The logic is that no layer depends on the previous one having worked. If an injection gets past the input, the tools limit what it can do. If the model reveals something it should not, the output filters it. And if everything fails, the logs make it possible to detect and reconstruct what happened.

Input: direct and indirect injection

Direct injection is typed by the user, with instructions along the lines of "ignore the above and do this". Indirect injection is more dangerous in an agent, because it arrives inside the content the agent processes as part of its job: the email it summarizes, the ticket it classifies, the page it queries or the document it retrieves from the knowledge base. The legitimate user never even sees it.

• Mark where every piece of content comes from. When building the context, keep system instructions, the user's request and external data apart, and always treat external data as untrusted.
• Use injection classifiers as a signal, not a guarantee. They catch known patterns and cut noise, but a patient attacker gets around them.
• Limit the sources. A triage agent does not need to browse the internet. Every source you add is new attack surface.
• Normalize the content. Strip hidden text, HTML comments and metadata that a person does not see but the model does read.

The design rule that protects most, however, sits in another layer: assume some injection will succeed and limit what the agent can do when it does.

Model: instructions, versions and provenance

The model is not a reliable security barrier, but its configuration still matters.

• System instructions without secrets. OWASP includes system prompt leakage in its 2025 list: anything written there can end up in a response. Credentials, sensitive internal names and customer data stay out of the prompt.
• Authorization is not delegated to the model. Writing "do not show other customers' data" in the instructions is not a control. Filtering by permissions in the data layer is.
• Pinned model and version. Switching models or versions is a change that goes through adversarial testing, just like a code change.
• Known provenance. Models from verified sources and, if they are fine-tuned or fed with your own data, versioned datasets and indexes, with control over who can write to them.

Tools: where manipulation becomes action

OWASP calls this risk excessive agency: more functionality, permissions or autonomy than the task needs. The Agentic AI Threats and Mitigations guide, published in February 2025 by the OWASP Agentic Security Initiative, expands on threats specific to agents, such as tool misuse, privilege compromise and poisoning of the agent's memory.

• Least privilege per tool. Each tool exposes only the operations needed, with parameters validated against a schema. A generic "run command" tool is almost always a design mistake.
• Its own identity and short-lived credentials. The agent acts under its own identity, or under that of the user it serves with the same permissions, never with a broadly privileged service account.
• Human confirmation for write actions. Reading can be automatic; creating, modifying, deleting, sending or paying requires explicit approval until the use case builds a track record. The approval screen shows the actual action and its parameters, not a summary written by the agent itself.
• Rate and volume limits. Maximum calls per minute, per session and per tool, plus caps on records, amounts or recipients. A loop or an abuse stops on its own, and unbounded resource consumption is kept in check too.
• Allowed destinations. If the agent sends email or calls external URLs, only to approved domains. This is the most direct exfiltration path.

Incident triage is a good example of an agent that reads a lot and writes little, which is why it can work with a narrow tool perimeter; we describe it in incident triage with agents.

Output: filtering and data leakage

The model's output is text generated from untrusted content, so it is treated as untrusted input by the system that receives it. OWASP covers this in two separate entries: sensitive information disclosure and improper output handling.

• Filter sensitive data before displaying or sending: card numbers, identity documents, credentials or health data, according to the organization's classification. Existing data loss prevention (DLP) rules are a good starting point.
• Enforce permissions at retrieval, not only in the response. If the agent only retrieves documents the user can see, the output filter is a second layer rather than the only one.
• Escape or validate before use. Output that is inserted into a web page, a SQL query or a system command is handled like any other user data.
• Close leakage channels. Links and images with external URLs generated by the model can carry data in their parameters. Render only those from approved domains.

Monitoring and logging: the cross-cutting axis

This layer has two jobs: detecting attacks in progress and reconstructing what happened. NIST AI 600-1, the Generative AI Profile of the AI RMF, lists incident disclosure among its primary considerations, and that is only possible with complete logs.

• What to log. For every interaction: the input, the retrieved context and its origin, tool calls with parameters and results, approvals and the output, along with the model and instruction versions.
• What to alert on. Detected injection attempts, denied tool calls, call spikes, disallowed destinations and outputs blocked by the filter.
• Where. Agent events go to the SIEM and the security operations center, treated like any other source.
• How to stop it. A tested kill switch that disables write tools without depending on the agent.

These logs contain sensitive data: their retention and access are defined with the data protection team before they are switched on.

From OWASP risk to concrete guardrail

The table walks through the ten entries of the OWASP Top 10 for LLM Applications 2025 and proposes the main guardrail for an agent. It is a starting point; each use case needs its own analysis.

OWASP 2025 risk	Layer	Concrete guardrail
LLM01 Prompt Injection	Input and tools	External content marked as untrusted; write actions require approval
LLM02 Sensitive Information Disclosure	Output	Retrieval with the user's permissions; sensitive data filter
LLM03 Supply Chain	Model	Models from verified sources; inventory and pinned versions
LLM04 Data and Model Poisoning	Model and input	Versioned datasets and indexes, with control over who writes to them
LLM05 Improper Output Handling	Output	Escape and validate before passing output to another system
LLM06 Excessive Agency	Tools	Least privilege, parameter schemas, human approval
LLM07 System Prompt Leakage	Model	No secrets or authorization rules in the instructions
LLM08 Vector and Embedding Weaknesses	Input	Vector stores segmented by each user's permissions
LLM09 Misinformation	Output	Cite the source of each claim; human review for relevant decisions
LLM10 Unbounded Consumption	Tools and monitoring	Rate, token and cost limits per session, with alerts

No guardrail is enough on its own, and several reinforce each other: human approval reduces the impact of injection, and logging makes the approval auditable. If the agent is part of IT operations, the broader context is in AI agents in IT operations, and the management framework that organizes these decisions is in ISO/IEC 42001 in practice.

For agents that operate on regulated systems or customer data, validate the design of permissions, approvals and logging with Security, Risk and the data protection team before going to production.