Guardrail maturity for AI agents and software delivery moves through four stages: written rules, visible checks, enforced policy, and measured, self-correcting control. At each stage you can name what you have, what evidence proves it, and the one change that moves you to the next.
The model is an original working framework, not a standard. It is meant to help teams place themselves and pick a next step.
Stage 1: Rules on paper
You have a policy document and some habits. Developers know they should not commit secrets or pull random packages. Agents run with whatever access their creator had.
Evidence you are here: a policy exists, nobody can say how often it is broken.
Typical risks: shared credentials for agents, no inventory of tools agents may call, releases that depend on someone remembering a checklist.
Next move: make the rules visible. Pick three rules that matter most, such as no known exploited vulnerabilities in a release, no unapproved package sources, and no agent holding admin rights, and start measuring violations without blocking anything.
Stage 2: Visible checks
Checks run in CI and report. Dashboards show violations. Agents have been given their own accounts and a list of tools. Nobody is blocked yet.
Evidence: a weekly report of violations by rule and team, and an inventory of agents with owners.
NIST SP 800-53 control CM-8 asks for an accurate, complete inventory of components. This stage is where that inventory starts to carry weight, because every check needs something to check.
Typical risks: reports that nobody reads, and alert fatigue.
Next move: pick the clearest rule and enforce it in a limited place, such as one repository or one agent, with a recorded exception path.
Stage 3: Enforced policy
Chosen rules block or hold work. A release with a flagged component stops. An agent that tries to call an ungranted tool is refused and the attempt is logged. High impact agent actions, like changing pipeline configuration or deleting data, wait for human approval.
Evidence: blocked events with reasons, an exception register with owners and expiry dates, and an approval log for agent actions.
OWASP's LLM06, Excessive Agency, describes the risk of an LLM system holding more functionality, permissions or autonomy than needed. Enforced tool lists and approvals address it directly.
Typical risks: rules so strict developers route around them, and exceptions that never expire.
Next move: tune with data. Review what was blocked and what was excepted. Remove rules that fire without value and tighten ones that are bypassed.
Stage 4: Measured and self-correcting
Guardrails are treated like a product. They have owners, a change process and metrics. Findings from incidents become new rules. Reachability analysis keeps rules from blocking on unreachable code. Fix suggestions flow back to developers, and automation opens fix changes under human review.
Evidence: metrics on blocks, overrides and time to fix; a record of rules created after incidents; a review calendar.
NIST SP 800-137 treats continuous monitoring as a program with a strategy and ongoing assessment, which is the mindset at this stage.
Typical risks: complacency, and rule sprawl.
Next move: exercise it. Run a controlled test in which a harmless but policy-violating change is attempted, and verify it is stopped, logged and reviewed.
Dimensions to score separately
Programs often differ across areas. Score each from one to four.
- Dependencies and packages.
- Build and release pipeline.
- Secrets and credentials.
- AI agent tool access.
- AI agent identity and permissions.
A team may be at stage three for packages and stage one for agents. That is common and a useful finding.
What blocks progress most often
Missing inventory, no named owner for rules, and no exception process. Fix those three before buying more tooling.
Open the pull request gate demo
What to do
- Score each dimension from one to four, with one proof item each.
- Fill the biggest inventory gap first.
- Choose three rules and measure them for two weeks.
- Enforce one rule in a limited scope, with an expiring exception path.
- Review blocks and overrides monthly and adjust.
- Test with a harmless policy violation once a quarter.
Where Safeguard fits
Safeguard supports policies, gates and guardrails enforceable at build, CI and release, an MCP Guardrail proxy, and agent identity tracking. Autonomous remediation, which opens fix pull requests, is off by default and its categories start on manual. These are generally available, and the maturity stages above apply to how you adopt them.
Quick check
Should we aim for stage four everywhere?
Not necessarily. Match the stage to the risk. A low risk internal tool may be fine at stage two.
What is the fastest improvement?
Giving every agent its own identity and a written list of allowed tools, then checking that list in CI or at the proxy.
Sources
- NIST SP 800-53 Rev. 5, control CM-8 (OSCAL catalog)
- NIST SP 800-137, Information Security Continuous Monitoring
- OWASP Top 10 for LLM Applications 2025
Last reviewed: 18 October 2026.
