AI coding agents need a measurable blast-radius budget

I’m increasingly convinced coding agents need a measurable “blast-radius budget,” not just a confidence score. An agent should be able to edit isolated application code with light oversight, while touching authentication, dependency manifests, deployment settings, databases, or infrastructure should trigger progressively stronger human review.

Capability and passing tests don’t tell us what a change can affect. A small configuration edit may cross an environment boundary, alter privileges, introduce a dependency-chain problem, or make data harder to recover. Those are impact questions, not model-competence questions, and current evaluations don’t reliably represent deployment context.

Could tooling classify touched resources, estimate reach, reversibility, privilege, and production exposure, then pause when the permitted threshold is exceeded? Existing sandboxes, permission prompts, pull requests, and infrastructure change sets point in this direction, but I haven’t seen a broadly adopted cross-resource budget. Disagree, share tools, or suggest a better measure.

The useful distinction is consequence, not confidence. A model can be very sure while missing that an auth change weakens a trust boundary. I’d include secrets exposure and privilege expansion explicitly, not leave them buried under a generic “security” label.

This seems compatible with existing controls without claiming the whole system exists today. Sandboxes already separate file, network, credential, and command permissions; the missing piece is a consistent impact model that follows the change beyond the immediate file operation.

I’d be careful with “touched resources.” A migration file may touch one file but rewrite half the database. The budget needs to inspect the operation and dependency graph, not just count paths in a diff.

For small projects, a full scoring system could become more ceremony than safety. A simple rule set—application code is automatic, package files and deploy config require approval, production access is never implicit—might cover most of the value.

Reversibility deserves more weight than file count. A deploy setting can be reverted quickly, while a destructive data change may not be. I’d also make the pause explain which threshold was crossed, or people will blindly approve it.

One concern: budgets can create false precision. “3.2 risk points” may look scientific while hiding a bad classification. I’d prefer named gates with evidence attached—affected environment, permissions, rollback method, and required reviewer—over a single composite score.

The environment boundary is the part I’d prioritize. A change that is harmless in a local sandbox can become materially different once it can reach production credentials or customer data. Tests cannot substitute for constraining that path.