Agent Security › Guardrails
Guardrails gets used to mean several different things. Instructions, detection and genuinely enforced boundaries are not the same, and for the things that matter you need the one the agent cannot negotiate with.
"Put guardrails around the AI."
It's becoming one of the most common pieces of advice given to businesses using AI agents. But what does it actually mean?
A guardrail might be an instruction telling an agent not to do something, a safety mechanism built into the AI model, a rule checking an agent's output, a permission restricting access to a system, an approval step before an action happens, or a technical control that makes an action impossible.
Those aren't the same thing. And when AI agents can access business systems and take real actions, the difference matters.
Telling an agent not to do something is not the same as preventing it from doing it. Good agent security needs both instructions and controls. But we need to know which is which.
AI agent guardrails are rules, controls and boundaries designed to keep an AI agent operating within an intended scope.
They can help control what information an agent accesses, what tools it uses, which actions it performs, what information it sends, how much it spends, who it communicates with, when it requires human approval, which systems it can reach, how long it operates and what happens when something unexpected occurs.
The important thing is that different guardrails provide very different levels of protection. A useful way to think about them is as three layers.
All three can be useful. But only the third creates a boundary the agent cannot simply choose, misunderstand or be manipulated into crossing.
The simplest guardrail is an instruction. For example: never send an email without human approval. Or: do not access financial information. Or: only use information from the customer's account.
These instructions might appear in system prompts, agent instructions, workflow descriptions, policies, tool descriptions, memory or other context supplied to the model.
Instructions are important. They tell the agent how it is expected to behave. But they shouldn't automatically be treated as security boundaries.
AI systems don't execute instructions in the same deterministic way traditional software executes a rule. An agent may misinterpret an instruction, encounter conflicting instructions, receive malicious instructions through external content, operate in a situation the instruction didn't anticipate, make an incorrect judgement about an exception, or pursue its main objective in an unexpected way.
Imagine an agent is told: never send customer information outside the company. But the same agent has access to customer records, browser access, email access and the technical ability to upload files. The instruction is useful. But the underlying capabilities still exist.
If protecting customer information genuinely matters, the stronger question is: why does this agent technically have the ability to send that information somewhere it shouldn't?
Imagine an office containing confidential files. A sign on the door says: staff must not remove confidential documents. That's a policy.
Now imagine the files are stored inside a locked cabinet accessible only to authorised employees. That's a control.
You probably want both. The sign communicates the rule. The lock makes the rule harder to violate. Agent security works in much the same way. Prompts can describe expected behaviour. Permissions and technical controls enforce boundaries.
The second layer attempts to identify problematic behaviour. These systems might monitor inputs, outputs, tool requests, actions, destinations, data, spending or patterns of behaviour.
For example, a monitoring system might detect an agent trying to send sensitive data externally, repeated denied access attempts, an unusually large financial transaction, unexpected tool usage, an attempt to access a restricted system, or content that appears to contain prompt injection.
Detection is valuable because not every dangerous situation can be anticipated in advance. But detection creates another question: what happens after something is detected?
An alert that nobody sees for six hours isn't necessarily much protection against an autonomous agent operating in seconds. Detection therefore needs a response. That response might block the action, request approval, pause the workflow, restrict the agent, revoke credentials, or stop the agent entirely.
Enforcement guardrails sit outside the agent's own decision-making wherever possible. They determine what the agent is technically able to do.
Imagine an agent has this rule: never spend more than £100 without approval. There are two ways to implement it. Option A: put the rule in the agent's instructions. Option B: configure the payment system so transactions above £100 physically require approval from an authorised person.
Option B creates the stronger security boundary. Even if the agent misunderstands the rule, forgets the rule, is manipulated, receives conflicting instructions, or decides the payment is necessary to achieve its goal, the transaction still cannot happen without approval.
The agent cannot negotiate with the boundary. That's what we want for consequential actions.
Not every rule needs a hard technical boundary. But the more consequential the action, the stronger the case for one. Examples include:
The key principle is: if crossing a boundary could create serious consequences, don't rely solely on the agent remembering the boundary exists.
Guardrails shouldn't be designed separately from permissions. Imagine a marketing agent. It can READ the CRM, CHANGE campaign fields and PREPARE emails, but cannot SEND them without approval. The permission model creates the underlying authority. The guardrails then enforce additional conditions: only send to approved customer segments, never include restricted customer information, no more than X messages per hour, campaigns above X recipients require approval, do not contact opted-out customers.
Permissions answer: what can this agent do? Guardrails answer: under what conditions can it do it?
Human approval is itself a form of control. But approval works best when it is placed at meaningful boundaries. Requiring approval before every web search would make a research agent almost pointless. Requiring approval before it sends an email to 10,000 prospects is very different.
The objective isn't human approval everywhere. It is human approval where consequences justify it. A useful pattern is: low consequence, autonomous; moderate consequence, monitor; high consequence, approval; very high or irreversible, strong technical control plus approval. The exact boundaries depend on the organisation and the task.
Prompt injection shows why instructions alone aren't enough. Imagine a research agent reading a webpage. Hidden inside that page is an instruction telling the agent to ignore its task, retrieve information from another system, and send that information somewhere else.
Ideally, the agent recognises the malicious instruction and ignores it. But agent security shouldn't depend entirely on that happening every time. If the research agent cannot access the sensitive system, or cannot send data to an unapproved destination, then the consequences of successful manipulation are reduced.
This is called reducing the blast radius. You may not be able to guarantee that an agent will never process a malicious instruction. You can limit what happens afterwards.
Technical controls aren't magically perfect. A guardrail can fail because the rule is badly configured, the wrong permission is granted, an integration behaves differently than expected, a third-party system changes, credentials are too broad, an alternative route exists, another agent has greater authority, monitoring isn't functioning, or the control itself contains a vulnerability.
That's why agent security shouldn't rely on one magical safety mechanism. It needs layers.
A high-consequence action might have several controls. Imagine an AI finance agent:
Now a single failure doesn't automatically become a financial incident. That is defence in depth.
Some agent policies are written almost entirely as prohibitions. Don't reveal confidential information. Don't send unauthorised emails. Don't change production systems. Don't spend more than £500. Don't delete files. Don't access HR information.
These rules may all be sensible. But every important "don't" should trigger another question: what actually prevents it?
Sometimes the answer will legitimately be that the model instruction is sufficient because the consequence is low. For consequential actions, the answer should increasingly involve something outside the prompt.
Another common approach is: give the agent all the tools it might need, then use instructions to tell it which ones it should use. That creates unnecessary authority.
If an agent should never make a payment, why give it a payment tool? If it should never delete records, why provide delete permission? If it only needs one folder, why connect the entire drive?
A tool that doesn't exist in the agent's environment is a much stronger restriction than "please don't use this tool."
A useful starting principle for higher-risk agents is: if the agent doesn't need it, don't give it. New systems: deny. New tools: deny. New destinations: deny. New authority: deny. Then explicitly grant what the agent needs.
This is the opposite of connecting everything and trying to write enough instructions to control it afterwards.
A good guardrail shouldn't simply produce an error where possible. The agent needs to know what happens next.
This allows the agent to continue working without allowing it to bypass the control.
One blocked action may be innocent. Perhaps the agent selected the wrong tool. But imagine it tries System A, denied; then System B, denied; then an API, denied; then another agent, denied. Now the pattern becomes interesting.
The agent may simply be trying different ways to complete its task. But from a security perspective, repeated attempts to achieve an unauthorised action deserve attention. Monitoring shouldn't only ask: did the agent cross the boundary? It should also ask: how often is it pushing against it?
Businesses will increasingly use different models. An agent might run on one model today and another next year. The underlying security policy shouldn't disappear because the model changes.
If the business rule is that payments above £1,000 require approval, that should remain true whether the agent uses OpenAI, Anthropic, Google, an open model, or something that doesn't exist yet. This is another reason important controls should sit outside the model where possible. Your security policy should belong to your business, not your AI provider.
Multi-agent systems make guardrails harder. Imagine Agent A cannot access Finance, but Agent B can. Agent A asks Agent B to retrieve financial information. If Agent B simply trusts Agent A, the original restriction may become meaningless.
Guardrails therefore need to consider: who originated the request? Which agent is acting? Whose authority applies? What data can be returned? Can authority be delegated? Can one agent request an action it could not perform itself?
A secure multi-agent system can't assume: another agent asked, therefore it is authorised.
This is fundamental. An agent shouldn't generally be able to disable its own monitoring, increase its own spending limit, grant itself new permissions, change approval requirements, remove restricted destinations, alter security logs, create more powerful credentials, or deactivate the controls governing it.
The security layer needs independence from the system it controls.
Start with actions where a mistake would matter: money (payments, purchases, refunds, financial commitments); external communication (email, messaging, customer and supplier contact); public actions (publishing, social media, public websites); sensitive data (customer data, financial data, HR information, credentials, confidential documents); production systems (code deployment, databases, infrastructure, configuration); irreversible actions (deletion, account closure, data destruction); and authority (permissions, credentials, agent creation, delegation).
These are generally more important than trying to control every low-risk action an agent performs.
For each agent, ask:
If you're relying on "we told the agent not to" for something that could seriously affect your business, that's the place to look first.
As businesses use more agents, these controls become difficult to manage individually. One agent in your CRM, another in email, another on your website, another in finance, another across all four. Each system may implement permissions differently.
We think businesses will increasingly need an Agent Control Layer around those agents: identity, ownership, authority, permissions, approval, boundaries, monitoring and containment, in one place. That's what we're building towards with Agent Control. The objective isn't to surround agents with so many restrictions that they become useless. It's to make sure autonomy exists inside boundaries the business, not the agent, controls.
Agent Control is in build. Leave your email and we will let you know when it is ready.
When deciding whether an agent security measure is strong enough, ask: is this something we're asking the agent not to do, or something it genuinely cannot do?
Both have a place. But don't confuse them. Because as AI agents become better at reasoning, adapting and finding alternative routes to complete their goals, the difference between an instruction and a boundary becomes increasingly important.
Tell the agent what good behaviour looks like. Monitor whether it follows those expectations. And for the things that really matter, build boundaries it cannot negotiate with.