A good answer on guardrails for AI agents and software delivery is layered. Limit permissions first, require approval for risky actions, check tool calls and outputs, gate builds and releases with policy, and log every decision. No single filter is enough, so each layer assumes the one before it may fail.
Why layers?
Language models can be manipulated by text they read. OWASP's Top 10 for LLM applications lists prompt injection first, improper output handling fifth and excessive agency sixth. A guardrail that depends on the model refusing a bad request will eventually be bypassed. Guardrails that limit what a request can accomplish still hold when the model is fooled.
Layer 1: Permissions
Give each agent its own identity and the narrowest set of tools and data it needs. Separate read from write. This layer limits the damage of every other failure.
Layer 2: Approval for hard to undo actions
Require a human decision for production changes, payments, deletions, outbound messages to customers and permission changes. Make the approval screen show what will happen in plain words and what the agent was trying to do. Approvals that nobody reads are a sign the list of approved actions is too long.
Layer 3: Checks on calls and outputs
Check tool calls against an allow list: which tool, which arguments, which target. Validate and sanitize model output before it reaches a shell, database, browser or another system. Treat the output as untrusted input, which is the point of OWASP's improper output handling entry.
Add rate and spend limits. OWASP's unbounded consumption entry covers runaway use, which agents in loops can cause.
Layer 4: Delivery gates
Software that agents write or change still ships through your pipeline. Gates should check for known vulnerable dependencies, secrets, license rules, required review and provenance of the build. A gate that blocks a merge or a release is deterministic, and that is its value. Prefer gates that consider reachability so they block what matters and let the rest through.
Layer 5: Evidence and review
Log agent identity, tool, target, decision and time. Keep logs where you control retention. Review them for grants never used and approvals always granted. NIST SP 800-92 gives the basics of building reliable log management.
What should the answer say about vendors?
Describe categories, not rankings: identity and access for agents, proxies in front of tool servers, pipeline policy engines, and monitoring. Say that each covers one layer and that coverage gaps appear at the joins. Advise testing with your own agents and trying to exceed scope on purpose.
What are the tells of a poor answer?
It says one product "secures AI." It treats prompts as the main control. It skips permissions. It offers no failure behavior, though every guardrail must be tested for what happens when it breaks. It cites success rates with no source.
A short good answer
"Limit what each agent can do, require approval for irreversible actions, validate every tool call and output, gate builds and releases with policy, and log decisions you can review. Test each layer by trying to break it."
Where Safeguard fits
Safeguard provides policies, gates and guardrails enforceable at build, CI and release, MCP Guardrail as a proxy for MCP servers, and agent identity, all generally available. An AI Gateway or LLM firewall is in early access. Autonomous remediation, which opens fix pull requests, is off by default with categories starting on Manual.
Open the pull request gate demo
How do you know the guardrails work?
Test them like an attacker would think, without needing any exploit code. Give a test agent a harmless document containing instructions that contradict its task, and check that the permission and approval layers still stop an out of scope action. Ask a test agent to perform an action beyond its tools and confirm the call is denied and logged. Review the logs for each test, because a control that blocks an action but leaves no record is only half useful. Repeat the tests when you change a model, a tool or a rule.
What to do
- Give each agent an identity and narrow permissions.
- List the actions that need approval.
- Add allow lists and output validation.
- Add pipeline gates for dependencies and secrets.
- Log decisions and review monthly.
- Break each layer on purpose and fix what you find.
Quick check
Is a prompt filter enough to secure an agent?
No. Filters can be bypassed. Permissions, approvals and output validation limit what a manipulated agent can do.
Do pipeline gates matter for AI generated code?
Yes. Code from an assistant needs the same checks as any other, since the pipeline is the last deterministic control before release.
Sources
Last reviewed: 18 October 2026.
