Use case · Guardrails & governance

Guardrails for AI agents that touch production code.

Letting an AI coding agent work on production bugs is only reckless when the only thing stopping it is a prompt. RunGuard puts the boundaries in the infrastructure — protected paths, no auto-merge, scoped context, your own credentials — so the worst case is a pull request you decline, not unreviewed code in production.
Protected paths enforcedNever auto-mergesYour keys, never ours

In short

AI coding agents that touch production code need guardrails enforced by infrastructure, not by prompt instructions a crafted input can override: protected paths as a hard gate, no auto-merge, scoped review-grade context, customer-owned credentials, a low-confidence path that produces an investigation instead of a guess, and auditable status. RunGuard applies these before an agent is dispatched and again before its output is accepted.
RG-GUARDThe guardrailsSix controls, enforced not suggested

What an agent on production code actually needs.

Each of these is a control RunGuard enforces around the executor — before dispatch, and again before any output is accepted.
  1. 01

    Protected paths, as a hard gate

    Sensitive directories — auth, billing, payments, secrets — are off-limits. RunGuard checks protected paths before dispatch and again before accepting the agent’s output. It’s enforced, not a polite line in a prompt.

  2. 02

    Never auto-merge

    Every change an agent proposes arrives as a pull request a human reviews. RunGuard never merges, and never enables auto-merge. The agent opens the door; a person walks through it.

  3. 03

    Scoped, review-grade context

    The agent receives a crash packet and a narrow task — "investigate this error and propose a small, reviewable fix" — not "go fix the codebase." Tight scope is what keeps output reviewable.

  4. 04

    Customer-owned credentials

    The agent runs on your GitHub Copilot seat or your Anthropic key, inside your own GitHub. RunGuard orchestrates the handoff and never holds your LLM credentials.

  5. 05

    Low confidence → investigation, not a guess

    When an error isn’t cleanly reproducible, the task asks for a draft investigation rather than a speculative fix — so low-confidence work shows up as notes to review, not risky code.

  6. 06

    Auditable routing & status

    Every incident records which executor it went to, its status, and the linked PR. You can always answer "what did an agent touch, and when" from one timeline.

RG-VSWhere guardrails belong

A prompt is a request. Infrastructure is a rule.

If the only thing keeping an agent out of your billing code is a sentence in the system prompt, it isn’t a guardrail — it’s a hope.
RunGuardPrompt-level rules only
Protected filesHard gate, checked pre- and post-dispatchAsked for politely in the system prompt
Bypass riskCan’t be prompted awayA crafted input can override the instructions
MergingAuto-merge never enabledDepends on how the agent behaves
CredentialsYour own key; orchestrator never holds itOften a shared or hosted key
AuditabilityOne status timeline per incidentScattered across agent logs
RG-FAQQuestions

Plain answers about AI coding agent guardrails.

What guardrails do AI coding agents need?

AI coding agents that touch production code need guardrails enforced by infrastructure, not by prompt instructions a crafted input can override: protected paths as a hard gate, no auto-merge, scoped review-grade context, customer-owned credentials, a low-confidence path that produces an investigation instead of a guess, and auditable status. RunGuard applies these before an agent is dispatched and again before its output is accepted.

Is it safe to let an AI agent fix production bugs?

It is safe when the boundaries are enforced outside the agent. With protected paths as a hard gate, no auto-merge, and a scoped task, the worst case is a pull request you decline — not unreviewed code shipped to production. The risk lives in setups where the only guardrail is the prompt.

Why should an AI coding agent never auto-merge?

Because review is where hallucinated, incomplete, or out-of-scope fixes get caught. Auto-merging removes the one human checkpoint that stands between a plausible-looking diff and your production branch. RunGuard never auto-merges; the fix is always a PR.

What are protected paths?

Protected paths are directories an agent is not allowed to modify — typically auth, billing, payments, and secrets handling. In RunGuard they are a hard gate: the check runs before an incident is dispatched and again before any output is accepted, so the agent can’t touch them even if it tries.

Can you enforce AI safety with prompt instructions alone?

No. If a tool boundary exists only as a line in the system prompt, a crafted input or an over-eager model can step around it. Guardrails that matter — what files are off-limits, whether code can merge itself — have to live in the infrastructure, where they can’t be prompted away.

Who holds the AI’s API keys?

You do. The agent runs on your own GitHub Copilot seat or your own Anthropic key, inside your own GitHub. RunGuard orchestrates routing, safety, and tracking, and never holds your LLM credentials.

Automate the fix. Keep the guardrails.

Connect a repo, set protected paths, and route incidents to your own agent — with the boundaries enforced where they can’t be prompted away.