In question, applied to reading.
What a state view looks like
If a state view is a controlled observation, something has to issue it and be able to check it later. The one thing it cannot be is the agent itself.
It also has to be written after the read came back, not when the read was allowed. Otherwise it only records what the agent could have seen, not what it actually got.
{
"state_view_id": "sv_01J...",
"view_version": 3,
"source": {
"system": "github",
"repository": "example/app",
"path": "config/deployment.yaml"
},
"observation": {
"source_version": "blob:8f31c2",
"fields": ["content"],
"observed_at": "2026-07-22T10:15:00Z"
},
"authority": {
"scope": "repository_read",
"granted_by": "policy:repo-read"
},
"issued_by": "boundary",
"content_trust": "untrusted"
}
The exact fields do not matter. What matters is that the agent did not write this record, and that it says enough to be checked later.
A view also does not have to be built in one read. Agents explore. They read, think, follow a reference, and read again. The view grows.
But the record itself should not quietly change. Each addition needs its own version, or a new record that points back at the previous one. Otherwise a request could point at a view ID that means something different by the time anyone checks it.
This is the same stale-state problem, one level up. A reference that moves under you is not a reference.
So the request points at one exact version.
{
"operation": "modify_file",
"target": "config/deployment.yaml",
"state_view_ref": {
"id": "sv_01J...",
"version": 3
}
}
State binding ties a request to the view it was given. State view control says whether the agent should have had that view at all.
Not every read needs a decision
I do not think every read should trigger an approval or a heavy policy check. That would make agents unusable, and it would be the wrong lesson.
Most reads can be admitted automatically inside a scope that was set beforehand.
The claim is narrower.
The agent may ask for a view. It should not be able to give itself one.
Read and write are not the same boundary
A write needs a decision before it can create impact. A read needs a scope and a record before the agent reasons on it, and again every time the view grows.
There is an uncomfortable side to this. The better an agent gets, the more it explores. It searches, follows links, and calls more tools until it has enough to act. The capability that makes it useful is the same one that widens its view.
That is why gating the write alone is not enough. The request can look perfect when it arrives. Current state, correct format, properly bound. And still be built on something the system never meant to show.
Controlling the outcome is half the path. The other half is controlling the view it came from.
A write changes the external system.
A read changes the world the agent reasons about.
Both belong inside the boundary.
Project: Impact Boundary Labs
SOCIAL SHARE CARD GENERATOR