AI guardrails are checks that sit between an AI agent and what it reads, says and does. They catch prompt injection, leaked secrets and personal data, data leaving for places it shouldn't and destructive commands, and stop or mask them before they take effect.
Autonomous runs six built-in detectors in real time on the prompts, tool calls and tool results of the AI agents your teams use, on their laptops and in the browser, behind its MCP Gateway and on your LLM gateway. Each detector allows, redacts or blocks, by one policy you watch in monitor mode before you enforce it.
An AI agent reads a ticket, a wiki page or a tool's answer and treats what it finds there as part of its task. Anyone who can write into those systems can write instructions for it, and the agent acts with the developer's own access.
A real session
Asked: Analyze this Jira issue.
The issue and the files attached to it held hidden instructions telling the assistant to call tools. It did, and a GitHub personal access token in a file it read was exposed.
In over 100,000 enterprise agent sessions, our research team saw about 4,000 prompt injection attempts, most of them arriving from Jira, Confluence and other systems people already trust; in 49 of them the agent went on to make a tool call. A review afterwards finds that too late. Guardrails check each piece of content when it arrives and each action before it runs.
Set guardrails to Monitor. Every prompt, tool call and tool result is scanned and each finding is logged as would block, while nothing is stopped. Give it days to a week of real traffic.
Choose the stages each detector checks, its action and its confidence threshold, 70 by default, down to the single kind of secret. Replay the saved policy over the last hour, day, week or month of recorded activity to see what it would catch.
Give the enforcing policy to one group from your identity provider, then to everyone. From then on actions are stopped or masked inline, and the Enforcement log shows them as blocked instead of would block.
A stage is a point where content is checked, from the prompt to the model's answer. Each detector checks the stages switched on for it and takes its action when it fires: allow, redact or block.
In prompts and tool results
Ships turned off
Each pattern at its own stages
Commands about to run, at Tool input · Observes until you opt in
Six detectors run in real time, each with its own switch, action, threshold and sub-detectors. A seventh scans skills and MCP servers for threats when they are analyzed, not as they run.
Instruction overrides, attempts to extract the system prompt, safety bypasses and role escalation. It reads prompts and tool results for instructions that try to take over the task, and blocks them before the agent acts on them. More below.
API keys, tokens and credentials, from cloud provider keys and source-control tokens to private keys. It redacts or blocks secrets in prompts, tool calls and tool results, masking just the key or token where it redacts. Each kind of secret can be tuned on its own.
Personal data such as card numbers, government IDs, email addresses and phone numbers. Turn it on when your agents handle customer or employee data: it masks the personal data it finds, and can block instead.
Data leaving through unauthorized URLs, blocked domains and encoded payloads. It checks tool calls and their results for data on its way out, a file uploaded with curl or a DNS lookup carrying data. A destination it keeps flagging that you trust can be marked trusted.
Invisible characters, bidirectional text overrides and look-alike letters, and hex, unicode-escape, HTML-entity and URL-encoded payloads. Text a person can't see but a model reads: zero-width characters, reversed text, a Cyrillic letter in a Latin word, or a payload hidden in an encoding.
Destructive shell commands such as wiping a disk or the system root, credential access, reverse shells, download-and-run patterns like curl | sh, and defense evasion. It checks a command before it runs, never text an agent read: a command in a file or a log is a mention, not an action. It allows by default; set it to Block to stop them.
Prompt injection is text that a model reads as instructions when it should read it as data. Direct injection comes from the person typing; indirect injection hides in what the agent reads on their behalf: a web page, a ticket, a document, a tool's answer.
For an agent, indirect injection is the dangerous kind. Its instructions arrive with the authority of the task: in our research they came from Jira, Confluence, Linear, Google Drive and Outlook, and led agents off task to hunt for credentials, or to run a shell command hidden in an encoded string.
The Prompt Injection detector checks prompts and what tools return, and blocks by default. The Encoding detector catches instructions hidden in characters people can't see. Through your LLM gateway, the same policy applies to model traffic, the tools' own descriptions included.
When the built-in detectors miss something only your organization knows, add a guardrail of your own: an internal project codename that must never reach a prompt, a data format of yours, or a rule easier to say in words than in a pattern.
Fast and exact, checked on the machine. A pattern that could hang on some input is refused when you save it.
An instruction in plain words, judged by a model: for when what you want to catch is a meaning, not a string.
Try sample content at any stage, or replay the saved policy over the last hour, day, week or month of your organization's activity, before it affects anyone.
Custom guardrails run on the endpoint agent and the LLM gateway, at the stages you choose, with their own action and threshold.
One policy covers every surface, so a stage you switch off stops being checked everywhere.
On macOS, Windows and Linux, around the AI agents your developers run, such as Cursor, Claude Code and Codex. It checks prompts, tool calls and tool results inline, through each agent's real-time hooks.
For AI used in a browser tab, such as ChatGPT, Claude and Gemini, the same guardrails apply when a prompt is submitted.
The MCP servers we host for you: each tool call's arguments are checked before it runs, and its result before the agent reads it.
Your LiteLLM proxy asks Autonomous to check each request and answer, so every stage is covered, the tools' definitions and the model's output included.
Running LiteLLM? Try LiteLLM guardrails. Everything else the platform covers is on the platform overview.
Controls that keep an AI system within limits you set, by checking what goes into it, what comes out and what it does. For AI agents, that means checking prompts, tool calls and tool results as they happen, and allowing, masking or blocking each one.
LLM guardrails check the traffic to and from a model. An agent also runs commands, reads files and calls tools on the machine, which never pass through a model's API, so Autonomous checks those where the agent runs too. On your own gateway, the same policy works as LiteLLM guardrails.
In monitor mode, nothing: it is a would-block entry to review. Raise the detector's confidence threshold, switch off the sub-detector or stage that misfires, or trust the destination the exfiltration detector keeps flagging, then replay recorded traffic to check before you enforce.
On their machine the action is stopped before it runs, with a message naming the policy: Blocked by and the name you give it, or organization guardrails policy. Through an LLM gateway, the call returns an error with the reason. A redaction masks only the matched text and lets the rest through.
Yes. Tool output, what a tool returned before the model reads it, is checked wherever agents call tools, for MCP and built-in tools alike. Behind the MCP Gateway, each call's arguments are checked before it runs and its result after.
Yes. A custom guardrail matches a regular expression or follows an instruction in plain words, judged by a model, at the stages you choose and with its own action. Test it on sample content or replay it over your recorded activity before it affects anyone.
No. PII ships turned off, so turning guardrails on never starts masking personal data by surprise. Turned on, it masks card numbers, government IDs, email addresses and phone numbers by default, and can block instead.
Not unless you choose to. Every new policy and guardrail starts off or in monitor mode, where activity is evaluated and logged but nothing is blocked. You move a policy to enforce when its findings look right, for a pilot group first.
Enterprise AI agents are repeating the Hugging Face breach patterns on developer endpoints right now. A study of 100k agent sessions revealed thousands of cases of autonomous credential hunting, indirect prompt injection via Jira/Confluence, and unsupervised production changes. Learn why agentic security requires continuous session monitoring, input guardrails, and brokered credentials.
Read More
We demystify AI guardrails, gateways, and everything in between, while clarifying what’s needed to ensure secure MCP operations.
Read More
In this post we're talking about the fact that the agentic and MCP layer is a blindspot to security teams and how to avoid it.
Read MoreTurn them on in monitor mode and see, on your own agents' traffic, what they would have stopped.
Book a demo