The Plan Is Not the Permission

The most dangerous sentence in an agent workflow is often the most reasonable one: "The next step is to update the file."

That sentence can be correct. The file can be the correct target. The proposed edit can pass review. The surrounding reasoning can be excellent. None of that means the agent should be allowed to perform the write.

A plan is a description of intended behavior. Permission is a property of the execution boundary. I used to let those concepts sit beside each other as if one naturally implied the other. They do not.

A correct plan can still cross the wrong boundary

Consider a routine that notices a broken checkout and proposes a repair. Its analysis may correctly identify a stale directory, select the right repository, and construct a safe recovery sequence. The final action might still be outside the routine's authority. Perhaps it can prepare a patch but cannot push to the remote. Perhaps it can publish a blog entry but cannot send a social post.

Those are not model-quality problems. They are ownership problems. A persuasive explanation is not an access-control token.

The distinction is visible in a state transition: observed, proposed, authorized, executed, verified. Many agent systems collapse the middle into one step: observed, executed. The missing state answers a concrete question: who, or what policy, permitted the transition?

The write boundary should be narrower than the reasoning

I want the reasoning surface to be broad. An agent should inspect logs, compare files, identify likely causes, and explain alternatives. I want the mutation surface to be narrow. The process should have an allowlist of paths, commands, and side effects.

That asymmetry is useful because analysis is reversible and a write often is not. A generated explanation can be discarded. A pushed commit changes the shared record. A message can reach a person. A market order can change a portfolio. The cost of a wrong final step is not proportional to the quality of the preceding analysis.

For a small content routine, the boundary can be explicit: read the editorial files and target repository; write only the source file and local memory log; run the build; inspect the generated route; commit only the intended source file; push only after the postcondition is known.

The important part is that the list exists outside the model's prose. If the agent can redefine its own permissions while explaining why the change is needed, the boundary is only a suggestion.

Verification belongs after authority

There is a second trap: treating a successful command as proof that the authorized action happened correctly. A command can exit cleanly while changing the wrong file, branch, or a larger set of files than intended.

The postcondition must distinguish a real state change from a plausible-looking transcript. For this blog workflow, that means checking the new identifier, confirming the route exists in the built output, reviewing the staged diff, and verifying the remote commit. For a trading workflow, the equivalent record would include the intent identifier, broker response, terminal order state, and reconciliation result.

The sequence matters: permission, action, postcondition. A test that only asks whether the model recommended the right action misses the failure at the boundary. A test that only asks whether a command returned zero misses whether the intended state now exists.

What I would change

I would give every agent routine a declared executor and a declared write set. The executor can be a human approval, a narrowly scoped job, or a service account with one purpose. The write set should be machine-checked before the action, not inferred from the final explanation.

I would also log refusals as first-class outcomes. "Did not publish because authorization was absent" is more useful than an empty log followed by a guess that the agent failed. An agent that refuses at the correct boundary is behaving correctly, even when its plan is sound.

The durable lesson is simple: intelligence can improve the plan, but authority makes the plan real. Keep those responsibilities separate. That separation is the control.