Guardrails are rules enforced at the moment of action: an agent may not call this tool, a build may not ship with that flaw, a release may not go without approval. You can build them with policy code, proxies and pipeline checks. Buying pays off when rules multiply across many teams and tools.
What is a guardrail, exactly?
A guardrail is a control that decides, automatically, whether an action proceeds. It is different from guidance or review. Two families matter here. Delivery guardrails act on software: block a merge, fail a build, hold a release. Agent guardrails act on AI agents: allow or deny a tool call, limit arguments, require human approval, log everything.
OWASP lists Excessive Agency among the Top 10 for LLM applications, and describes it as systems given more autonomy or permissions than they need. Guardrails are how you turn that warning into enforced limits.
What can you build yourself?
For delivery, quite a lot. A CI job can run a scanner and fail on a rule. A policy engine can evaluate manifests before deploy. Branch protection can require review. These are well understood and many teams run them.
For agents, a thin proxy in front of a tool server can check each call against an allow list, strip dangerous arguments, and write an audit line. It is a few weeks of work for one tool server and one team.
A constructed example, not a real team: a platform team writes a CI step that fails builds containing a banned license or a vulnerable dependency flagged as reachable, and a small proxy that lets an internal assistant read tickets but not close them. Works well, with one maintainer.
Where does building get expensive?
Rule sprawl. Each team wants exceptions. Without a model for rules, exceptions and expiry, the policy folder becomes a pile of special cases.
Coverage. A guardrail in one pipeline does nothing for the team that uses another. A proxy on one tool server does not cover the next.
Evidence. Auditors and incident responders need to know which rule fired, who overrode it, and why. That needs storage, search and review screens.
Keeping up. New agent protocols, new tool servers and new attack patterns appear steadily. Someone must follow them.
Safety of the guardrail itself. A guardrail that fails open hides danger, and one that fails closed halts work. Both need tests.
What does buying give you?
A shared policy model across pipelines and agents, with exceptions that expire. A central log of decisions. Integrations already built for common CI systems and tool servers. And someone else keeping up with changes.
What you still own: the rules themselves. A product cannot decide how much risk your business accepts.
How do you decide?
Count three things: pipelines, agent tool servers and teams. If you have one of each, build. If you have a dozen pipelines, several tool servers and teams that disagree about rules, buy or adopt a shared platform.
Test failure behavior in either case. Break the guardrail on purpose and see what happens.
Where Safeguard fits
Safeguard offers policies, gates and guardrails enforceable at build, CI and release, and MCP Guardrail, a proxy for MCP servers. Both are generally available. Autonomous remediation, which opens fix pull requests, is off by default with categories starting on Manual. An AI Gateway or LLM firewall is early access only.
What should you test before trusting any guardrail?
Write three tests for each rule: one input that must be blocked, one that must pass, and one that probes the edge. Run them in CI so a change to the policy cannot silently weaken it. Then test failure: stop the policy service and see whether builds halt or slip through, and kill the agent proxy and see what the agent can still reach directly. Keep the results. They double as evidence for auditors and as a regression suite when you switch tools, which is the strongest argument for writing rules in plain, portable form.
What to do
- List your pipelines, tool servers and teams.
- Write the top ten rules in plain words, each with an owner.
- Add an expiry to every exception from day one.
- Prototype one delivery guardrail and one agent guardrail yourself.
- Break each one on purpose and record how it fails.
- Decide build or buy using the counts in step 1.
Quick check
What is the difference between a guardrail and a review?
A review relies on a person noticing. A guardrail is enforced automatically at the time of the action, though people still write the rules and handle exceptions.
Should a guardrail fail open or closed?
It depends on the action. For high impact actions, fail closed. For low impact ones, failing open with an alert may be acceptable. Decide per rule and test it.
Sources
Last reviewed: 18 October 2026.
