01
A model can propose an action but cannot authorise it
Consider a customer-service request to cancel an order or change an address. The model can classify the intent and collect the required details. It cannot decide that the user is authorised or call any backend command that it can describe.
Application code checks identity, order ownership, status, policy, and command permission. It then exposes a narrow business command such as request cancellation. The command accepts a typed input and returns a controlled result.
02
Keep tenant and user boundaries before retrieval and action
Every request has an authenticated user and tenant context. The application applies this context before it retrieves evidence or lists tools. The model cannot change the tenant identifier, add a role, or select a protected endpoint.
The same rule applies to enterprise assistants. Advisory questions can use approved public or role-approved content. An order-status or credit-limit lookup requires the authorised user, endpoint, and credentials. One interface does not mean one permission set.
03
Control spend and repeated execution
The application sets model, token, tool, time, and cost limits for each task. It records provider calls and can stop work when a limit is reached. Cache use and provider selection follow application policy.
A command also needs replay control. Use an idempotency key or business operation identifier. Record the request, decision, approval, command, and result. A retry can then return the earlier result or continue safely. It must not create the same order, payment, export, or update twice.
04
Treat all model and document text as untrusted input
A document can contain text that asks the model to ignore rules or call a tool. A user can make the same request. Neither source can grant permission. The application validates tool arguments and command policy after the model returns them.
Use allow-listed commands. Do not expose a general database, shell, or HTTP tool when the workflow needs one business operation. Redact secrets and sensitive fields before they reach the model. Keep system credentials in the application runtime.
05
Use controlled business commands
A business command represents one approved operation. Examples include get order status, prepare a cancellation request, create a review task, or export approved records. Each command has a typed input, permission rule, validation rule, and defined result.
The model can suggest a command and prepare its input. Application code checks the input against current business state. It can reject an invalid order status, a missing reason, an amount outside policy, or a request from the wrong user. The command layer also limits which fields can change.
This design is safer than a general tool because the application keeps the policy near the operation. It is also easier to test. The team can test allowed, denied, duplicate, stale, and failed requests without depending on the wording of a conversation.
06
Record enough detail to investigate an action
For each material action, record the authenticated user, tenant, request, selected command, validated input, policy result, approval, execution result, and operation identifier. Also record the model and prompt versions when they influenced the proposal. Do not put secrets or unnecessary personal data in the log.
An operator needs to answer simple questions. Who requested the action? Which evidence was available? Which rule allowed it? Did a person approve it? Did the backend accept it? Was the request retried? The record must connect these events without relying on a model summary.
Set retention and access rules for the record. A useful audit trail is still sensitive data. Only authorised roles should view or export it.
07
Test denial and recovery paths
A normal demonstration often shows a successful request. Production tests must also cover denial and recovery. Test an unauthorised user, wrong tenant, stale order state, malformed input, changed policy, expired approval, provider timeout, duplicate request, and partial backend failure.
The application must fail in a known state. It should not repeat a write because a model or user asked again. It should show when a person must intervene. It should keep the evidence needed for support and reconciliation.
These tests do not prove that the architecture has been adopted in production. They define the acceptance work needed before a team can trust an AI-assisted action path.
08
Place approval at the point of consequence
Low-risk read actions can return after policy and evidence checks. A material write can require a person to review the proposed command and its evidence. The application binds approval to the exact input and command. A change requires a new approval.
After execution, monitor failures, denials, retries, cost, latency, and reviewer overrides. These records support incident review and future evaluation.
The diagram defines a control pattern. It does not establish production adoption, business value, certification, or independent security assurance.