The authority that releases an action must survive the model being wrong.
An agent that asks itself whether an action is safe still owns both sides of the decision. It proposes the operation, interprets the evidence, and decides whether its interpretation is sufficient. Adding a paragraph about caution can improve its behavior. It cannot create a boundary that survives the agent being wrong. Permission becomes meaningful when another component can prevent execution even after the model has decided to proceed.
Last week’s routing problem was choosing which capability should handle a request. This week’s problem starts when the chosen capability can change something. A useful answer and an authorized action require different evidence. The distinction matters even for a mundane workflow: an assistant preparing a customer incident update from internal records. Drafting the explanation, selecting attachments, and sending the message should not inherit one undifferentiated grant to “handle the incident.”
Consider that assistant as a proposed design, not a deployment I have tested. The user asks for a draft addressed to an existing customer contact. An incident note contains a suggested distribution list and says that the full diagnostic bundle should accompany the update. The model may reasonably consider those details relevant. Neither detail establishes that the suggested recipients may receive the bundle or that the user authorized sending anything. Retrieved content can supply facts without becoming a source of permission.
Four responsibilities need distinct owners. Model advice interprets what the user wants and proposes an action. Application policy defines which actions are eligible under the organization’s rules. User consent grants the requested action within the user’s own authority. Enforcement checks those inputs and controls the credential or operation that changes the system. Combining their descriptions in one prompt does not combine their authority. A polished explanation from the model is still advice.
This is established authorization engineering applied to a new caller. OWASP’s authorization guidance recommends denying by default, checking permissions on every request, and enforcing access controls where the caller cannot bypass them. A logged-in identity alone does not establish access to every object. For the incident assistant, the relevant question includes the specific customer, document, destination, and operation. “The agent is trusted” leaves those decisions unanswered.
The boundary therefore needs explicit inputs that the application can verify. In this example, I would carry the authenticated requester, resolved recipient identifiers, exact attachment revisions, requested operation, applicable policy version, and evidence of any required approval. The model can propose a recipient name; trusted application code resolves the actual account and its relationship to the customer. A model-generated field saying “approved” has no authority unless it points to an approval the application can independently establish.
Separate authority does not necessarily require another model, machine, or service. It requires an enforcement path the acting model cannot rewrite or avoid. Open Policy Agent documents the separation between policy decisions and enforcement: the application supplies structured input, obtains a policy result, and must enforce it. The important integration question is where a denied result stops dispatch. Calling a policy engine and then letting the agent decide whether to respect its answer preserves the original problem.
Deterministic rules should establish the floor before uncertain interpretation begins. In the proposed incident workflow, a draft-only grant cannot authorize sending. An attachment classified for internal use cannot become externally shareable because a model finds it helpful. A missing recipient identity should prevent delivery rather than trigger a guess. These are proposed rules for this example, not universal rules for every organization. Their owner must define them, and the execution path must apply them consistently.
A decision model can still help with the gray zone. It might identify whether a proposed explanation appears to reveal operational detail that needs review, or whether the requested action diverges from the stated task. Its output is evidence for a policy-controlled transition. An unavailable judge, an ambiguous result, or missing context needs an explicit disposition: retain the draft and route the unresolved question to an authorized reviewer. Calling a larger model does not supply the absent authority.
Consent deserves more precision than a button labeled “Continue.” If the user eventually requests delivery, show the resolved recipients, the message, and the exact attachments that will leave the system. OWASP’s transaction-authorization guidance calls for acknowledgement of significant transaction data and a final authorization check tied to execution. Applied here, approval should bind to the reviewed package. A changed recipient or attachment requires a new decision rather than reuse of the old confirmation.
That does not mean asking permission for every keystroke. The application can honor a prior grant for a bounded class of work while checking that each operation remains inside it. Preparing the draft and running an authorized read-only check need not repeatedly interrupt the user. The confirmation should resolve a real boundary, such as sending the reviewed material outside the organization. Repeated vague prompts add friction without clarifying what the person actually authorized.
The credential boundary determines whether those distinctions survive contact with the tools. A draft assistant with an unrestricted mail credential can bypass a carefully designed send tool through another available interface. OWASP’s excessive-agency guidance recommends minimal tool functionality, minimal downstream permissions, and authorization outside the model. For this design, keep sending behind the service that checks the grant. Inventory alternate routes as part of the boundary, including shell access and general network clients where they exist.
The permission check also has a lifetime. A reviewer can approve one attachment revision while another process replaces it before dispatch. The execution service should bind the decision to the reviewed bytes or immutable revision and reject a changed package. Approval should expire under a documented policy, and revocation must remain effective before execution. These controls cost more than carrying a Boolean through a chat session, but that Boolean cannot explain what was approved after the underlying work changes.
Authorization and successful execution need separate records. A permitted send can fail, and a timeout can leave its outcome unknown. Preserve the operation identifier and reconcile the downstream state before repeating a potentially completed effect. The application should report “delivery unresolved” when that is the evidence, rather than allowing the model to turn a missing response into either success or a fresh grant. A retry is another execution decision, not an excuse to forget the first one.
Keep the audit record outside the actor’s editable conversation. Record the request, resolved resource references, policy version, decision, approval reference, execution attempt, and verified outcome under a shared operation identifier. Open Policy Agent’s decision-log documentation shows how policy-query events can carry inputs and policy metadata, and describes masking sensitive fields. That is useful decision evidence; the application still needs execution evidence and storage controls. Copying a transcript into a mutable file does not make it an immutable audit trail.
The distinction is testable without trusting a model’s explanation. In a controlled test, give the assistant a prohibited send request and check whether the service prevents it. Change an attachment after approval, remove required policy input, make the judge unavailable, and present a note that claims the user already consented. These are proposed tests, not results from this article. Check the denied or held operation and its record, not merely whether the assistant apologizes.
A system can pass ordinary tasks while failing every meaningful boundary test. Judge its permission design by the action it refuses even when the model confidently recommends it, the ambiguity it hands to a named owner, and the record that survives a failed attempt. Grant autonomy to a defined operation with defined evidence. The component that wants to act should have to satisfy the boundary, not narrate its way through it.
Subscribe to Signal Over Noise for practical analysis of AI agents and automation: what to test, which constraints matter, and when a tool is worth using. Bring the next idea to one bounded workflow and check the result before expanding it.
If this was useful, forward it to one engineer who needs less noise in their feed.