Skip to content
Free tool · AI security · Agents

AI Agent Guardrail Planner

AI agent guardrails are the controls that limit what an agent reads, what it can do and what it sends out, so a mistake or a hijack does as little harm as possible. Which ones you need depends on the agent: an assistant that only suggests needs far less than one that sends email or spends money on its own. Describe yours in six answers and get a layered plan with an example for each guardrail, what it does not stop, a risk level and the matching OWASP risks. Everything runs in your browser.

No download, no card
Start from an example, or describe your own below
1. What does it read?
2. What can it do?
3. Anything else?
4. How much does it act alone?
5. Most sensitive data it touches
6. Who uses it?
Read this first. No input filter reliably stops prompt injection; OWASP says it is unclear whether fool-proof prevention exists. So the plan leans on limiting what a hijacked agent can reach and putting a person or a deterministic check in front of anything that matters. Each item says what it does not stop.

Your guardrail plan (18 items)

Input guardrails

What reaches the model, and how untrusted content is marked.

  • Must have
    Mark untrusted content as data, not instructions

    Why: A model cannot reliably tell an instruction from text it was asked to read. Content from the web, email, documents or tools can contain instructions aimed at the agent.

    Example: Wrap every fetched page, email or tool result in clearly labelled delimiters, state in the system prompt that nothing inside them is an instruction, and strip hidden text such as HTML comments and white-on-white text first.

    Does not stop: The model can still follow instructions inside the delimiters. Separation lowers the odds; it is not a boundary.

    LLM01 Prompt InjectionASI01 Agent Goal Hijack
  • Must have
    Validate and expire what goes into memory

    Why: Memory turns a one-off injection into a lasting one: a poisoned note is replayed into every later session.

    Example: Only save facts the user confirms, tag each memory with its source and an expiry date, keep memory separate per user, and let users see and delete what is stored.

    Does not stop: Does not catch poisoned content that looks legitimate when it is saved.

    ASI06 Memory & Context PoisoningPractise: Agent Memory Governance Lab
  • Should have
    Screen inputs for prompt injection

    Why: A classifier or rule set catches known injection patterns before they reach the model, and gives you a signal to log and alert on.

    Example: Run each inbound email and retrieved document through an injection detector; quarantine high-scoring items for review instead of passing them to the agent.

    Does not stop: Not a complete defence. New phrasing, other languages, encoded text and instructions inside images get through, and benign text gets blocked. OWASP says it is unclear whether fool-proof prevention exists.

    LLM01 Prompt InjectionASI01 Agent Goal HijackPractise: Prompt Injection Tester
  • Should have
    Lock the system prompt, and keep secrets out of it

    Why: The system prompt sets the agent’s goal, scope and permitted actions. Users and injected text can often get the model to reveal it.

    Example: State the allowed tasks and what the agent must refuse. Put API keys, internal URLs and access rules in code, not in the prompt. Version the prompt and review changes.

    Does not stop: A system prompt is guidance, not enforcement. A jailbreak can override it, and its text should be assumed public.

    LLM07 System Prompt LeakageASI01 Agent Goal Hijack

Tool and permission guardrails

What the agent can reach, with which credentials, and how much.

  • Must have
    Give it only the tools the task needs

    Why: Excessive agency is too much functionality, too many permissions or too much autonomy. Every tool you remove is an action a hijacked agent cannot take.

    Example: An inbox-triage agent gets “read message” and “apply label”, not “send”, “forward” or “delete”. Remove general-purpose tools such as a raw shell or open HTTP client unless the task needs them.

    Does not stop: Does not stop misuse of the tools that remain.

    LLM06 Excessive AgencyASI02 Tool Misuse and ExploitationPractise: Agent Tool-Scope Lab
  • Must have
    Scoped, short-lived credentials per agent

    Why: If the agent runs on a shared admin key, a hijack inherits everything that key can do. A narrow, expiring credential caps the damage.

    Example: Give the agent its own identity. Issue tokens scoped to one mailbox, one repository or one project, expiring within the task. Where possible, act with the signed-in user’s permissions, not a service account’s.

    Does not stop: Does not stop abuse of what the scope allows.

    ASI03 Identity and Privilege AbuseLLM06 Excessive Agency
  • Must have
    Allowlist destinations and validate tool parameters

    Why: Most damage needs a destination: a recipient, a payee, a URL. A fixed list of allowed destinations blocks the attacker’s own.

    Example: Email only to your own domain or known contacts; fetch only approved domains; pay only existing payees; reject any tool call whose parameters fail a strict schema.

    Does not stop: Does not stop abuse through an allowed destination, such as an allowed site that hosts user content.

    LLM06 Excessive AgencyASI02 Tool Misuse and Exploitation
  • Must have
    Close the ways data can get out

    Why: Private data plus untrusted content plus a way out is the combination that lets an injected instruction leak data. Removing the way out breaks it.

    Example: Do not let the agent fetch arbitrary URLs (data can ride in the URL), do not render images or links from untrusted sources in its replies, and route all outbound traffic through an allowlisting proxy.

    Does not stop: Does not stop leaks through channels you allow, such as a reply to the user or a message to an allowed recipient.

    LLM02 Sensitive Information DisclosureASI01 Agent Goal Hijack
  • Should have
    Rate, spend and volume limits

    Why: Limits turn a runaway loop or a hijack into a bounded incident, and stop one user exhausting your model budget.

    Example: A daily spend cap per agent, a maximum number of messages per hour, a cap on tool calls and tokens per task, and per-user request limits; pause the agent and alert when one is hit.

    Does not stop: Does not stop damage that stays under the cap, or slow, patient abuse.

    LLM10 Unbounded ConsumptionASI08 Cascading Failures

Action guardrails

Checks between the decision and the effect.

  • Must have
    Human approval for high-impact actions

    Why: A person who sees the exact action can catch what the model got wrong or was tricked into. OWASP lists approval for high-risk actions as a prompt-injection mitigation.

    Example: Before sending, paying or changing anything that matters, show the exact recipient and text, the payee and amount, or the diff, and require an explicit click. Approval is per action, not per session.

    Does not stop: Does not stop approval fatigue, rubber-stamping, or a summary written to mislead the approver (human-agent trust exploitation).

    LLM06 Excessive AgencyASI09 Human-Agent Trust Exploitation
  • Should have
    A policy check outside the model

    Why: Rules enforced in code cannot be talked out of. Every tool call passes a deterministic check before it runs, whatever the model decided.

    Example: A policy gateway checks each call: amount under the limit, recipient on the allowlist, resource tagged as non-production, user entitled to the record. Calls that fail are blocked or sent for approval.

    Does not stop: Does not stop cases your rules did not anticipate, or bugs in the rules.

    LLM06 Excessive AgencyASI02 Tool Misuse and ExploitationASI08 Cascading FailuresPractise: Policy Gateway Lab

Output guardrails

What leaves the agent: answers, messages, generated code.

  • Should have
    Filter outputs for sensitive data

    Why: Data the agent can read can end up in its answer or in a message it sends, by mistake or because it was told to.

    Example: Scan replies and outbound messages for secrets, card numbers and personal data patterns; redact or block before they leave; never put data the user is not entitled to into the context in the first place.

    Does not stop: Does not catch data that is paraphrased, encoded or split across messages.

    LLM02 Sensitive Information Disclosure

Monitoring and response

Seeing what the agent did, and stopping it.

  • Must have
    Log every prompt, tool call and approval

    Why: Without a trace you cannot tell what the agent did, why, or what an attacker reached.

    Example: One trace per task with every model call, tool name, parameters, result size, approver and outcome. Store logs where the agent cannot edit them, and protect them: they contain sensitive data.

    Does not stop: Logging prevents nothing. It lets you see, investigate and prove what happened.

    ASI10 Rogue AgentsASI09 Human-Agent Trust ExploitationPractise: Agent Trace Triage Lab
  • Should have
    Alert on unusual behaviour

    Why: A hijacked agent behaves differently from its normal pattern: new destinations, bursts of calls, data it does not usually touch.

    Example: Alert on a first-seen recipient or domain, a spike in tool calls, access outside the usual records, repeated denied approvals or blocked policy checks, and injection-screen hits.

    Does not stop: Does not catch abuse that looks like normal use.

    ASI10 Rogue AgentsASI08 Cascading Failures
  • Should have
    A kill switch and credential revocation

    Why: When something goes wrong you need to stop the agent in seconds, not after a deploy.

    Example: One switch that halts all runs of this agent, a tested way to revoke its tokens, and a short runbook for who decides and what to preserve.

    Does not stop: Does not undo actions already taken.

Evaluation

Testing that the guardrails hold, before launch and after every change.

  • Must have
    Red-team with indirect prompt injection

    Why: You only know a guardrail holds if you have tried to break it the way an attacker would: through the content the agent reads.

    Example: Plant instructions in a test email, web page, document or tool result and check the agent does not act on them. Try data exfiltration and tool misuse. Re-run on every model, prompt or tool change.

    Does not stop: Passing your tests does not prove the agent is safe; it shows it resists the attacks you thought of.

    LLM01 Prompt InjectionASI01 Agent Goal HijackPractise: Agent Prompt-Injection Harness Lab
  • Should have
    A guardrail regression suite

    Why: Model and prompt changes silently weaken guardrails. A fixed test set shows when they do.

    Example: Keep a set of attack and benign cases; track how many attacks are blocked and how many benign requests are wrongly refused; fail the release if either gets worse.

    Does not stop: Only covers the cases in the set.

    ASI01 Agent Goal HijackLLM01 Prompt Injection
  • Consider
    Review permissions on a schedule

    Why: Agents collect tools and scopes over time. Access that is no longer needed is risk with no benefit.

    Example: Every quarter, list each agent’s tools, scopes and credentials, remove what was not used, and confirm an owner for each agent.

    Does not stop: Does not catch misuse of access that is still needed.

    ASI03 Identity and Privilege AbuseLLM06 Excessive Agency
TL;DR

What this tool is

  • Describe your agent in six answers: what it reads, what it can do, how much it acts alone, the most sensitive data it touches, who uses it, and whether it uses third-party tools or memory.
  • Get a tailored plan from 26 guardrails in six layers: input, tool and permission, action, output, monitoring and response, and evaluation. Each is marked must have, should have or consider.
  • Every guardrail says why it matters, gives a concrete example, and says plainly what it does not stop. Prompt-injection filters are treated as one layer, not a fix.
  • You get a risk level from Low to Critical with the reasons, a warning when the agent combines private data, untrusted content and a way to send data out, and a map to the OWASP Top 10 for LLM Applications 2025 and the OWASP Top 10 for Agentic Applications 2026.
  • Tick what is already in place and copy the plan as a plain-text report for a design review or a ticket. Runs in your browser; nothing is uploaded.

AI agent guardrails by layer, with examples

These are all 26 guardrails the planner draws from. Each one lists what it is for, an example, what it does not stop, and the OWASP entries it addresses. LLMxx:2025 refers to the OWASP Top 10 for LLM Applications 2025; ASIxx to the OWASP Top 10 for Agentic Applications 2026.

Input guardrails

What reaches the model, and how untrusted content is marked.

  • Mark untrusted content as data, not instructions. A model cannot reliably tell an instruction from text it was asked to read. Content from the web, email, documents or tools can contain instructions aimed at the agent. Example: Wrap every fetched page, email or tool result in clearly labelled delimiters, state in the system prompt that nothing inside them is an instruction, and strip hidden text such as HTML comments and white-on-white text first. Does not stop: The model can still follow instructions inside the delimiters. Separation lowers the odds; it is not a boundary. (LLM01:2025 Prompt Injection; ASI01 Agent Goal Hijack)
  • Screen inputs for prompt injection. A classifier or rule set catches known injection patterns before they reach the model, and gives you a signal to log and alert on. Example: Run each inbound email and retrieved document through an injection detector; quarantine high-scoring items for review instead of passing them to the agent. Does not stop: Not a complete defence. New phrasing, other languages, encoded text and instructions inside images get through, and benign text gets blocked. OWASP says it is unclear whether fool-proof prevention exists. (LLM01:2025 Prompt Injection; ASI01 Agent Goal Hijack)
  • Lock the system prompt, and keep secrets out of it. The system prompt sets the agent’s goal, scope and permitted actions. Users and injected text can often get the model to reveal it. Example: State the allowed tasks and what the agent must refuse. Put API keys, internal URLs and access rules in code, not in the prompt. Version the prompt and review changes. Does not stop: A system prompt is guidance, not enforcement. A jailbreak can override it, and its text should be assumed public. (LLM07:2025 System Prompt Leakage; ASI01 Agent Goal Hijack)
  • Permission-aware retrieval. A shared document index can return files the person asking is not allowed to see, and anyone who can add a document can plant instructions in it. Example: Filter retrieval by the requesting user’s access rights at query time, restrict who can add to the index, and record the source of every chunk the agent uses. Does not stop: Does not stop an authorised, legitimate-looking document that contains injected text. (LLM08:2025 Vector and Embedding Weaknesses; LLM02:2025 Sensitive Information Disclosure)
  • Validate and expire what goes into memory. Memory turns a one-off injection into a lasting one: a poisoned note is replayed into every later session. Example: Only save facts the user confirms, tag each memory with its source and an expiry date, keep memory separate per user, and let users see and delete what is stored. Does not stop: Does not catch poisoned content that looks legitimate when it is saved. (ASI06 Memory & Context Poisoning)
  • Authenticate and validate messages between agents. A message from another agent is untrusted input. Without authentication, a spoofed or replayed message can redirect the agent. Example: Give each agent its own credentials, sign or mutually authenticate messages, validate them against a typed schema, and treat their content as data. Does not stop: Does not help when a properly authenticated agent has itself been hijacked. (ASI07 Insecure Inter-Agent Communication)

Tool and permission guardrails

What the agent can reach, with which credentials, and how much.

  • Give it only the tools the task needs. Excessive agency is too much functionality, too many permissions or too much autonomy. Every tool you remove is an action a hijacked agent cannot take. Example: An inbox-triage agent gets “read message” and “apply label”, not “send”, “forward” or “delete”. Remove general-purpose tools such as a raw shell or open HTTP client unless the task needs them. Does not stop: Does not stop misuse of the tools that remain. (LLM06:2025 Excessive Agency; ASI02 Tool Misuse and Exploitation)
  • Scoped, short-lived credentials per agent. If the agent runs on a shared admin key, a hijack inherits everything that key can do. A narrow, expiring credential caps the damage. Example: Give the agent its own identity. Issue tokens scoped to one mailbox, one repository or one project, expiring within the task. Where possible, act with the signed-in user’s permissions, not a service account’s. Does not stop: Does not stop abuse of what the scope allows. (ASI03 Identity and Privilege Abuse; LLM06:2025 Excessive Agency)
  • Allowlist destinations and validate tool parameters. Most damage needs a destination: a recipient, a payee, a URL. A fixed list of allowed destinations blocks the attacker’s own. Example: Email only to your own domain or known contacts; fetch only approved domains; pay only existing payees; reject any tool call whose parameters fail a strict schema. Does not stop: Does not stop abuse through an allowed destination, such as an allowed site that hosts user content. (LLM06:2025 Excessive Agency; ASI02 Tool Misuse and Exploitation)
  • Rate, spend and volume limits. Limits turn a runaway loop or a hijack into a bounded incident, and stop one user exhausting your model budget. Example: A daily spend cap per agent, a maximum number of messages per hour, a cap on tool calls and tokens per task, and per-user request limits; pause the agent and alert when one is hit. Does not stop: Does not stop damage that stays under the cap, or slow, patient abuse. (LLM10:2025 Unbounded Consumption; ASI08 Cascading Failures)
  • Run code in a sandbox with no standing access. Generated code does whatever it is written to do. Running it next to your credentials or network turns an injection into code execution on your systems. Example: An isolated container or VM per session: not root, no credentials, read-only mounts, CPU and time limits, outbound network denied or limited to an allowlist (block the cloud metadata address), destroyed afterwards. Never pass model output to eval or a shell directly. Does not stop: Does not stop sandbox escape bugs, or misuse of data you put inside the sandbox. (ASI05 Unexpected Code Execution (RCE); LLM05:2025 Improper Output Handling)
  • Vet and pin third-party tools and MCP servers. A tool’s description is read by the model, so a malicious or changed description can steer the agent. An update can change behaviour after you approved it. Example: Install from sources you trust, read every tool description, pin versions or hashes, alert when a tool’s description or schema changes, and keep a list of what each agent uses. Does not stop: Does not stop a trusted tool that is compromised upstream after you pinned it, until the next review. (LLM03:2025 Supply Chain; ASI04 Agentic Supply Chain Vulnerabilities)
  • Close the ways data can get out. Private data plus untrusted content plus a way out is the combination that lets an injected instruction leak data. Removing the way out breaks it. Example: Do not let the agent fetch arbitrary URLs (data can ride in the URL), do not render images or links from untrusted sources in its replies, and route all outbound traffic through an allowlisting proxy. Does not stop: Does not stop leaks through channels you allow, such as a reply to the user or a message to an allowed recipient. (LLM02:2025 Sensitive Information Disclosure; ASI01 Agent Goal Hijack)

Action guardrails

Checks between the decision and the effect.

  • Human approval for high-impact actions. A person who sees the exact action can catch what the model got wrong or was tricked into. OWASP lists approval for high-risk actions as a prompt-injection mitigation. Example: Before sending, paying or changing anything that matters, show the exact recipient and text, the payee and amount, or the diff, and require an explicit click. Approval is per action, not per session. Does not stop: Does not stop approval fatigue, rubber-stamping, or a summary written to mislead the approver (human-agent trust exploitation). (LLM06:2025 Excessive Agency; ASI09 Human-Agent Trust Exploitation)
  • A policy check outside the model. Rules enforced in code cannot be talked out of. Every tool call passes a deterministic check before it runs, whatever the model decided. Example: A policy gateway checks each call: amount under the limit, recipient on the allowlist, resource tagged as non-production, user entitled to the record. Calls that fail are blocked or sent for approval. Does not stop: Does not stop cases your rules did not anticipate, or bugs in the rules. (LLM06:2025 Excessive Agency; ASI02 Tool Misuse and Exploitation; ASI08 Cascading Failures)
  • Dry run and preview before execute. A preview shows what will change before it changes, so a person or a check can stop it. Example: Produce an infrastructure plan before applying it; show the rows a query would update before committing; save an email as a draft first. Block any state-changing call during the preview. Does not stop: Does not help if the reviewer does not read the preview, or if the real run differs from the preview. (ASI09 Human-Agent Trust Exploitation; ASI08 Cascading Failures)
  • Prefer reversible actions, and keep an undo. If you can roll an action back, a mistake costs time instead of data or money. Example: Soft-delete instead of hard-delete, versioned storage, backups before bulk changes, drafts instead of sends, and a documented rollback for each infrastructure change. Does not stop: Some actions cannot be undone: a sent message, a completed payment, leaked data. (ASI08 Cascading Failures)

Output guardrails

What leaves the agent: answers, messages, generated code.

  • Filter outputs for sensitive data. Data the agent can read can end up in its answer or in a message it sends, by mistake or because it was told to. Example: Scan replies and outbound messages for secrets, card numbers and personal data patterns; redact or block before they leave; never put data the user is not entitled to into the context in the first place. Does not stop: Does not catch data that is paraphrased, encoded or split across messages. (LLM02:2025 Sensitive Information Disclosure)
  • Treat model output as untrusted downstream. Output passed to a database, browser or shell can become an injection attack on that system. Example: Use parameterised queries, escape HTML before rendering, validate generated code and config before use, and never pass output straight to a shell or eval. Does not stop: Does not stop output that is well-formed but harmful, such as a valid query that deletes the wrong records. (LLM05:2025 Improper Output Handling)
  • Policy and grounding checks on answers. Public-facing agents are held to what they say. A confident wrong answer about a refund or a policy is a real commitment to a customer. Example: Check replies against a content policy; require factual claims to cite a retrieved source; route answers about money, legal terms or health to a person; label replies as AI-generated. Does not stop: Does not catch a wrong answer that passes the checks. Grounding reduces errors; it does not remove them. (LLM09:2025 Misinformation)

Monitoring and response

Seeing what the agent did, and stopping it.

  • Log every prompt, tool call and approval. Without a trace you cannot tell what the agent did, why, or what an attacker reached. Example: One trace per task with every model call, tool name, parameters, result size, approver and outcome. Store logs where the agent cannot edit them, and protect them: they contain sensitive data. Does not stop: Logging prevents nothing. It lets you see, investigate and prove what happened. (ASI10 Rogue Agents; ASI09 Human-Agent Trust Exploitation)
  • Alert on unusual behaviour. A hijacked agent behaves differently from its normal pattern: new destinations, bursts of calls, data it does not usually touch. Example: Alert on a first-seen recipient or domain, a spike in tool calls, access outside the usual records, repeated denied approvals or blocked policy checks, and injection-screen hits. Does not stop: Does not catch abuse that looks like normal use. (ASI10 Rogue Agents; ASI08 Cascading Failures)
  • A kill switch and credential revocation. When something goes wrong you need to stop the agent in seconds, not after a deploy. Example: One switch that halts all runs of this agent, a tested way to revoke its tokens, and a short runbook for who decides and what to preserve. Does not stop: Does not undo actions already taken. (ASI10 Rogue Agents)

Evaluation

Testing that the guardrails hold, before launch and after every change.

  • Red-team with indirect prompt injection. You only know a guardrail holds if you have tried to break it the way an attacker would: through the content the agent reads. Example: Plant instructions in a test email, web page, document or tool result and check the agent does not act on them. Try data exfiltration and tool misuse. Re-run on every model, prompt or tool change. Does not stop: Passing your tests does not prove the agent is safe; it shows it resists the attacks you thought of. (LLM01:2025 Prompt Injection; ASI01 Agent Goal Hijack)
  • A guardrail regression suite. Model and prompt changes silently weaken guardrails. A fixed test set shows when they do. Example: Keep a set of attack and benign cases; track how many attacks are blocked and how many benign requests are wrongly refused; fail the release if either gets worse. Does not stop: Only covers the cases in the set. (ASI01 Agent Goal Hijack; LLM01:2025 Prompt Injection)
  • Review permissions on a schedule. Agents collect tools and scopes over time. Access that is no longer needed is risk with no benefit. Example: Every quarter, list each agent’s tools, scopes and credentials, remove what was not used, and confirm an owner for each agent. Does not stop: Does not catch misuse of access that is still needed. (ASI03 Identity and Privilege Abuse; LLM06:2025 Excessive Agency)

Agentic AI security risks: the OWASP Top 10 for Agentic Applications 2026

Published by the OWASP GenAI Security Project’s Agentic Security Initiative (Version 2026, December 2025). The one-line summaries are ours; read the OWASP document for the full descriptions, examples and mitigations.

  • ASI01 Agent Goal Hijack. Content the agent reads redirects its goal, so it works for the attacker while appearing to serve the user.
  • ASI02 Tool Misuse and Exploitation. The agent uses legitimate tools in harmful ways: wrong recipient, wrong record, too many calls.
  • ASI03 Identity and Privilege Abuse. Delegation chains, inherited credentials or cached context are abused to escalate the agent’s access or act without authorisation.
  • ASI04 Agentic Supply Chain Vulnerabilities. Third-party tools, MCP servers, plugins, prompts or models the agent depends on are malicious or change underneath it.
  • ASI05 Unexpected Code Execution (RCE). Code the agent generates or is tricked into running executes on your systems.
  • ASI06 Memory & Context Poisoning. Poisoned memory or context persists and steers later sessions.
  • ASI07 Insecure Inter-Agent Communication. Messages between agents are spoofed, tampered with or replayed.
  • ASI08 Cascading Failures. A single fault, such as a hallucination, malicious input or poisoned memory, spreads across agents, tools and workflows into system-wide harm.
  • ASI09 Human-Agent Trust Exploitation. The agent’s fluency and apparent expertise lead people to over-trust it, and approve actions or share information without checking.
  • ASI10 Rogue Agents. A malicious or compromised agent drifts from its intended function or scope, often through actions that each look legitimate.

The model-level risks underneath come from the OWASP Top 10 for LLM Applications 2025: LLM01:2025 Prompt Injection, LLM02:2025 Sensitive Information Disclosure, LLM03:2025 Supply Chain, LLM04:2025 Data and Model Poisoning, LLM05:2025 Improper Output Handling, LLM06:2025 Excessive Agency, LLM07:2025 System Prompt Leakage, LLM08:2025 Vector and Embedding Weaknesses, LLM09:2025 Misinformation, LLM10:2025 Unbounded Consumption. For agents the most relevant are LLM01 Prompt Injection and LLM06 Excessive Agency, whose three root causes OWASP names as excessive functionality, excessive permissions and excessive autonomy.

Why prompt-injection filters are not enough

A model reads instructions and data through the same channel, so it cannot reliably tell them apart. OWASP’s LLM01 guidance says it is unclear whether fool-proof prevention for prompt injection exists. Filters, classifiers and delimiters are still worth having: they catch known patterns and give you something to alert on. But plan as if some injected text will get through, and make sure that when it does, the agent cannot do much with it.

The combination to break is what Simon Willison called the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. An agent with all three can be told, by a web page or an email, to send your data somewhere. Removing any one leg closes that path, and the way out is usually the easiest to remove. The planner flags the trifecta when your answers add up to it. To practise the decisions, try the Policy Gateway Lab and the Agent Tool-Scope Lab.

Frequently asked questions

What are AI agent guardrails?

Controls around an AI agent that limit what it reads, what it can do, what it sends out and how fast, and that let you see and stop it. They sit in layers: input (how untrusted content is handled), tools and permissions (least privilege, scoped credentials, allowlists, spend and rate limits), actions (human approval, a policy check in code, dry runs, reversibility), output (data-leak filtering, safe handling downstream), monitoring (logs, alerts, a kill switch) and evaluation (red-team tests). No single layer is enough on its own.

What are examples of AI guardrails?

An email agent that can draft but not send without a click. A support bot whose refund tool is capped at a fixed amount and only pays the original card. A coding agent that runs code in a container with no credentials and no open internet. A research agent that cannot fetch arbitrary URLs, so injected text cannot smuggle data out in a link. Tokens scoped to one mailbox that expire after the task. A switch that stops every run of an agent at once.

How do you implement guardrails for AI agents?

Start from what the agent can do, not from filters. Remove every tool the task does not need, give it its own short-lived, narrowly scoped credentials, and put a deterministic policy check and, for high-impact actions, a human approval in front of each tool call. Then mark untrusted content as data, filter outputs for sensitive data, log every tool call, add a kill switch, and red-team it with instructions planted in emails, web pages and documents before launch and after every change.

What are the security risks of agentic AI?

The OWASP Top 10 for Agentic Applications 2026 lists them: ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution (RCE), ASI06 Memory & Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation and ASI10 Rogue Agents. In practice the biggest risk is an agent that reads untrusted content and also holds the permissions to act on it.

Can guardrails stop prompt injection?

Not completely. OWASP’s guidance on LLM01 Prompt Injection says it is unclear whether fool-proof prevention exists. Input filters and delimiters reduce the odds but miss new phrasing, encoded text and instructions in images. What reliably limits the damage is design: give the agent less to misuse, keep a person or a rule in code in front of high-impact actions, and close the channels that could carry data out.

What is the OWASP Top 10 for Agentic Applications?

A list of the ten most critical security risks for AI agents that plan, use tools, keep memory and work with other agents, published by the OWASP GenAI Security Project’s Agentic Security Initiative as Version 2026 in December 2025. Its entries use the IDs ASI01 to ASI10. It builds on the OWASP Top 10 for LLM Applications 2025, which covers the model-level risks (LLM01 to LLM10).

The tools people use most on PlayCISO.

All tools
🎉 New here? Use code WELCOME10 for 10% off any plan at checkout