Guardrails

Guardrails is the Sigrid Axis capability that stops an AI coding agent from introducing security, maintainability, and architecture problems, by checking the agent’s work against Sigrid Core before it reaches a commit or a merge.

Guardrails runs two checks:

• The quality gate checks each file the agent changed for maintainability and security, before it reports a task done, with the guardrails_quality_check MCP tool.
• The architecture drift check checks the whole change for new dependencies, cycles, and bypassed facades, before you push, with the architecture-drift skill.

Each check runs on a standing instruction, which you set up once. The quality gate works on uncommitted code in systems not yet published to Sigrid. The drift check needs a published system, because it compares your diff with Sigrid Core’s dependency graph.

For the problems that are already in your code, see Auto-fix Agents. For a walkthrough of each check in day-to-day work, see building with Guardrails and preventing architecture drift.

Supported technologies

The guardrails_quality_check tool supports these technologies:

• Java
• Python
• C/C++
• C#
• JavaScript
• TypeScript
• Kotlin
• Progress ABL
• PHP

The technology support page marks them with “Guardrails”. The architecture drift check supports every technology marked with “Architecture” on that page.

Set up the quality gate

Connecting the MCP server is half the setup. The agent does not call the tool unless something tells it to, so the other half is a standing instruction that it runs at a fixed point in every task.

Claude Code

Install the Claude Code plugin. Its UserPromptSubmit hook adds the instruction below to every prompt you send, so for the quality gate there is nothing to add yourself. The hook is on by default. To turn it off, see plugin options.

Other tools

Put the instruction in AGENTS.md at the root of your repository, so it applies to every session without you asking. Cursor, GitHub Copilot, Devin, and most other agentic tools read that file. It is the same text the Claude Code hook adds: three code principles, and a quality gate to pass before reporting a task done:

Principles: single responsibility, self-documenting code, simple control flow.
Before reporting done:
1. Run Sigrid guardrails_quality_check on changed production code (skip tests, docs, generated).
2. Fix all maintainability findings judged against the principles — skip only if the code already honors them; say which and why.
3. Security findings: fix if contained, otherwise flag to user.

The quality gate applies the Boy Scout Rule: leave each file you touch cleaner than you found it.

Two adjustments are worth making from the start. If your codebase follows specific design patterns, such as hexagonal architecture or Redux, add them to the principles line, and write a principle for every recurring mistake you find yourself correcting. You can also loosen the timing to commits only. Either way, you can always ask for the check yourself: “Run Sigrid on these files: …”.

For which wording in that prompt carries it, and a session where the agent refactors in response to a finding, see building with Guardrails.

Set up the architecture drift check

No hook adds this instruction. Add it to CLAUDE.md in Claude Code, or to AGENTS.md in other tools:

Before pushing code or opening a pull request, run the architecture-drift skill.
If it reports drift, fix it, or explain why the new dependency is intended.

The check needs a published system and a Sigrid profile with your baseline branch, which setup writes. To run it yourself, type /architecture-drift. For an example session, see preventing architecture drift.

What Guardrails does not see

Neither check sees vulnerable dependencies or duplication spread across files. The quality gate reads one file at a time, and the drift check only looks at the references between directories.

The change-feedback skill covers those before you push. It runs Sigrid CI on your working tree for maintainability, open-source, and security, which finds vulnerable dependencies and duplication across files.

An instruction to the agent is followed most of the time, and the agent is the one who decides it has finished. Sigrid CI in a pre-commit hook or in your pipeline gives you a check the agent cannot decide it has already satisfied.