Raghu Vintha

Make authority visible before an agent acts.

Most of the failures I’ve seen come from treating a proposal, permission and proof as though they were the same thing. I design for a clear separation between them.

Three things to keep separate
Proposal
What the agent wants to do.
Permission
What it is authorised to execute.
Proof
The evidence of what actually happened.

What follows is how I approach that separation. Each pattern is written the same way: the constraint that forces it, the design choice, how I try to break it, and where it stops working. That last part matters most, and it’s the part usually missing.

These are patterns, not a certificate. They describe how I build and what I check for. None of them is a statement that a particular deployed system has been independently verified against them.

Most of what I build is client or product work and stays private. What is here is the method.

Approval should name the action

The constraint. An approval has to survive being read two years later by someone who wasn’t there. “Approved” on its own doesn’t survive that. It records that a click happened, not what was authorised.

The design. An approval needs to identify exactly what the person said yes to.

What a specific approval contains
Action
The change that is being proposed.
Resource
What that action will affect.
Scope
The limits within which it is permitted.
Evidence
What the reviewer was looking at.

If the proposal changes after approval, the approval doesn’t carry over to the new one. If it expires, execution stops. Scope is bound before the proposal is made rather than inferred after the approval is given, because otherwise “yes, do this” quietly becomes “yes, you are trusted”, and the blast radius stops being something anyone actually chose.

How it is enforced, and what is not yet tested. The approval binds to a hash of the structured proposal — the action, the resource, the scope — and not to its prose. That is a structural property rather than a promise: a changed target produces a different hash and therefore cannot satisfy the approval issued for the original. Changed is defined rather than felt. Hashing free text would be the wrong design in both directions, making a reworded sentence a rejection and a materially different action a pass.

The negative paths are what would prove the rest. Swap the target after approval, remove the approval, replay an old approval against a new proposal, and confirm in each case that the refusal leaves an inspectable record, because a silent refusal and a silent execution look identical in a log. I have watched controls of this family refuse in ordinary operation. I have not sat down and run those three as a deliberate adversarial suite, and a passing test of the approval screen would only prove that the screen works.

Where it fails. The gate isn’t a control, it’s an interface for someone’s judgement, and judgement degrades under conditions the diagram doesn’t show. A reviewer who can’t understand the evidence in the minutes they actually have will approve by habit. Then the records are worse than useless, because they document approvals with no judgement behind them. Singapore’s framework makes the same point from the other direction: it suggests watching the human override rate, on the reasoning that a low rate may signal rubber-stamping, and watching review times, because a short one may signal automation bias. How the evidence is presented, and how long there is to judge it, are part of the control. If they aren’t designed, the control is decorative.

Memory doesn’t grant permission

The constraint. An agent that can retrieve is an agent that can be instructed by whatever it retrieves. A note explaining a past decision and an instruction to take a new action are the same shape once they are both text in a context window.

The design. Two planes, kept apart. Knowledge is what the system has learned and may consult. Control is what the system is permitted to do. The authority lives in the records themselves, plain files under version control, and the search index is a cache that can be thrown away and rebuilt.

The load-bearing part is where the separation is enforced. “Retrieved content is not a command” is a goal, and a goal written into a prompt is a request. So the agent’s credential is read-only against the record, and the write path is one it holds no tool for. It cannot widen its own boundary because nothing it can call does that, not because it was told not to.

How I verify it. Delete the index and rebuild it from the records, then confirm the system answers the same way. If the rebuilt index disagrees with the old one, the index was holding state that nothing else held.

The containment itself is structural rather than tested: the agent’s credential is read-only against the record and it holds no tool that widens its own boundary. That is a design property you can read straight off the permission model. Adversarial testing of retrieved content, planting a hostile instruction and confirming it is treated as data, is the obvious next check and one I haven’t run.

Where it fails. Neither check says anything about whether the records are correct. A rebuildable index will faithfully reproduce a wrong answer. Separation of planes is a containment property, not a truth property, and the distinction matters because “our memory is governed” gets heard as “our memory is right”.

The version-control claim needs a limit on it too. Git makes tampering visible to anyone holding an independent copy; it does not make it impossible, because amend, rebase and force-push all rewrite history. Whoever holds push rights can edit the audit trail, which is the same pathology as an agent editing it. The control is the trust boundary around the remote — signed commits, a protected branch, a mirror the same people cannot rewrite — and a design that leaves that unnamed hasn’t solved what it thinks it has.

Handoff without inherited assumptions

The constraint. Work moves between agents and between sessions. What travels well is a summary. What travels badly is the evidence the summary was based on. The failure is quiet: a receiving agent reads “tests pass”, treats it as established, and builds on a claim that was true of a revision that no longer exists.

The design. A handoff names the objective, what is genuinely done, what is unresolved, where the evidence lives, and the exact next action. Evidence is referenced by location and revision, never restated as a conclusion. The receiving agent establishes its own permission to act rather than inheriting the sender’s. Secrets are never written into a handoff; the handoff names where the secret is stored.

How it is enforced. The receiving agent establishes its own permission rather than inheriting the sender’s, and evidence is referenced by location and revision rather than restated as a conclusion. The state a session resumes from is governed by a versioned contract with hard limits — a maximum line count, a maximum size, exactly one resume target — and state exceeding them is rejected outright rather than warned about. On the day this page was written, that contract refused my own checkpoint six separate times until it was condensed to something a stranger could read.

The adversarial checks are what would prove the remainder. Resume from a handoff whose evidence has been deleted, and from one whose revision has moved underneath it, and confirm the receiver stops and names the gap. If it proceeds instead, it has converted a summary into proof, which is the exact failure the pattern exists to prevent.

Where it fails. This describes a contract, and a contract is only as good as the discipline of whoever writes to it. A handoff written under time pressure will overstate what is done, and no receiving check can detect a confident lie about work that was never attempted. The pattern reduces silent inheritance. It doesn’t manufacture honesty.

Full references

Each of these patterns is written up as a reference an engineer can read and copy from, rather than a library to depend on.

Writing →