Should a Debug AI Commit Code? Guardrails for Autonomous Fixes in CI/CD

Debugging AIs are getting good at localizing faults, drafting patches, and even passing tests. The temptation is obvious: wire an agent into CI, let it repro a failing case, propose a fix, and hit merge. But should a debug AI ever commit code by itself?

The short answer: yes, but only within clearly defined guardrails. Large-scale software systems already use automation to heal themselves — from autoscaling to circuit breakers to canary rollouts. Extending that idea to code changes can work, if we bound risk, prove correctness via contracts, and make reversibility instant.

This article lays out a pragmatic, engineering-first blueprint for allowing a debug AI to propose and, in low-risk lanes, commit code. It spans reproducibility from traces, tests-as-contracts, approval gates, sandboxing, and instant rollback — with concrete examples and reference architectures.

TL;DR

• Let the AI propose changes broadly, but commit only within a safety envelope defined by:
  • Deterministic reproduction from traces and inputs
  • Tests-as-contracts (characterization, property-based, invariants)
  • Policy gates tied to risk scoring and ownership
  • Hermetic, sandboxed execution and minimal secrets
  • Progressive delivery with automatic rollback
  • Signed provenance, auditability, and explainable diffs
• Start with autopatches for low-risk classes: comments, logging, flaky-test quarantines, typo-level bug fixes, non-prod tooling. Gradually expand as metrics (revert rate, regression escape rate) justify.

---

Why even consider autonomous fixes?

• MTTR pressure: When a test fails or an outage is brewing, an automated patch can reduce time-to-mitigation.
• Developer focus: Offload rote bug fixes (boundary checks, null guards, dependency pin updates) so engineers spend time on architecture and product.
• Scale: In monorepos and polyglot fleets, bugs cluster. Automation can stamp out repeating patterns found via traces or static analyzers.

But automation without guardrails amplifies risk: silent regressions, prompt-injected patches, data exfiltration, and brittle approvals. We need a system, not a chatbot, to make this work.

---

Threat model: What can go wrong when an AI commits code?

• False fix and regression: Patch hides the symptom, worsens the root cause, or swaps a rare failure for a common performance cliff.
• Context starvation: The agent acts on a narrow trace; misses environment or cross-service invariants.
• Prompt injection and tool misuse: Build logs, comments, or artifacts contain adversarial instructions.
• Supply-chain exposure: The agent adds or upgrades dependencies that introduce vulnerable licenses or malware.
• Secret leakage: The agent sees prod data or long-lived secrets; patch inadvertently logs PII.
• Flaky tests: The agent chases noise, producing churn.
• Ownership bypass: Code owners or compliance rules are skipped via automation.

We mitigate these with guardrails embedded in the CI/CD path — not in the model alone.

---

Principle 1: Deterministic reproduction from traces

An autonomous fix must begin with a reproducible failing case. You cannot trust a patch that fixes a failure you cannot deterministically replay.

Key practices:

• Record precise inputs and environment: HTTP/gRPC requests (headers, payloads), feature flags, relevant env vars, and versions.
• Attach a trace ID to the failure: Correlate logs, metrics, and spans via OpenTelemetry.
• Use snapshotting or record/replay where possible: rr for C/C++, JVM Flight Recorder, or language-specific deterministic runners.
• Freeze and materialize nondeterministic sources: Time, random, network egress, and external APIs should be mocked or replayed.
• Minimal reproducer: Generate a test case that fails in isolation, independent of full system state.

Example: generating a repro test from an OpenTelemetry trace in a Node.js service.

js
// scripts/generate-repro.js
// Given a trace ID, fetch pertinent spans and reconstruct a failing HTTP request
// Requires: an OTel-compatible backend exposing a JSON API (e.g., Jaeger/Tempo)

const fetch = require('node-fetch');
const fs = require('fs');

async function fetchTrace(jaegerUrl, traceId) {
  const res = await fetch(`${jaegerUrl}/api/traces/${traceId}`);
  if (!res.ok) throw new Error('Trace fetch failed');
  return res.json();
}

function toCurl(span) {
  const attrs = Object.fromEntries(span.tags.map(t => [t.key, t.value]));
  const method = attrs['http.method'] || 'GET';
  const url = attrs['http.url'];
  const headers = (span.logs || [])
    .flatMap(l => (l.fields || []))
    .filter(f => f.key.startsWith('http.header.'))
    .map(f => `-H '${f.key.replace('http.header.', '')}: ${f.value}'`)
    .join(' ');
  const body = attrs['http.request.body'] ? `--data '${attrs['http.request.body']}'` : '';
  return `curl -sS -X ${method} ${headers} ${body} '${url}'`;
}

function testTemplate(curl) {
  return `const assert = require('assert');
const child_process = require('child_process');

describe('Repro from trace', function() {
  this.timeout(5000);
  it('should fail as observed', function() {
    const { status, stdout, stderr } = child_process.spawnSync('bash', ['-lc', `${curl}`]);
    // Assert on status or response fields that failed
    assert.notStrictEqual(status, 0, 'Expected failure status');
  });
});\n`;
}

(async () => {
  const [,, jaegerUrl, traceId] = process.argv;
  const trace = await fetchTrace(jaegerUrl, traceId);
  const httpSpan = trace.data[0].spans.find(s => s.operationName === 'HTTP POST /v1/orders');
  const curl = toCurl(httpSpan);
  fs.writeFileSync('test/repro.trace.test.js', testTemplate(curl));
  console.log('Wrote test/repro.trace.test.js');
})();

Notes:

• Store just enough to reproduce; avoid logging raw PII. Redact via OTel attribute processors.
• Stable replay requires hermetic dependency versions and fixtures for DB or queues.
• Prefer replaying at service boundary to avoid contaminating business logic with test-only hooks.

---

Principle 2: Tests as contracts (not suggestions)

The AI must be constrained by contracts that reflect user-facing correctness, not incidental behavior.

Build a layered test oracle:

• Characterization tests: Capture current behavior around the failure. Useful for legacy code where spec is implicit.
• Property-based tests: Specify invariants and edge cases. These defend against overfitting to a single trace.
• Mutation testing: Ensure tests can kill common fault patterns so trivial, masking fixes are rejected.
• Golden outputs with drift detection: For data pipelines or rendering, snapshots can be effective if combined with diff quality gates.
• SLO-backed synthetic checks: Encode latency ceilings, error-rate budgets, and idempotency expectations.

Example: property-based test in Python with Hypothesis to constrain a money rounding helper.

python
# tests/test_rounding_props.py
from hypothesis import given, strategies as st
from decimal import Decimal, ROUND_HALF_UP
from rounding import round_money

@given(st.decimals(allow_nan=False, allow_infinity=False, places=6))
def test_round_money_is_bankers_rounding(x):
    # Contract: round to 2 dp using banker style
    expected = Decimal(x).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)
    assert round_money(Decimal(x)) == expected

@given(st.decimals(min_value='-100000', max_value='100000', places=6))
def test_round_money_is_idempotent(x):
    v = round_money(Decimal(x))
    assert round_money(v) == v

Avoid these pitfalls:

• Snapshot overuse: If contracts are snapshots of everything, agents will game the snapshot rather than fix the semantics. Scope snapshots narrowly.
• Non-deterministic oracles: Randomized, time-based, or rate-limited checks should be stabilized under test.
• Hidden side effects: Include invariants for logs, metrics, and retries if they define SLOs or rate limits.

---

Principle 3: Constrained propose-commit loop

The safe path is propose broadly, commit narrowly. Start with a conservative lane for autopush; expand with evidence.

Mechanics:

• Diff budget: Cap lines changed, files touched, and forbid certain directories from autopush (auth, crypto, payments, migrations).
• Risk scoring: Label changes with an estimated blast radius (e.g., internal utility vs. public API) and require different approval levels.
• Ownership: Enforce CODEOWNERS rules; autopush is allowed only in code owned by a specific team that opted in.
• Commit metadata: Tag autopatches with trailers for provenance and traceability.
• Explanation: Require the AI to produce a structured rationale referencing the failing test or trace ID.

Example commit message template for AI patches:

fix: null-guard in OrderDTO parser to avoid NPE on missing 'customer_id'

- Reproduced from trace_id=7b4c2f...
- Adds null check and default 'anonymous' handling in parse
- Characterization test added to capture prior failure
- Property test added for idempotency

AI-Explanation: The failure occurs when upstream omits 'customer_id' for guest checkout. The parser assumed presence and dereferenced None. The fix makes the field optional and aligns with business rule in docs/guest-checkout.md.

Co-authored-by: debug-ai-bot <bot@example.com>
Change-Type: patch
AI-Autofix: true
Trace-ID: 7b4c2f...

Policy gating with Open Policy Agent (OPA) is an effective way to keep rules auditable.

Example Rego snippet to deny risky autopushes:

rego
package ci.autofix

default allow = false

# Autopush only allowed when explicitly tagged and low-risk
allow {
  input.commit.trailers["AI-Autofix"] == "true"
  input.risk.score <= 2
  count(input.diff.files) <= 3
  input.diff.total_loc <= 60
  not touches_forbidden_paths
}

touches_forbidden_paths {
  fp := input.diff.files[_]
  forbidden := ["/auth/", "/crypto/", "/payments/", "/db/migrations/"]
  contains_any(fp, forbidden)
}

contains_any(s, arr) {
  some i
  contains(s, arr[i])
}

For version control platforms, wire this into branch protection: the OPA policy runs, emits a status check, and blocks merges that violate constraints.

---

Principle 4: Sandboxing and isolation

Treat the AI like an untrusted build tool with limited privileges.

• Ephemeral environments: Run the agent inside short-lived sandboxes (gVisor, Firecracker, Kata) with seccomp and AppArmor profiles.
• Constrained network: No internet egress by default; allowlist artifact registry and trace backend. Deny raw IP egress.
• Minimize secret exposure: Use OIDC short-lived tokens; never mount prod credentials. Redact logs before model inputs.
• Data minimization: Partial clone with sparse checkout; fetch only relevant subpaths.
• Tool attestation: Pin model and tool versions. Hash and attest the agent container with Sigstore.
• Prompt hygiene: Strip user-generated content with potential injections (PR comments, flaky logs) or route via a sanitizer that removes markers like 'system:' and tool instructions.

Example GitHub Actions job configuration with sandboxing and minimal permissions:

yaml
name: ai-autofix
on:
  workflow_run:
    workflows: ['ci']
    types: [completed]

permissions:
  contents: write
  pull-requests: write
  checks: write
  id-token: write

jobs:
  autofix:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/org/debug-ai-agent:1.4.2
      options: >-
        --network none
        --security-opt=no-new-privileges
        --cap-drop=ALL
    steps:
      - name: Sparse checkout
        uses: actions/checkout@v4
        with:
          sparse-checkout: |
            services/orders
            libs/parsers
          fetch-depth: 0

      - name: Acquire short-lived token
        id: oidc
        uses: actions/oidc-token@v1

      - name: Run AI agent in offline mode
        env:
          OIDC_TOKEN: ${{ steps.oidc.outputs.token }}
          TRACE_BACKEND_URL: ${{ secrets.TRACE_BACKEND_URL }}
        run: |
          ai-agent \
            --offline \
            --allowlist-paths 'services/orders,libs/parsers' \
            --deny-net \
            --policy policy.rego \
            --out pr.patch \
            --explain explain.md

      - name: Open PR
        run: gh pr create --title "AI autofix: ${GITHUB_RUN_ID}" --body-file explain.md || true

---

Principle 5: Progressive delivery and instant rollback

When autopatches do merge, they should ship gradually and be easy to undo.

• Feature flags: Gate code paths behind flags so the runtime switch is independent of deployment. Ship the patch dark, then ramp.
• Canary rollouts: Route a small fraction of traffic, monitor, and auto-promote on SLO adherence.
• Automatic rollback: On regression detection, roll back immediately and open a revert PR with context.
• Continuous verification: Validate not just syntactic health (CPU, 5XX) but semantic metrics (conversion, latency p95 per endpoint).

Example Argo Rollouts canary with instant rollback on error-rate increase:

yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: orders-api
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 120}
        - analysis:
            templates:
              - templateName: error-rate
            args:
              - name: service
                value: orders-api
        - setWeight: 50
        - pause: {duration: 300}
        - analysis:
            templates:
              - templateName: latency-p95
      trafficRouting:
        nginx: {}
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate
spec:
  metrics:
    - name: http-5xx
      interval: 1m
      successCondition: result < 0.01
      failureCondition: result >= 0.01
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: sum(rate(http_requests_total{service='orders-api',status=~'5..'}[5m])) / sum(rate(http_requests_total{service='orders-api'}[5m]))

For rollbacks:

• Keep deployments idempotent and track build provenance so rollback is a single kubectl or GitOps sync.
• Implement a revert bot that opens a PR with context (trace IDs, failing SLOs, and the offending commit) and assigns owners.

---

Principle 6: Observability-driven acceptance

Tests are necessary but insufficient. Use real-time signals to validate that the fix behaves in the wild.

• Shadow traffic: Replay production-like requests against a shadow environment running the patched build and diff responses.
• Differential metrics: Compare error rate and latency histograms pre/post via a change detector.
• Log invariants: Ensure log volume and cardinality do not explode (AI-added log loops can be costly).
• Counterfactual checks: If the fix adds a fallback path, assert it is rarely used under normal load.

Example simple change detector formula:

• Compute Jensen-Shannon divergence between response distributions (status code, payload class). Alert if divergence exceeds a threshold relative to baseline noise.

---

Principle 7: Accountability and provenance

If an AI can commit, it must be accountable.

• Signed commits and attestation: Use Sigstore/cosign to sign the agent container and attach an in-toto/SLSA attestation linking inputs (trace ID, test hashes) to outputs (patch hash).
• Structured explainability: Include a machine-readable explanation (JSON) with impacted files, referenced docs, and proof artifacts (test diff, property test names).
• Audit trails: Log every model prompt and tool action with PII redaction, retained for incident review.
• Change windows: Restrict autopush to certain hours with on-call coverage.

---

Lessons from industry and research

We are not starting from zero. Automated Program Repair (APR) and production tooling have a decade of lessons:

• Google Tricorder autofixes: Static analyzers that propose fixes developers can accept; high acceptance for small, localized patches with tests (Sadowski et al.).
• Meta SapFix and Sapienz: Automated patch generation guided by tests and static analysis, with human-in-the-loop code review before deployment.
• APR literature: GenProg, Prophet, Angelix, TBar, and newer learning-guided repair show that most accepted fixes are simple edits near the fault and that overfitting is common without diverse tests.
• GitHub Dependabot: Dependency bump bot accepted widely due to constrained risk domain and strong rollback story.

Takeaway: Bounded scope, strong oracles, and easy reverts make automation sustainable.

References:

• Meta engineering blog on SapFix: https://engineering.fb.com/2019/05/08/developer-tools/sapfix/
• Tricorder: Developer tooling at Google scale (Communications of the ACM): https://cacm.acm.org/research/developer-support-tools-google/
• APR survey: Le Goues et al., A systematic review of Automated Program Repair, ACM Computing Surveys.
• SLSA framework: https://slsa.dev/
• OpenTelemetry: https://opentelemetry.io/
• Argo Rollouts: https://argoproj.github.io/argo-rollouts/

---

Implementation blueprint

This section outlines a concrete path to deploy a debug AI in CI/CD, from failure detection to rollout.

1) Trigger and reproduce

• Trigger: On failing CI jobs or production error budget burn rate increase.
• Fetch context: Pull the relevant trace ID, logs, and build metadata.
• Repro: Generate a minimal failing test; verify it fails in a hermetic environment.

2) Propose a patch

• Localize: Use stack traces, blame history, and coverage maps to focus on suspect files.
• Synthesize: Draft a patch constrained by policies (diff budget, allowed directories).
• Extend tests: Add or update characterization and property tests to encode the intent.
• Explain: Produce rationale referencing documentation, invariants, and the repro.

3) Run preflight gates

• Lint, typecheck, and run unit/integration tests.
• Mutation testing for touched modules (fast selective mutants) to guard against trivial masking.
• Risk scoring and OPA policy evaluation.
• Security scan for new dependencies and licenses (Syft/Grype; SBOM delta must be empty for autopush lane).

4) Review and merge

• Open PR with structured metadata. Require human approval for medium/high risk.
• For low-risk lanes (e.g., test-only, logging, configuration toggles), allow autopush if policy passes.
• Signed commit with attestation bundle attached to PR as artifact.

5) Deliver progressively

• Feature flag the change if possible; default off.
• Canary rollout with automated analysis against SLOs.
• Auto-promote or rollback.

6) Observe and learn

• Track metrics: revert rate, escaped regressions, MTTR reduction, patch acceptance rate, test fragility index.
• Postmortem heuristics: Update risk rules and tests based on escapes.
• Continual learning: Fine-tune or retrain the agent on accepted diffs and rejected PRs, but only with sanitized, policy-compliant data.

---

Example: End-to-end workflow in CI

A concrete GitHub Actions workflow that responds to a failing test job, generates a patch within a sandbox, and opens a PR guarded by policies.

yaml
name: debug-ai-autofix
on:
  workflow_run:
    workflows: ['CI']
    types: [completed]

jobs:
  triage:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Collect failure context
        run: |
          gh run view ${{ github.event.workflow_run.id }} --json conclusion,headBranch,url -q '.url' > run.url
          echo "trace_id=$(grep -oE 'trace_id=[a-f0-9]+' logs.txt | head -1 | cut -d= -f2)" >> $GITHUB_OUTPUT
      - name: Upload context
        uses: actions/upload-artifact@v4
        with:
          name: failure-context
          path: |
            run.url
            logs.txt

  propose:
    needs: triage
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/org/debug-ai-agent:1.4.2
      options: >-
        --network none --security-opt=no-new-privileges --cap-drop=ALL
    permissions:
      contents: write
      pull-requests: write
      checks: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          sparse-checkout: |
            services/orders
            libs/parsers
      - uses: actions/download-artifact@v4
        with:
          name: failure-context
      - name: Generate repro
        run: ai-agent repro --trace $TRACE_BACKEND_URL --out tests/repro.test.ts
      - name: Synthesize patch
        run: ai-agent patch --policy policy.rego --explain explain.md --out patch.diff
      - name: Verify locally (hermetic)
        run: |
          npm ci --ignore-scripts
          npm test -- tests/repro.test.ts || true
          npm test
      - name: Open PR
        run: |
          git apply patch.diff
          git checkout -b ai/autofix-${GITHUB_RUN_ID}
          git commit -S -m "fix: AI autofix for repro ${GITHUB_RUN_ID}" -m "AI-Autofix: true" -m "Trace-ID: ${TRACE_ID}"
          git push -u origin ai/autofix-${GITHUB_RUN_ID}
          gh pr create --title "AI autofix: ${GITHUB_RUN_ID}" --body-file explain.md --label ai-autofix

  policy:
    needs: propose
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run OPA gate
        run: |
          opa eval -i pr.json -d policy.rego 'data.ci.autofix.allow' > result.txt
          grep true result.txt

---

Pseudocode: The agent loop

python
class DebugAIAgent:
    def run(self, trace_id):
        ctx = self.collect_context(trace_id)
        repro = self.generate_repro(ctx)
        assert repro.fails_hard()

        candidates = self.synthesize_patches(ctx, repro)
        for patch in candidates:
            if not self.policy_allows(patch):
                continue
            if not self.verify_patch(patch, repro):
                continue
            pr = self.open_pr(patch)
            self.attach_attestation(pr, ctx, patch)
            return pr
        return None

    def verify_patch(self, patch, repro):
        with sandbox(offline=True, secrets_min=True) as env:
            env.apply(patch)
            if not env.run_tests(['repro', 'touched_modules']):
                return False
            if not env.mutation_score_delta() >= 0:
                return False
            if env.sbom_delta() != {}:
                return False
            return True

---

Handling flaky tests and noisy failures

Autofix agents can get stuck chasing flakes. Bake flake handling into the pipeline.

• Flake quarantine: If a test fails nondeterministically across retries, the agent can propose quarantining with a clear annotation and owner ping, not a semantic patch.
• Stabilize before patch: Failures labeled flaky should not trigger autopush; require human triage or stabilize test harness.
• Statistical triage: Require p < 0.05 reproducibility across N runs before accepting the failure as real for autopatch.

---

Security and compliance considerations

• SOC 2 change management: Treat autopatches as standard changes with tickets, approvals (when required), and documented risk assessment.
• License compliance: Forbid new dependencies in autopush lane; human review required for any SBOM delta.
• Data protection: Redact personally identifiable information from traces and logs; store only keyed references in PRs.
• Model governance: Version the model and prompt templates; roll forward/back models like any dependency.

---

What should be allowed to autopush?

Start with:

• Test-only edits: Adding characterization/property tests.
• Logging tweaks: Adding structured logs, improving error contexts (with log volume caps).
• Config and flags: Toggling feature flags off for mitigations.
• Simple correctness patches: Null checks, bounds checks, typo fixes, non-breaking parsing changes with explicit tests.

Require human approval for:

• Public API changes, database schema migrations, auth/crypto logic, concurrency primitives.
• Dependency additions or upgrades.
• Changes touching multiple services or shared core libraries.

---

Metrics to decide if autonomy is working

• MTTR reduction: Time from failure detection to merged fix.
• Revert rate: Percentage of AI-led merges reverted within 7 days.
• Escape rate: Regressions detected in production attributable to AI patches.
• Test effectiveness: Mutation score for touched modules pre/post.
• Risk coverage: Proportion of fixes happening in autopush vs. human lanes.
• Developer satisfaction: Survey signal; do engineers accept or disable the bot?

Targets to aim for before expanding scope:

• Revert rate below 1% for low-risk autopushes.
• Escape rate near zero for autopush; comparable to or better than human patches for reviewed merges.
• MTTR improvement of 20–40% on targeted failure classes.

---

Example: Using traces to generate a failing test and a safe patch

Scenario: A 500 error occurs when submitting an order without a customer_id. The trace shows a None dereference in the OrderDTO parser.

• Repro test: Generated from the trace, asserting 400 with a structured error for missing field.
• Contracts: Property tests assert idempotency and that guest checkouts are allowed.
• Patch: Add a null-check and default behavior, guided by business rule docs.
• Policy gate: Touches only libs/parsers with diff of 12 LOC; risk score 1; autopush permitted.
• Delivery: Feature-flag the behavior; canary 10% then 50%, no SLO regressions; auto-promote.
• Provenance: Signed commit, Trace-ID attached, attestation stored.

---

Practical tips and gotchas

• Keep models local and deterministic: For regulated environments, run the model on-prem or in a VPC; pin model versions.
• Budget the agent: Hard time and token limits prevent runaway behavior.
• Train on your codebase: Fine-tuning or RAG with internal docs improves locality and reduces hallucinations.
• Do not let the AI modify tests without scrutiny: Require that newly added tests fail before the fix, and pass after; forbid removal of existing tests in autopush.
• Integrate with CODEOWNERS and on-call: The agent should ping the right humans with context.
• Prefer small, frequent patches: Large, sweeping changes increase risk nonlinearly.

---

Should a debug AI commit code?

Yes — with boundaries. The right mental model is not a junior developer with unlimited commit rights; it is a specialized repair tool operating in a constrained lane, backed by strong contracts and instant reversibility. Let it propose widely to harvest ideas and fixes; let it commit narrowly where the risk is low, the tests are strong, and the rollback is trivial.

The organizations that succeed will treat AI repair as an engineering system: measurable, auditable, guarded by policy, and tuned by outcomes. Start small, collect data, expand scope when the data says it is safe.

---

Checklist: Guardrails for autonomous fixes

• Reproduction

  • Trace-backed, deterministic repro test exists and fails before the patch
  • Nondeterminism (time, random, external I/O) is stubbed or replayed

• Contracts

  • Characterization and property tests updated/added
  • Mutation tests show non-decreasing score
  • SLO-aligned synthetic checks included for critical paths

• Policy

  • Diff under threshold; no forbidden paths
  • Ownership and approvals enforced
  • Commit includes AI trailers and explanation

• Security

  • Sandbox with no egress; minimal secrets via OIDC
  • No new dependencies in autopush lane; SBOM delta empty
  • Signed commit and attestation

• Delivery

  • Feature flag available; canary rollout configured
  • Automatic rollback on SLO breach
  • Post-merge monitoring and shadow traffic checks

If you cannot check these boxes, the AI can still propose — but a human should decide.