.svg)
Block risky changes before they merge.
Run every PR policy in Block, Warn, or Observe mode across dependencies, code, infrastructure as code, secrets, known-malicious files, supply-chain hygiene, and the agent files your assistants run on. Test new policies silently before enforcing them, warn when judgment is required, and block the violations that should never merge — all from one configuration and the same Context Engine.
What you can enforce at PR time.
Heeler's guardrails draw from the same context engine the operate and remediation layers use — org-aware, not just rule-based.
Open-source dependencies
Vulnerable dependencies, scored by real exploitability — not just a manifest match:
Code (SAST)
Dangerous code the branch introduces — diff-only, scored by severity and confidence:
Infrastructure as Code
Misconfigurations in the infrastructure your code defines — caught in the definition, before anything is stood up:
Malicious files (IOC)
Known-malicious files the PR introduces — attack tooling flagged for what it is, before it merges:
Dependency hygiene & supply chain
Supply-chain hygiene, enforced at PR time:
Secrets
Two rules. One gates the credentials this pull request adds — every commit in the window, not just the squashed diff. The other gates the repository itself: a live credential anywhere in its inventory, git history included, holds the merge whatever the pull request touches. It clears when the credential is rotated, not when someone pushes another commit.
Agent files
The instructions, skills, subagents, hooks, and MCP config your coding agents run on — gated when a PR introduces or changes one:
Standards (OWASP ASVS)
The controls of an ASVS level that a pull request can actually check, applied as one set rather than assembled rule by rule:
Open SLO violations
Keep new work from stacking on top of overdue risk:
Three enforcement modes, one config.
Each guardrail picks a mode. Mix and match across your policy library — strict where it matters, observational where you're still learning the signal.
Stop the merge.
The PR cannot merge while the violation exists. Use Block for the things that should never land — known-malicious dependencies, files that are attack tooling outright, critical CVEs in reachable code paths, valid secrets in committed files, and injection or deserialization flaws in the code the PR adds.
- Hard merge block via required check
- Circumventing a Block is recorded with a full audit trail
- Reasons and remediation steps surfaced in the PR comment
Flag for the reviewer.
The PR can merge, but the warning shows up in the PR with full context. Use Warn for risk that needs a human judgment call — medium-severity issues, deprecated APIs, dependency upgrades that pass tests but change behavior.
- Inline PR comment with the violation explained
- Pair with a workflow to notify the owning team, resolved from Heeler's ownership graph
- Tracked so warnings don't quietly accumulate
Capture the signal silently.
No PR comment, no merge effect — just data. Use Observe to test a new guardrail against your real PR traffic before you roll it out. See what it would have blocked or warned on, tune thresholds, then promote.
- Zero developer-facing noise during testing
- Dashboard shows what would have triggered
- Promote to Warn or Block with one config change
AGENTIC AUTO-FIX
A guardrail that fixes what it catches.
A red check still leaves the work to the developer. When Heeler flags a fixable dependency or code vulnerability, the same check offers the validated fix — without sending the developer to another tool.
GitHub shows a “Fix w/ Heeler” button on the guardrail check; GitLab takes a /heeler fix reply. No context switch, no separate tool.
Heeler computes the safe upgrade — not a model's guess — an agent applies it, your CI validates, and a merge-ready PR comes back. The same engine behind Heeler's remediation.
Available for net-new, direct, fixable vulnerabilities. When there's no clean fix, the guardrail abstains rather than guess.
DEVELOPER EXPERIENCE
Built so developers don't route around it.
Guardrails only work if the people they land on trust them. Heeler's are scoped, explained, and tuned before they ever block.
Diff-only by design — a guardrail fires on what the PR introduces, never on inherited debt. Nobody gets blocked for a problem they didn't create.
An inline comment explains the violation, why it matters, and how to fix it — with the dependency path for transitive issues and a deep link into Heeler.
Violations appear as comments and annotations right in the pull request the developer is already looking at — no separate tool, no ticket to chase down.
FLEXIBLE BY DESIGN
Guardrails you shape to your program.
Not a fixed ruleset. Describe guardrails in plain language, chain conditions on real runtime context, and scope them from global to a single branch.
Describe the policy you want in plain language; the assistant turns it into a working guardrail — no rule syntax to learn.
Compose multiple conditions into one guardrail — say, a critical CVE that's also reachable and internet-facing — so it fires only when every condition is true, not on any one alone.
Condition guardrails on real context — is the finding reachable, is the service internet-facing, is it actively exploited — not just a severity threshold. The same signals that power prioritization.
SCOPE
Global by default. Precise when you need it.
Scope any guardrail to control exactly where it applies — and combine scopes for surgical targeting.
All repositories and services. The default — and the right starting point for critical security policies.
Specific repositories by name, source (GitHub, GitLab, Bitbucket), or organization / group.
Services by tier, application name, or internet accessibility.
All branches, the default branch only, or all except main.
Combine for surgical targeting
Block critical vulnerabilities only in production-tier, internet-accessible services — while warning on the same violations in internal services.
ENFORCEMENT
Blocking happens where it already lives — your branch protection.
Heeler doesn't proxy your Git or sit in the merge path. For each pull request it posts a native pass/fail status check; your existing branch-protection rules decide whether that check is required to merge. No new gate to trust, no webhook choke point.
A check run on the PR — make it a required status check in your branch protection rule.
A commit status — require it to succeed on your protected branches.
A PR status — enforce it with a branch policy on the target branch.
A build/merge check — require it in your branch permissions.
All three modes post through the same mechanism: Block fails the check, Warn posts a non-blocking note, Observe stays silent.
One policy. Every layer of prevention.
Heeler runs the same policy everywhere your code moves, read from one model of your environment in the Context Engine. PR guardrails are the layer on the pull request — they don't replace the others, they share their policy and their findings.
Inside the AI coding agent, as code is generated.
In the terminal, before commit.
PR guardrails
Native status checks on the pull request, server-side.
Routing, tickets, and fixes after merge.
See your real PRs run through Heeler.
A demo on your codebase shows which guardrails would have caught what — and where Observe vs. Warn vs. Block lands for your team.
