PR GUARDRAILS

Three modes. One guardrail framework.

Heeler runs Block, Warn, and Observe guardrails on every pull request — across dependencies, secrets, and the code your team and agents write. Try new policies in Observe before enforcing them, route warnings to the owning team, and block the violations that should never merge — all from one config.

What you can guard on.

Heeler's guardrails draw from the same context engine the audit and remediation layers use — org-aware, not just rule-based.

Open-source dependencies

• Vulnerable dependencies, scored by real exploitability — not just a manifest match:
  • Known-exploited (KEV)
  • Critical CVE in reachable code
  • Malicious package
  • Compromised maintainer
  • License violation

Code (SAST)

• Dangerous code the branch introduces — diff-only, scored by severity and confidence:
  • This is some text inside of a div block.
  • This is some text inside of a div block.
  • This is some text inside of a div block.
  • This is some text inside of a div block.
  • This is some text inside of a div block.
  • This is some text inside of a div block.
  • This is some text inside of a div block.

Dependency hygiene & supply chain

• Supply-chain hygiene, enforced at PR time:
  • Minimum release-age
  • Unpinned dependency
  • Unmaintained / deprecated
  • OSSF: dangerous workflows
  • OSSF: no branch protection
  • Unsigned releases

Secrets

• Validated, live credentials in a commit — flagged on the PR so the developer sees it. Automate rotation with a workflow; stop secrets from ever being committed with Agent Skills and the CLI.
  • Live cloud keys (AWS, GCP…)
  • Active tokens in commits
  • Validated, not regex

Open SLO violations

• Keep new work from stacking on top of overdue risk:
  • Findings past SLO in the repo
  • Blocks until overdue risk is handled

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.

BLOCK

Stop the merge.

The PR cannot merge while the violation exists. Use Block for the things that should never land — known-malicious dependencies, 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

WARN

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

OBSERVE

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 vulnerability, the same check offers to fix it — opening a validated, merge-ready remediation PR without anyone leaving the pull request.

• Right from the check
• GitHub shows a “Fix w/ Heeler” button on the guardrail check; GitLab takes a /heeler fix reply. No context switch, no separate tool.
• The deterministic remediation engine
• 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.
• Offered only when it's safe
• 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.

• Only what this PR added
• 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.
• The reason, right in the PR
• 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.
• Flagged in the PR, not a queue
• 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.

• AI Guardrail Assistant
• Describe the policy you want in plain language; the assistant turns it into a working guardrail — no rule syntax to learn.
• Chain rules together
• 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.
• Context-aware conditions
• 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.

• Global
• All repositories and services. The default — and the right starting point for critical security policies.
• Repository
• Specific repositories by name, source (GitHub, GitLab, Bitbucket), or organization / group.
• Service runtime context
• Services by tier, application name, or internet accessibility.
• Branch
• 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.

• GitHub
• A check run on the PR — make it a required status check in your branch protection rule.
• GitLab
• A commit status — require it to succeed on your protected branches.
• Azure DevOps
• A PR status — enforce it with a branch policy on the target branch.
• Bitbucket
• 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.

WHERE IT FITS

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.