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.
Your guardrail plan (18 items)
Input guardrails
What reaches the model, and how untrusted content is marked.
- Must haveMark 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 haveValidate 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 haveScreen 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.
- Should haveLock 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 haveGive 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.
- Must haveScoped, 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 haveAllowlist 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 haveClose 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 haveRate, 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 haveHuman 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 haveA 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 haveFilter 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 haveLog 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.
- Should haveAlert 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 haveA 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.
ASI10 Rogue AgentsPractise: Agent-IR Tabletop Lab
Evaluation
Testing that the guardrails hold, before launch and after every change.
- Must haveRed-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.
- Should haveA 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 - ConsiderReview 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
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).
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.