How execution boundaries reduce the blast radius of AI agent mistakes

How execution boundaries reduce the blast radius of AI agent mistakes

AI agents make mistakes. Not rarely, and not only the weak models - a strong model working from a stale diff, a misread document, or a hostile instruction will eventually propose the wrong effect. So the interesting engineering question is not "how do we make agents never wrong?" It is: when a wrong proposal executes, how big is the damage? That is the blast radius problem, and it is mostly determined by one design decision: where the execution boundary sits.

Intent is not the effect

An LLM's output is a proposal. It becomes real only when a tool applies it - a shell command runs, a file is written, an API is called, a token is spent. Everything the model "did" before that moment is just text.

Most current safety work lives on the intent side: better prompts, permission dialogs, code review, least-privilege tokens. These help, but they share a structural gap: the permission gate is coarse (this token can write to this repo; this agent may run shell commands), while the effect itself can still be unbounded in shape. An agent with repo write access can close issues, rewrite history, or rename resources in one confident pass. The token was scoped. The blast radius was not.

What an execution boundary is

An execution boundary is the point where a proposed effect meets the actual state it would change. In an experimental project I have been building - Guardian Core, an experimental Safe Execution Core - the boundary does two things:

• State-bound execution. Effects are not free-form actions. They are expressed as bounded changes against a declared state - a filesystem scope, a repository, a server - and the boundary validates the proposal against that state before anything happens.
• Evidence-based outcomes. After execution, the caller receives evidence: what changed, where, and with what result. The outcome is a record, not a story.

The goal is not to make the agent smarter. It is to make the effect smaller by construction.

A concrete example

Suppose an agent is asked to "clean up build artifacts" in a project.

Without a boundary, the agent runs something like rm -rf ./build. If it misread the layout - or a prompt injection nudged it to clean "a bit more" - the command deletes whatever it resolved to. The blast radius is the command's reach.

With an execution boundary, the agent instead proposes a bounded change: delete the files matching *.o under ./build. The boundary validates the scope (paths inside the declared area, operation type allowed), applies the change, and returns evidence: which files changed and with what result. If the proposal resolves to something outside the scope - a symlink escaping the tree, a path that no longer exists - the change is rejected before execution, and the rejection itself becomes evidence. The mistake still happened. The damage did not propagate.

What the evidence actually is

Guardian Core is experimental research code, and I want the claims to stay inside what exists today:

• Four domain experiments: Filesystem, GitHub, and VPS/Dokploy are implemented as conformance adapters against one core; Email is a later, independent fourth validation.
• The core and its adapters carry their own test suites (41 tests in Guardian Core; the VPS/Dokploy proof carries 179 - counts as of this writing).
• The result model returns evidence of what was executed, not a promise about the world.

What it explicitly does not provide: universal distributed atomicity, exactly-once semantics, or a guarantee that a bounded effect is always the right one. Concurrency between independent agents touching the same state is a real limitation, and the repository says so plainly. If two agents execute overlapping changes, the evidence will show what happened. It will not un-happen it.

Takeaways for agent developers

• Put the boundary at the effect, not the prompt. Prompt rules are advisory. The tool call is the contract.
• Budget blast radius per tool. Every tool should answer: what is the worst single call this can do?
• Make evidence a first-class output. "It succeeded" is a story. "These 14 files changed, with these results" is evidence.
• Design for containment, not perfection. Assume a wrong proposal eventually passes your checks. What limits it then?

Your turn

How do you cap blast radius in your agent stack today - allowlists, sandboxes, review gates, effect-typed tools? And what would an execution boundary need to expose before you would let an autonomous agent operate inside your own domain?

Repository (experimental, feedback welcome): https://github.com/AndersonVitaease/memoryos-guardian-core