Who May Make This Change?
You approved an edit. Then the document changed. What should the agent be allowed to write?
Follow one approved edit through a document service. This teaching model changes the grant, the document and the request to show what each check protects.
3:45 Interactive Article3:45 · Narrated by Ara · Captions optional Open in 4K ↗
Read the narration
Who may make this change?
An agent has permission to edit a document. You approve its proposed change. Before it writes, somebody else edits the same section. Does your earlier approval still apply? The answer depends on what the approval identifies, and what the service checks when the write arrives.
A grant narrower than the owner’s access
In this invented example, Ines asks an agent to tighten a section called Limits. She gives it a narrower grant than her own access: one document, one section, one action, an expiry time, and the agent’s proof key. Each restriction removes possibilities.
Record the exact change
At ten oh four, Ines approves the proposed text. The service records the target, the version the agent drafted from, and the new text as one digest. The digest identifies those bytes. The approval’s authority comes from Ines’s signed-in action, not from the hash itself.
Check at the point of the write
At ten oh six, the agent submits. The service checks the grant, its presenter, its validity, its scope, and Ines’s own rights. It also checks the document version and the exact approved change. All nine checks pass. The version comparison and the write happen in the same step.
The document changed after approval
Now suppose Tomas edits Limits after Ines approves, but before the agent writes. The current section no longer matches the approved base version. Check eight refuses the write, and Tomas’s edit survives. The next step is to read the changed section and prepare a new proposal.
A name does not identify a version
Change one setting: let approval name only the section, field-notes slash Limits. In this model, no version is named, so check eight is not run. The section name still matches, and the write is allowed.
What the missing check permits
Tomas’s edit is overwritten without being reviewed. A standing permission could have a separate version check and prevent this lost update. But that would still be a different policy from approving specific new text. Version protection and content approval answer different questions.
The request can change too
Change the request instead. Nobody edits the document, but the agent submits words Ines never approved. The scope and version checks pass. Check nine alone refuses the write, because the submitted change differs from the recorded approval.
The confused deputy
Now the agent directs the request at a handbook Ines may only read. The service authenticates the grant, but then writes using its own broader storage privilege, without checking the delegated request. The handbook is overwritten. This is the confused-deputy problem: the service uses its authority on someone else’s unchecked instructions.
Enforce the delegation
Switch the service back to checking the delegation. Its storage privilege is unchanged, and so is the request. This time scope, Ines’s rights, the version, and the approval checks refuse it. The boundary is enforced by the component that can actually make the change.
A copied bearer grant
Another process presents a copy of the grant. Under a bearer policy, possession is enough, so the write is allowed. The decision log correctly says that no sender was verified. A recorded name would not, by itself, prove who presented the request.
Bind presentation to a key
Bind the grant to the agent’s key, and the same copy fails check three. The copy holder cannot produce the required proof. This establishes which key presents the request. It still does not establish whether the submitted text is the text Ines approved.
Distinct questions need distinct checks
Return to the approved change with every check in place. Grant integrity, presentation, scope, validity, the owner’s rights, the document version, and the approved content are distinct questions. The log records the decision afterwards. It cannot replace a check that the service never performed.
Approval at the moment of change
For approval of a specific edit to protect the work, the service must check the exact change against the version it was approved on, using authority no wider than the owner’s, at the moment it writes. In the interactive example, remove one binding at a time and see what that permits.
Authorship and contributions
Author: Loki
Claude (Opus 5.5, Claude Code) (2026-10-04: cue file, capture, frame inspection and this manifest, under Loki's direction)
Moiré (2026-10-09: spoken adaptation and delivery under Loki’s direction)