The permission map every Claude Code agent needs (and the column most teams skip)

kuro-tomo — Wed, 23 Sep 2026 02:54:11 +0000

The question that matters more than "does the agent work"

Over the past several months I've been running structural governance checks on AI coding agents — mainly Claude Code — across a handful of active projects. Not code review. The specific question: what can this agent's tools actually reach, and does anything catch it when it reaches the wrong thing?

The pattern

An agent has a tool — a payment API, a messaging API, a deploy hook, whatever — that can act on the outside world. Somewhere in the flow, the agent's own summary says the action succeeded. But the guard that was supposed to sit in front of that call was either never wired up, or wired up against the wrong trigger (checking for a specific error string that changed after a dependency update, say). The agent isn't lying. It's reporting what it observed, and what it observed was incomplete.

A permission map, in practice

Tool	Reach	Guard exists?	Guard actually fires?
Read repo files	read-only	n/a	n/a
Write to feature branch	reversible	n/a	n/a
Call payment API	irreversible	yes (claimed)	no — checks wrong status code
Post to Slack/webhook	irreversible	no	no

The first two rows are usually easy to get right. The third column — "guard actually fires" — is where I've now found the same gap on three separate setups: a guard that exists on paper (someone wrote it, it's in the code) but doesn't fire against the real failure mode, because nobody re-verified it after whatever it depends on changed shape.

What actually catches this

A checklist that:

Maps every tool call by blast radius (read-only / reversible / irreversible).
Traces where the irreversible ones actually land — the real endpoint, not the one you remember configuring.
Deliberately tries to break each guard instead of just checking it's present. If a guard hasn't been broken and caught in the failing state, I don't count it as verified.

That third step is the one almost nobody does, and it's the one that finds the real bugs.

If you want this run against your own setup

I've turned this into a fixed-scope written audit — $950 flat, 2–3 weeks, everything async (no calls) — for anyone who wants steps 1–3 run against their own agent: mabokko@gmail.com. Also happy to just talk through the pattern above if that's more useful to you than paying for the full thing.

SinkSeal: git-hook guardrails for AI coding agents

kuro-tomo — Wed, 02 Sep 2026 05:23:23 +0000

I built this after watching an AI-agent-built demo feature get wired straight to a live SMS/voice vendor — no guard, no synthetic-tenant check, just the same code path production used. A routine demo session produced real phone charges.

SinkSeal is a set of git hooks (bash, no runtime dependency beyond git + grep/sed) that catch three things on every commit and push, regardless of which agent (Claude Code, Cursor, Codex, or a human) writes the code:

secrets, via gitleaks (warns rather than blocks if gitleaks isn't on your PATH — install it separately for this check to actually run)
risk-category changes (auth, payments, migrations, etc.) — flagged, not blocked, but requires an explicit commit-message trailer acknowledging it
"live-fire" calls to external irreversible-action APIs (SMS, payment, public-posting) reached from demo/test code paths — hard-blocked if the path looks like a demo, soft-flagged otherwise

Why git hooks, not a CI check

CI catches a bad diff after it's already pushed. A git hook catches it before the commit even lands, regardless of which coding agent (or human) wrote the code — the enforcement lives in the hook, not in any one tool's configuration or system prompt.

Install

git clone https://github.com/kuro-tomo/sinkseal
./sinkseal/install.sh /path/to/your/repo

This copies the hooks self-contained into <repo>/.githooks/, so it survives even if you later delete the sinkseal checkout, and it's inherited automatically by any git worktree of that repo.

Free and MIT-licensed: https://github.com/kuro-tomo/sinkseal

Feedback especially welcome on the pattern-matching approach — it's inherently a probabilistic safety net (regex-based), not a completeness guarantee, and I'd rather know where it's weak than oversell it.

DEV Community: kuro-tomo