DEV Community: AndersonVitaease

How execution boundaries reduce the blast radius of AI agent mistakes

AndersonVitaease — Sat, 05 Sep 2026 18:52:26 +0000

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

Giving AI Agents Capabilities Without Giving Them Unrestricted Authority

AndersonVitaease — Sat, 05 Sep 2026 14:58:52 +0000

As AI agents gain access to real tools, I've been thinking about a problem that seems increasingly important:

Giving an agent a capability often means giving it more authority than the specific action requires.

Consider a simple architecture:

Agent → Tool → Real System

The agent may only need permission to perform one specific operation, but the tool behind that operation may expose much broader authority.

I wanted to explore whether a small execution boundary could sit between the agent and the real system.

That experiment became Guardian.

The basic idea

Instead of:

Agent → Tool → System

the execution path becomes:

Agent → Guardian → Controlled Effect + Evidence

The agent proposes an intent.

Guardian then:

binds that intent to the current state;
checks whether execution is eligible;
dispatches a controlled effect;
reports what can actually be proven about the result.

The Core deliberately stays small:

bind → gate → apply → result

Guardian is not intended to decide what the agent should do.

It is intended to constrain what happens when the agent is allowed to do something.

Why put the boundary at execution time?

Agent frameworks are becoming increasingly capable at planning, reasoning and selecting tools.

But better reasoning does not necessarily reduce execution authority.

An agent can make a perfectly reasonable decision and still invoke a tool whose credentials or API surface allow significantly more than the intended operation.

So I wanted to separate two questions:

What does the agent want to do?

from:

What exact effect should the system permit?

Guardian focuses on the second question.

Five properties I'm exploring

The experiments so far have converged on five candidate properties:

1. Non-expandable authority

Execution should not silently become broader than the approved intent.

2. Fail-closed eligibility

If the system cannot establish that execution is eligible, it should not dispatch the effect.

3. State-bound execution

Approval should be tied to the state that was actually inspected, rather than assuming the world has not changed.

4. Intent-confined controlled effects

The adapter performing the operation should expose the smallest practical mutation corresponding to the approved intent.

5. Epistemic honesty with indeterminacy

If the system cannot prove what happened, the result should say that instead of converting uncertainty into success.

These are currently engineering properties being explored, not formally verified guarantees.

Testing the idea across different domains

I didn't want the design to exist only as an abstraction, so I tested the same small Core across different execution domains.

So far there are four experimental domain proofs:

Filesystem
GitHub
VPS/Dokploy
Email

Three are Core conformance adapters: Filesystem, GitHub and VPS/Dokploy.

Email was built later as an independent fourth validation.

The purpose wasn't to prove that Guardian is universal. It was to see whether the same execution-boundary idea survives contact with domains that have very different mutation semantics.

That distinction matters.

Filesystem writes have TOCTOU concerns.

GitHub exposes useful native state preconditions such as SHAs.

VPS deployment has different concurrency and backend semantics.

Email has a fundamentally different problem: once a message is sent, the effect isn't something you simply roll back.

A useful execution boundary has to acknowledge those differences instead of pretending they don't exist.

What Guardian does NOT claim

The project is experimental.

It does not currently claim:

formal verification;
distributed exactly-once execution;
universal agent safety;
protection against malicious adapters;
elimination of every concurrency race.

Some domains provide stronger primitives than others, and the evidence returned by Guardian is deliberately allowed to represent uncertainty.

I think that is preferable to reporting certainty the system doesn't actually possess.

Where this might fit

The architecture I'm exploring looks roughly like this:

AI Agent
↓
Tools / MCP
↓
Guardian
↓
Real Systems

The agent can still use powerful capabilities.

The idea is simply that capability does not automatically imply unrestricted authority.

The implementation is intentionally small because I'm trying to understand whether the execution boundary itself is useful before building a larger platform around it.

The code and the four domain experiments are public here:

https://github.com/AndersonVitaease/memoryos-guardian-core

I'm especially interested in criticism from people building AI agents, MCP servers, coding agents or agent infrastructure.

Should this kind of safety boundary exist at execution time, or do you think these guarantees belong somewhere else in the agent stack?