Models can suggest. Code should decide.

Two different jobs#

A language model can derive plausible suggestions from incomplete context. It can interpret intent, arrange possible steps, and formulate a suitable tool request. That flexibility is what makes models useful. It is not a substitute for controlled execution.

Probabilistic model output and deterministic execution have different jobs. The model may suggest what could happen. Controlled code decides what is actually allowed to happen. When these layers are collapsed, a linguistic judgment becomes a privileged side effect without a clear boundary between them.

This separation is not an argument against models. It is what allows their strengths to be used where uncertainty is acceptable without transferring the same uncertainty into permissions and system state.

Put the trust boundary before the side effect#

A suggestion can be wrong, ambiguous, or incomplete. The trust boundary should therefore not sit behind the tool. It needs to sit at the point where text becomes a concrete action.

Deterministic code can check which tool is being requested, which permission the action requires, and whether the requested side effect fits the allowed task. The model contributes context and suggestions. It does not hold final authority over privileged actions.

This boundary also makes failure easier to reason about. A model error remains a bad suggestion at first. Only an explicit, controlled decision can turn it into a change in an external system.

Tokens do not belong in the model#

Tokens are capabilities in compact form. Whoever holds one can perform the actions it authorizes. Tokens therefore belong in controlled code, not in a language model’s context.

The model does not need to know a secret value to suggest a useful domain action. Execution code can hold the appropriate credential, check the permission, and carry out the action through a constrained path. The token stays outside probabilistic processing and outside freely generated output.

The same principle applies to privileged actions themselves. A model can state that a change may be needed. Whether that change is permitted depends on rules that the model’s phrasing must not be able to alter.

Least privilege is a domain decision#

Not every agent environment needs the same capabilities. Write access should be granted only when the task genuinely requires it. Read access remains read-only by default. A capability is not enabled speculatively because it might become useful later.

Least privilege is more than a technical list of permissions. The domain task determines the smallest useful set of tools and side effects. An agent doing research needs different boundaries from one assigned to update a narrowly defined record.

Control is part of the architecture#

Guardrails, trust boundaries, and permissions are not filters added after an otherwise autonomous model. They are part of the architecture. Within that architecture, the model remains a powerful suggestion mechanism.

The practical rule is simple: models can suggest; code should decide. The more privileged the possible side effect, the less its authorization should depend on probabilistic output.

TODO: Add concrete, publishable examples of controlled execution when their technical details can be disclosed.