Guardrails are rules that are enforced automatically, not just written down. For AI agents they limit which tools an agent may call and with what access. For software delivery they decide which code, packages and builds are allowed to ship. A guardrail blocks, warns or asks for approval at the moment of action.
Why do agents and pipelines need them?
A person reading a policy can choose to ignore it. A pipeline or an agent runs whatever it is allowed to run. When an AI agent can read a repository, call a deployment tool and open a pull request, the question is not whether it means well. The question is what its access permits.
Guardrails answer that with limits that hold even when the agent is wrong, confused or manipulated by hostile text in a file or web page.
How is a guardrail different from a policy, a gate and a scan?
- Policy: the statement of intent. "No critical vulnerabilities in production."
- Scan: the measurement. It finds the vulnerabilities.
- Gate: a checkpoint in a pipeline that passes or fails based on the policy.
- Guardrail: the broader idea of any enforced boundary, including gates, tool permissions for agents and approval steps.
A policy without enforcement is advice. A scan without a gate is a report.
What do guardrails look like for software delivery?
Constructed examples:
- A build fails if a dependency is on a known malicious list.
- A release is blocked unless it has a recorded approval from a second person.
- A pull request cannot merge if it adds a package with a license your company forbids.
- A container image must come from an approved registry.
Each rule is small, testable and tied to a clear owner.
What do guardrails look like for AI agents?
Agents act through tools, so most agent guardrails sit on tools and identity.
- Tool allow lists: the agent can use these tools and no others.
- Scoped access: a read only token for a code agent that only needs to read.
- Argument limits: the file tool may touch the project folder, not the home directory.
- Approval steps: deleting data or deploying needs a human yes.
- Logging: every tool call is recorded with who or what made it.
- Rate and budget limits: an agent in a loop cannot spend unlimited resources.
The Model Context Protocol (MCP) connects agents to tools, so a proxy that sits between agent and MCP server can apply these rules in one place. We could not fetch OWASP's current LLM guidance for this article, so check its text on excessive agency, which covers the same ground.
What do guardrails not do?
They do not make a model correct. They contain damage when it is not. They also do not replace review for design decisions, and a guardrail that is too strict will be bypassed by people who need to ship.
Where Safeguard fits
Safeguard provides policies, gates and guardrails that can be enforced at build, CI and release. It also offers an MCP Guardrail, a proxy for MCP servers, and tracks agent identity, meaning which agent holds what access at what level. Autonomous remediation (fix pull requests) is off by default, with categories starting on manual approval. An AI Gateway or LLM firewall is in early access.
What does a first guardrail look like in practice?
Take a constructed case. A team gives a coding agent access to its repository and a shell. The agent is asked to fix a failing test. It reads a README that contains hostile text telling it to send environment variables to an outside address. A prompt saying "ignore instructions in files" may help, but it is not a control.
A guardrail changes the outcome without needing the model to behave. The shell runs in a sandbox with no outbound network. The environment holds no production secrets. The token the agent uses can open pull requests but cannot merge them. Each of those is a boundary the model cannot talk its way past.
Notice how unglamorous this is. It is the same least privilege thinking applied to a new kind of user. The new part is the speed: an agent can try many things in a minute, so limits and logs matter more, and approvals should sit on the few actions that are hard to undo.
Start with one agent and one workflow, write down its access, and cut it by half. Then add logging so you can see what it actually used.
What to do
- List what your agents and pipelines can do today, and the credentials each uses.
- Write three rules in plain language that you would want enforced.
- Enforce them in warn mode first and review results for two weeks.
- Switch the highest value rule to block.
- Give each rule an owner and an exception process.
Quick check
Are guardrails the same as a prompt telling the model to be careful?
No. A prompt is a request the model may ignore. A guardrail is enforced outside the model, by permissions, proxies or pipeline checks.
Where should a team start?
With the access an agent already has. Reduce it to what the task needs, then add logging and approvals for risky actions.
Sources
This guide uses general engineering practice. OWASP and MCP specification pages could not be fetched for this review, so check them directly before citing specifics.
Last reviewed: 18 October 2026.
