Read Access and Action Authority Belong to Different Contracts

An employee may need to understand a procedure without having authority to change the records governed by it. An AI assistant inherits the same distinction when it retrieves knowledge and prepares a tool request.

My public operating-layer case separates a knowledge plane from an action plane. Document groups and approved sources control retrieval. Roles, policy and approval rules control operational changes. This note examines the contract between those planes rather than claiming a new security certification or a completed authorization rollout.

A document can describe an action without granting it

An approved procedure can explain how a financial exception is handled. That makes the procedure useful to someone who needs to recognize and route an exception. It does not necessarily authorize that reader to execute the financial change.

The same issue arises when retrieved text reaches a model. The model can explain the procedure, summarize required evidence or identify the relevant authority. A generated request to perform the operation is still a request.

Treating access to instructions as access to execution would let knowledge retrieval silently expand operational privileges. The output would look informed while the action boundary had disappeared.

The two contracts therefore need different questions. Retrieval asks whether this identity may consult this approved source. Execution asks whether this identity may perform this operation on this object under the present conditions.

An invented exception request

Imagine a fictional production operator who can read a procedure for dealing with an incorrect personalization. The operator asks the assistant what should happen next.

The assistant retrieves the relevant procedure and prepares a proposed customer-remedy request. That can help explain the next step. It does not establish that the operator may authorize a financial adjustment.

The action path would need to evaluate the requested operation, the affected object and the applicable approval rule. If additional authority is required, the request should remain a proposal with its evidence rather than being described as an executed remedy.

This is an invented example. It does not disclose an actual customer case or assert that a particular remedy tool is connected in the public implementation.

Preserve the boundary after generation

Putting role instructions into a prompt can help the assistant explain its scope. I would still require the action interface to enforce the actual authorization contract when a request arrives.

That interface needs to distinguish the assistant's service identity from the human role represented in the request. The exact implementation depends on the system, but the review question is stable: whose authority is being evaluated, and what evidence binds it to this operation?

Current state also matters. A source retrieved earlier can remain readable while the target object changes or the approval becomes invalid. An execution decision should therefore use the applicable current authorization state, not merely reuse the model's earlier narrative.

The public case includes deterministic authorization and audit boundaries at the system-pattern level. It does not publish its production policy definitions. The details here are questions to apply during design and testing.

Test the contracts separately

• Can an authorized reader retrieve the right approved procedure?
• Is an unrelated or restricted source excluded from that retrieval?
• Can the same reader be denied an operation outside their authority?
• Does a proposed tool request remain distinguishable from a completed action?
• Are object state and required approvals checked at execution time?
• Does the audit record identify the operation, authority decision and outcome without copying unnecessary private content?
• Can a reviewer explain a denial without treating it as a retrieval failure?

Those checks examine different responsibilities. Passing the knowledge checks does not certify action safety, and passing a tool authorization test does not establish retrieval quality.

The public operating-layer case describes the two planes and their intended relationship.

Where in your system is an informed suggestion converted into an authorized operation, and can you inspect that boundary independently of the prompt?