Choose guardrails by where they enforce, what they can block, and what they record. A guardrail that only warns is advice. For AI agents and software delivery, look for enforcement at the point of action, policy you can read and version, a managed exception path and logs an auditor can use.
What counts as a guardrail here?
Two families. Delivery guardrails act on code and builds: block a merge with a leaked secret, fail a release that pulls a package against policy, require a signed artifact. Agent guardrails act on what an AI agent may do: which tools it can call, with what arguments, on whose behalf. The two meet in pipelines, since agents now open pull requests and trigger builds.
Which criteria matter?
Enforcement point. Where does the check run? Before a tool call, at pull request, in CI, at release, at deploy? Earlier is cheaper to fix, later is harder to bypass. Many programs need more than one point.
Block versus warn. Ask for a per-rule mode. You will want to start in warn mode and move proven rules to block.
Policy as code. Can you read, review and version the rules in the same way as source? Opaque rules are hard to defend in an audit.
Context. Does the check know which agent or pipeline is acting, and what it is allowed to touch? Identity-aware guardrails give better decisions than ones that see only the payload. OWASP's Non-Human Identities Top 10 names overprivileged identities and long-lived secrets as risks that guardrails should help contain.
Exception path. Real work needs exceptions. Look for owner, reason and expiry on each, with a record of who approved it.
Evidence. Every allow, block and override should be logged with time, actor and rule. Check that logs can be exported.
Latency and failure mode. If the guardrail service is down, does the pipeline stop or run unchecked? Choose deliberately, and test it.
Fit with your stack. Ask about your CI system, your agent frameworks and the protocols you use, such as MCP. A tool that needs a rewrite of your pipeline will go unused.
Defense against bypass. Can a developer or an agent skip the check by changing a config file? Ask where policy lives and who can edit it.
A constructed example
A team lets an agent open pull requests. Their guardrails: a secrets check at pull request, a dependency policy in CI that blocks packages outside an approved list, and a rule that agent-created changes to deployment files need human review. A new dependency is blocked at CI, the team grants a 14-day exception with an owner, and the log shows both. The scenario is invented, but each element maps to a criterion above.
Tool or service?
A tool gives you control and needs staff to tune it. A service handles tuning but makes you rely on someone else's judgment. Ask who writes the rules in a service and how you challenge a decision.
How should you test before buying?
Run a pilot in warn mode on one repository and one agent. Measure noise: how many alerts you would have blocked, and how many were wrong. Then try to bypass it on purpose, with the vendor's help, and see if the attempt shows in logs.
Where Safeguard fits
Safeguard offers policies, gates and guardrails enforceable at build, CI and release, plus an MCP Guardrail that proxies MCP servers, and agent identity that tracks which agent holds what access. These are generally available. An AI Gateway or LLM firewall is early access. Compare them against the criteria here like any other option.
What to do
- List where agents and pipelines can act today.
- Pick the three riskiest actions and decide whether each should block or warn.
- Write policy as code and review it like source.
- Define the exception process before you roll out.
- Pilot in warn mode and measure noise.
- Test the failure mode and a bypass attempt.
Quick check
Should every rule block from day one?
No. Start in warn mode, measure false positives, then promote proven rules to block.
Do guardrails replace code review?
No. They catch known bad patterns at speed. People still review design and intent.
Sources
Last reviewed: 18 October 2026.
