{"slug": "read-access-and-action-authority-belong-to-different-contracts", "title": "Read Access and Action Authority Belong to Different Contracts", "summary": "A developer published an operating-layer case study separating an AI assistant's knowledge plane from its action plane, arguing that retrieval access and execution authority are governed by different contracts. The case, shared on GitHub, holds that a model retrieving an approved procedure can explain or propose an action but must not be treated as authorized to execute it, with authorization enforced at the action interface using current state rather than the model's earlier narrative. The writeup offers design and testing questions rather than a completed authorization rollout or security certification.", "body_md": "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.\n\nMy 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.\n\nAn 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.\n\nThe 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.\n\nTreating 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.\n\nThe 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.\n\nImagine a fictional production operator who can read a procedure for dealing with an incorrect personalization. The operator asks the assistant what should happen next.\n\nThe 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.\n\nThe 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.\n\nThis 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.\n\nPutting 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.\n\nThat 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?\n\nCurrent 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.\n\nThe 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.\n\nThose checks examine different responsibilities. Passing the knowledge checks does not certify action safety, and passing a tool authorization test does not establish retrieval quality.\n\nThe [public operating-layer case](https://github.com/rkrisa/portfolio-ai-ops/tree/main/cases/ai-assisted-operating-system-personalized-ecommerce) describes the two planes and their intended relationship.\n\nWhere in your system is an informed suggestion converted into an authorized operation, and can you inspect that boundary independently of the prompt?", "url": "https://wpnews.pro/news/read-access-and-action-authority-belong-to-different-contracts", "canonical_source": "https://dev.to/rkrisa/read-access-and-action-authority-belong-to-different-contracts-5d65", "published_at": "2026-10-22 21:00:00+00:00", "updated_at": "2026-10-22 21:10:42.830474+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "artificial-intelligence"], "entities": ["GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/read-access-and-action-authority-belong-to-different-contracts", "markdown": "https://wpnews.pro/news/read-access-and-action-authority-belong-to-different-contracts.md", "text": "https://wpnews.pro/news/read-access-and-action-authority-belong-to-different-contracts.txt", "jsonld": "https://wpnews.pro/news/read-access-and-action-authority-belong-to-different-contracts.jsonld"}}