A boundary you
can read later.
A Boundary Receipt records what an agent was allowed to see, what was blocked, and what is still unknown — so the decision can be reviewed after the fact, not reconstructed from memory.
Illustrative sample. A Check-in receipt records the decisions made for one path; it is not a tamper-evident production audit log.
Allowed, blocked, unknown — and why.
Three honest states. The point is not to hide the unknowns, but to name them so they can be decided.
In scope
Fields and sources the agent may see and assemble for this declared purpose.
Out of scope
What the agent must not see, combine, or output on this path — and the reason.
Not yet decided
Paths that are real but undecided — surfaced, not silently allowed.
What a Receipt does — and does not — claim.
The same discipline we apply to your agents, applied to our own words.
What it does
- + Records what was allowed, blocked, and left unknown for one path
- + Names the declared purpose the boundary was resolved against
- + Makes a decision a company can read and review later
- + Shows where assembly and output create the real exposure
What it does not claim
- − It is not a compliance certification (SOC 2 / ISO / GDPR / AI Act)
- − It is not a tamper-evident production audit — that is enforcement, not a check-in
- − It does not promise an agent will never leak data
- − A declared purpose is a label, not an authorization
Aegis Gateway is the planned runtime entry point that would enforce and record boundaries against a non-cooperating agent. The first public offer is the advisory Boundary Check-in — mapping, not enforcement.
See your first Boundary Receipt.
Run a Boundary Check-in on one agent, one data path, one use case.