Some files should be inviolable — even to your AI agents.
It answers exactly one question: does this PR's diff touch a path you listed?
Inviolable is a GitHub App that fails its check on any pull request touching the files you listed as protected — security rules, CI workflows, billing code, .env — so your branch protection rules can hold the merge until a human has looked at it.
Code verifies. The LLM does not self-report.
contents:write
Matching core will be open source
This keeps happening.
AI coding agents don't fail politely. They reach into files they were never asked to touch — and the worst incidents start exactly there.
* Survey of 418 IT & security practitioners; defines "AI agents" broadly (not only coding agents). Cloud Security Alliance / Token Security, Apr 2026. The first two figures are from the PocketOS incident (April 2026), sourced below. The ledger is one I keep myself: 10 AI coding-agent incidents, every entry with a primary source, no double-counting — half were secrets leaks, and the worst case above was caused by one too.
PocketOS — deleted in 9 seconds
April 2026. A Cursor agent (Claude Opus 4.6) hit an auth error during staging work, found an over-scoped Railway token in an unrelated file, and wiped the production volume — and every volume-level backup stored inside it — with a single API call, in 9 seconds. The backups died with the data — Railway kept them in the same volume — so the newest restorable backup was three months old, and the gap was rebuilt by hand. Its customers ended up reconstructing their own bookings from Stripe payment histories, calendar integrations and email confirmations. The root cause was a secret sitting where an agent could reach it.
Sources — Zenity: "System Prompts Are Not Security Controls" (9 seconds; backups in the same volume) · Tom's Hardware (3-month backup; manual reconstruction) · Fast Company · NeuralTrust security post-mortem
Replit — "I didn't delete it." It did.
July 2025. An agent ignored an explicit code-freeze instruction, deleted a production database — and then misreported what it had done. The agent's own account of its work was wrong. Any protection that trusts the agent's self-report inherits this failure mode.
Sources: Jason Lemkin (first-hand) · The Register
Built-in guardrails share the agent's fate.
In the PocketOS incident, project rules were written, Cursor advertises destructive-action guardrails, and Claude Opus 4.6 is marketed on tool-use safety. Every one of those layers existed that day. None of them produced the intervention it was sold to produce.
Nor is that one bad day. In January 2026 The Register reproduced Claude Code reading a .env file that .claudeignore was supposed to put off-limits — while the documentation promised it would "refuse to read any files matching patterns listed there." Developers keep filing it ("Claude read the env file with all my secrets… There is no warning. No error."). The exclusion list was right there in the repo. It just wasn't load-bearing.
So Inviolable runs where the agent can't reach: as a GitHub Check on the pull request itself. It never asks a model whether a change "looks safe." It computes the actual diff and matches it against your protected paths — deterministically. Either a protected file changed, or it didn't.
One file. Three rules. No exceptions.
List your inviolable set
Commit one file to your repo. That's the whole setup — no org rulesets to configure, no admin console.
Deterministic check, fail-closed
Every PR is diffed against the list. A protected path in the diff → the Check Run reports failure. Config broken, API error, oversized diff, renames, symlinks? Also failure. Anything it can't verify, it reports red rather than guessing.
The gate opens on GitHub's terms, not ours
Inviolable is a required status check. Red means GitHub itself refuses the merge — and the only way through is a human with branch-protection bypass, deciding deliberately and leaving a record in your audit log. We don't build our own approval mechanism, so there's nothing of ours for an agent to talk its way past.
# .inviolable.yml — that's the entire setup protected: - firestore.rules # security rules: one bad line = open database - .github/workflows/** # whoever controls CI controls everything - src/billing/** # bugs here cost real money - CLAUDE.md # the agent's own instructions - ".env*" # nothing to discuss # .inviolable.yml itself is always protected — implicitly, non-negotiably
human reviews the actual diff, decides → merges with bypass (recorded in your audit log)
agent pushes e77d4b1 · touches it again → red again · re-decided every time
Setup takes one manual step we can't do for you: adding Inviolable to your branch protection rules. That's deliberate — automating it would mean asking you for admin permissions, and this App is built to hold as few permissions as possible.
What Inviolable does not catch.
A tool that claims to catch everything is the kind of tool this whole page is arguing against. So here is the boundary, up front, before you sign up for anything.
Inviolable answers exactly one question: does this pull request's diff contain a path you listed as protected? It reports the answer as a passing or failing check. It does not judge whether a change is good, and it does not stop a merge by itself — your branch protection rules do that, and you control them.
| Not covered | Why |
|---|---|
| Changes that never open a pull request — direct pushes to a protected branch, admin force-pushes, rewritten history | We read PR diffs. That's the whole input. |
| Anyone with branch-protection bypass merging anyway | That's the design. A human is supposed to be able to decide — and their decision is recorded. |
| A repo where the check isn't a required status check | Then the check goes red and the merge goes through anyway. We can't see your branch protection settings, so we can't warn you — which is why setup ends with a test you run yourself. |
Whether the paths in your .inviolable.yml are the right ones | Deciding what matters in your repo is your call, not ours. A path you didn't list isn't protected. |
| Secrets, vulnerabilities, or bad code anywhere outside your protected paths | This isn't a scanner. Different job, different tools. |
| Anything outside GitHub pull requests | Local machines, other hosts, changes made during a CI run. |
Setup finishes with a two-minute test: change a protected file in a scratch PR and watch the merge get held. Don't take our word that it works — make it go red once, with your own eyes. That is, after all, the entire argument of this page. See the setup & Prove-it steps →
"Can't I do this with GitHub's built-in rules?"
Sometimes — and if they fit you, use them. Honest answer, because you'll check anyway:
GitHub can gate paths natively — if you're an organization: Required-reviewers rulesets gate path-matched PRs behind designated teams, push rulesets (Team plan, private/internal repos) can block pushes by file path, and CODEOWNERS + branch protection requires owner review. If you're an org admin willing to wire those up, that's a legitimate setup.
| GitHub native rules | Inviolable | |
|---|---|---|
| Personal & public repos | ✕ org / Team-plan features | ✓ any repo |
| "Approve to unlock" human gate | △ org + team wiring | ✓ one file in the repo |
| Behaviour when the checker itself is down | — | ✓ we never silently start reporting green |
| Fail-closed on the unverifiable (broken config, API failure, huge diff, symlink/rename) | △ if you build it yourself | ✓ designed to report red, not guess |
| Protection config protects itself | ✕ rules managed separately | ✓ .inviolable.yml always covered |
AI-agent presets (CLAUDE.md, .cursorrules, …) | ✕ generic primitives | ✓ built for this threat |
| The guard itself can write code | admin scope is broad | ✓ physically cannot — no contents:write |
GitHub feature availability verified against docs.github.com / github.blog changelog, Jul 2026.
Built to be distrusted.
A tool that guards your most sensitive files should assume you'll audit it.
No diffs or file contents stored
The safest copy of your code is the one that was never made. Breaches keep turning out to involve data sitting somewhere it didn't need to be — so we don't keep a second copy of yours. Diff contents are matched and discarded, never retained. We do record the path names that matched, so the check result and the audit trail mean something.
No contents:write — ever
The App requests read-only repo access plus Checks. It is physically incapable of modifying your code. "Doesn't auto-fix" isn't a policy choice; it's a permission the App does not hold.
Open-source matching core
The path-matching and diff-verification core will be published, so you can audit exactly what gets checked — and how it fails closed. It is also your exit: if this service ever shuts down, the same protection keeps running in your own CI.
Get the same gate, without building it yourself.
Inviolable packages a setup its author has run on a production repo for months. It's in development — planned free for public repositories, paid for private ones. The waitlist doubles as a 3-question survey that directly shapes what gets built. Read what it doesn't catch before you decide it's for you.
Join the waitlist →No credit card · no spam · one email when early access opens
日本語の方へ
Inviolable（インバイオラブル）は、AIコーディングエージェント（Claude Code / Cursor など）による「触ってはいけないファイル」への変更を検知し、そのPull Requestのチェックを不合格として報告するGitHub Appです。firestore.rules・CI設定・課金コード・.env などの保護パスを .inviolable.yml に1ファイル書くだけ。変更は実際のdiffで決定論的に照合し（AIの自己申告は信用しません）、保護パスに触れていればCheck Runを失敗として報告します。マージを止めるのは当App自身ではなく、あなたが設定したブランチ保護ルールです——独自の承認コマンドは作りません。GitHubの権限モデルにそのまま乗ることで、エージェントが言いくるめられる「当社製の承認機構」が存在しない状態を作っています。
最も安全なデータは、そもそも2箇所目にコピーしなかったデータです。本来そこに置く必要のなかったデータが置かれていたために漏れる——という事故が繰り返されています。ですから当Appは、お客様のコードの2つ目の置き場所になりません。diffの内容とファイルの中身は保存せず、contents:write 権限も一切要求しません（App自身がコードを書き換えられない設計）。保護パスに一致したパス名のみ、チェック結果の表示と監査のために記録します。照合コアはオープンソースとして公開予定です。
検知しないものも先にお伝えします。PRを経ない変更（直接push・強制push・履歴書き換え）、バイパス権を持つ人が意図的に行うマージ、ブランチ保護を設定していない場合、.inviolable.yml に書き漏らしたパス、保護パス以外のファイルの中身——これらは判定対象外です。当Appはブランチ保護の設定状況を確認できませんので、導入の最後に「保護ファイルを変更したPRを作り、マージが止まることを自分の目で確認する」テストをお願いしています。
現在開発中で、ウェイトリストを受け付けています。設問は英語ですが、日本語での回答も歓迎です。