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
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?
Top comments (0)