What it does

The three hard constraints

1. Scope fence

2. Prompt injection defense

3. Workflow invariants

The HITL gate

Threat model: what this covers

What it doesn't cover (yet)

Try it Every "AI-powered CI healing" demo I've seen has the same problem nobody talks about. The model sees your runtime logs — attacker-controlled input. It writes back to your workflow files — privileged output. That's a prompt injection → privilege escalation chain gift-wrapped for anyone who can influence your test output. A malicious dependency, a poisoned test fixture, a crafted log line — and suddenly your "helpful AI" is widening permissions: write-all or adding a secret exfil step to the workflow it just "fixed". Quietly. In a PR your tired reviewer rubber-stamps at 5pm on a Friday. I built aiheal to solve exactly this. Six scanners run on every CI failure: An LLM triages the results, assigns confidence, and proposes a fix. If confidence is high — it opens a PR. If confidence is low — a human must approve before anything touches the repo. The application code is never touched. Never seen by the model. Never included in any prompt. AI edits are structurally restricted to: Go source, go.mod, go.sum, and everything else — never included in any plan, at any confidence level. This isn't a prompt instruction ("please don't touch app code"). It's enforced before the prompt is even built. Runtime logs are sanitized and wrapped in <untrusted> tags before reaching the model: Your failed test output doesn't get to tell the LLM what to do. If a dependency tries to print IGNORE PREVIOUS INSTRUCTIONS into your build log — the model sees it as data, not instructions. Before any AI-generated patch is applied, it's checked against a hard rule set: Violations are rejected structurally, before apply. Not caught in review. Not flagged in a comment. Rejected. When the AI assigns low confidence, the pipeline routes through a GitHub Environment with required human reviewers. This isn't a "are you sure?" dialog. It's a GitHub-native gate — no approval, no merge, no heal. The gate is not bypassable via prompt. The routing logic lives outside the model's reach. The last one is worth thinking about. If you're running a CVE scanner that pulls from an external feed an attacker can influence — you have a different problem upstream. The repo ships with a small Go login API as a demo target. Set your OPENROUTER_API_KEY (or swap to any OpenAI-compatible endpoint), configure the GitHub Environment with a reviewer, and you have a working self-healing pipeline with all three constraints active. What would you add to the threat model? Genuinely curious what attack surfaces I'm missing — drop them in the comments. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse