Mina asks a fictional assistant to summarize draft H-7 in her Harbor workspace. The assistant proposes reading that draft. Before any content is returned, the document service needs to answer a separate question: may this caller perform this action on this particular document? The fact that the assistant selected a plausible tool does not settle that question.

For our example, the trusted service records give Mina one active grant: read H-7. Draft H-8 also belongs to Harbor, while draft R-7 belongs to another workspace, Ridge. Mina has no grant to either of those drafts and no grant to rename H-7. We will evaluate requests against these invented records. No real document, user account, credential, model or external service is involved.

OWASP distinguishes authentication, which establishes identity, from authorization, which checks permitted actions. [1] Its 2025 Excessive Agency guidance also places authorization in the systems executing tool actions rather than leaving that decision to the language model. [5] This gives us a concrete way to read an agent's capabilities: separate what it can propose, what the interface can represent and what the receiving service actually permits for the current request.

Treat a model-produced tool call as a proposed operation over parameters, not as an authorization assertion. In our fictional document service, the trusted principal is mina, the trusted workspace is Harbor and the active grant relation contains exactly (mina, read, H-7). The resource registry places H-7 and H-8 in Harbor and R-7 in Ridge. No rename grant exists.

The construction evaluates a finite set of requests against those declared records. It does not perform authentication, parse a token, contact an API or read document content. Credential validity and intended-audience checks will be stipulated results from separate controls. This boundary matters: a short logical illustration can expose a missing distinction without implementing the machinery needed to establish trustworthy identities and attributes in production.

OWASP's authorization guidance separates identity verification from permission evaluation [1]. Its LLM06:2025 guidance calls for downstream mediation rather than a model deciding whether its own action is authorized [5]. The proposed tool name, argument structure, validated identity and active resource grant therefore occupy different roles. A persuasive explanation generated by an assistant cannot replace the receiving system's decision about the exact subject, operation and object.

Our toy request has exactly three fields: action, objectId and workspace. Each must contain text. The recognized actions are read and rename; the workspace labels are Harbor and Ridge. An object identifier must use the declared H- or R- prefix followed by digits, with a maximum length of twenty characters. These are our example's input rules, not a recommended universal identifier format.

A request to read H-8 in Harbor satisfies those rules. The identifier has the expected shape and names an existing document. Yet Mina has no grant to read it. The input check answers whether the request can be interpreted under the declared format. The permission check answers whether Mina may carry out that interpreted operation. OWASP's input-validation guidance explicitly keeps authorization separate from a valid identifier. [2]

The same distinction applies when an interface asks a model for structured arguments. A successful schema check can prevent malformed or unexpected fields without proving ownership or permission. In this example, adding an extra role field is itself invalid because the allowed field set is exact. Removing that field would make the remaining shape acceptable only if the other rules pass; it would still not create a missing document grant.

Define the illustrative request shape with required string fields action, objectId and workspace, no additional fields, action in {read,rename}, workspace in {Harbor,Ridge}, and an H-/R- identifier followed by ASCII digits with total length at most twenty. The service recognizes both operations at this parsing layer. Recognition is deliberately distinct from the caller's authorization to use either operation.

The request (read,H-8,Harbor) passes that shape check, but the exact grant tuple (mina,read,H-8) is absent. Object existence and identifier validity therefore do not imply permission. This follows the separation in OWASP's validation guidance between input requirements and authorization [2]. A schema can constrain representation while leaving the subject-object relationship entirely unresolved.

Likewise, an additional role field causes the toy shape check to fail; it is not bound into the trusted principal. Rejecting that request is different from discovering an administrator grant. The construction uses already parsed, small in-memory records. It does not model parser limits, normalization, injection defenses or a complete validation library. Those concerns remain necessary in a real implementation, but adding them would still not make syntactic validity equivalent to access rights.

The assistant's request can say which document it wants. It cannot establish who Mina is by putting a name into the request body. In our construction, the trusted caller and workspace arrive through a separate service context. That context is an assumption of the example, not a Boolean value that a real client is allowed to declare for itself.

Imagine that the request includes the extra text role: admin. Our input rules reject the unexpected field. More fundamentally, the text does not alter Mina's grants. The same is true if an assistant confidently explains that it has administrator access. Authorization depends on the records and controls the service trusts, rather than on how convincing a request or explanation sounds.

OWASP's guidance places access checks on the server or another enforcing service boundary and discusses deriving context from securely established identity and attributes. [1] In a real application, that includes correctly validating whichever session or credential mechanism it uses. Our example assumes those controls provide a valid caller, then keeps that identity separate from model-generated arguments. It cannot prove that a real login flow or token verifier has been implemented correctly.

Separate untrusted operation parameters from trusted authentication context. The fictional evaluator receives principal mina and workspace Harbor through a distinct context object whose validity is assumed to have been established elsewhere. The model's request cannot overwrite that principal, manufacture a role or set the result of credential validation.

The extra-role-field case makes the boundary concrete. The exact-field schema fails, while the stored grant set remains unchanged. Even if a different interface permitted an informational role label, that label would need its own trustworthy provenance before it could influence authorization. A model's assertion of authority is data from the requesting side, not independent evidence that the authority exists.

OWASP recommends enforcing checks outside client-controlled logic and using established identity and attributes for resource access [1]. In production, issuer, session, token and application-specific validation require their appropriate mechanisms; our Boolean credential input does not implement them. The finite example begins after those controls are assumed to have produced a trusted result. Its claim is narrower: keep the resulting security context separate from fields that the agent is free to generate or modify.

There are two different reasons to refuse the neighboring documents in our example. Reading H-8 remains inside Harbor, but Mina lacks the exact document grant. Reading R-7 also crosses into Ridge, which does not match the trusted Harbor context. The service resolves each document's workspace from its own resource record; it does not accept the request's workspace label as proof of ownership.

Suppose a request names R-7 while still saying workspace: Harbor. The strings are well formed, but the server's R-7 record says Ridge. That disagreement prevents the request from passing our workspace condition. Conversely, a request for H-7 that wrongly names Ridge also fails that condition even though Mina's read grant for H-7 exists. All the required relationships must agree.

OWASP calls for checks on the specific object and operation rather than assuming access to every object of a type. [1] Our explicit three-document registry makes that principle visible. Changing an identifier does not change who owns the resource, and membership in a workspace does not automatically create every possible document permission. Real applications may have sharing or cross-workspace policies, but those would need declared rules beyond this deliberately narrow example.

The toy workspace predicate requires request.workspace, trustedContext.workspace and the server-resolved object's workspace to be equal. For H-8, all three are Harbor, so the workspace predicate passes while the exact-grant predicate fails. For R-7 requested as Harbor, the resource record resolves to Ridge, causing a workspace mismatch as well as an absent grant.

The reverse mismatch is also useful: requesting H-7 with workspace Ridge leaves the exact read grant present but fails the workspace predicate. Neither predicate subsumes the other in this policy. Resource ownership comes from the declared registry, and the requested workspace is a value to verify rather than a trusted replacement for that metadata.

OWASP's object-level guidance supports evaluating the specific resource and operation on each request [1]. Our construction uses one explicit workspace boundary and no cross-workspace sharing. That is a chosen policy, not a universal rule that shared resources are impossible. A real sharing model would need its own authenticated relationships, tenant semantics and enforcement. The lesson is to resolve and compare those relationships rather than infer authorization from a valid identifier or a broad role name.

We can now describe the small policy using five yes-or-no questions. V asks whether the request shape is valid. C asks whether the separately checked caller credential is valid. A asks whether the credential is intended for this service. T asks whether the requested, trusted and resource workspaces agree. G asks whether the current exact caller-action-document grant exists.

In this teaching model, the request passes only when all five answers are yes. Read H-7 with the stated valid context passes. Read H-8 fails G. A credential intended for a different service fails A, even if the document and grant otherwise match. An unexpected role field fails V. The checks identify different missing conditions rather than treating every refusal as malformed text.

Five Boolean conditions have 32 possible combinations, and just one has all five true. That count is a property of the chosen logical expression. It is not a measured attack-blocking rate, and it does not mean a real system is secure in 31 out of 32 situations. Some abstract combinations may not occur in a real authentication flow. Passing our small policy also leaves many implementation questions outside the example, including whether trusted inputs were established correctly.

Let V denote shape validity, C a stipulated valid authenticated context, A a stipulated intended-audience match, T the three-way workspace match and G membership of the current exact grant relation. The simplified predicate is P=V∧C∧A∧T∧G. We enumerate its 2^5=32 Boolean assignments; only (true,true,true,true,true) makes P true.

The concrete cases exercise different failures. The H-8 read has V,C,A,T true and G false. A wrong-audience H-7 request has V,C,T,G true and A false. The extra-role-field request has C,A,T,G true but V false. A request for H-7 naming Ridge has V,C,A,G true but T false. These examples show why one successful check cannot be substituted for the complete conjunction.

The enumeration is a truth-table calculation, not an authentication implementation or empirical security test. Boolean inputs are not a probability distribution, and all combinations need not be reachable through a real verifier. The predicate is sufficient only for the stipulated toy decision. Production authorization must establish trustworthy inputs, cover every access path and satisfy the application's full policy. OWASP separately emphasizes checking actual configuration and testing enforcement [1]; a logical table does not perform those tasks.

Suppose a credential carries permission described as read, but it was issued for a calendar service. The document service cannot infer that the same word also grants access to H-7. The intended recipient and the permitted kind of access are different parts of the decision. In our fictional cases, changing only the intended-service result from yes to no makes A fail.

RFC 8707 explains this distinction through resource indicators and OAuth scopes. A resource indicator identifies where the requested token will be used; a scope typically describes what access is requested. The authorization server applies policy when deciding what to issue. [3] Merely requesting a resource or scope does not establish that the request was granted, and a broad reading scope still needs the application's object-access rules.

The inspected MCP authorization specification, dated 2025-11-25, provides a concrete HTTP-based example: the receiving server checks that a token was intended for it, and a server calling an upstream API uses a separate token for that API rather than passing the incoming token through. [4] We are explaining those boundaries, not issuing tokens or supplying a complete OAuth setup. The flow is not presented as a rule for every MCP transport.

Keep credential audience, OAuth scope and application object authorization distinct. A token can describe reading access for one recipient without authorizing use at a different recipient. RFC 8707 distinguishes the target resource from the requested scope and permits the authorization server to apply its own policy when issuing the token [3]. The request parameters express requested access, not an automatically accepted grant.

Our A predicate is only a stipulated outcome of intended-recipient validation. No token bytes, signature, issuer, expiry, introspection response or OAuth exchange are modeled. Object-level G remains separate: even a correctly targeted document-service token with suitable coarse scope need not authorize every document. The service must apply its actual resource policy rather than interpret a familiar scope word as universal access.

The retained MCP 2025-11-25 authorization document scopes its flow to HTTP-based transports and requires intended-audience validation when that authorization mechanism is used [4]. It also separates an upstream API token from the incoming MCP token. Its OAuth 2.1 reference is explicitly a draft; we do not turn the example into a current, exhaustive deployment recipe. The relevant architectural point is that each protected service needs credentials and authorization appropriate to its own boundary.

An assistant built only to summarize documents can be given a reading tool without a rename or delete tool. That keeps unnecessary operations out of its normal choices. OWASP's Excessive Agency guidance distinguishes limiting available functions from limiting the permissions used by those functions. [5] Both matter because a narrow-looking menu and a powerful underlying connection are different things.

Our teaching service recognizes read and rename so that the difference is easy to inspect. Mina's stored permission allows only reading H-7. A rename request is therefore understandable but unauthorized. Hiding rename from the assistant's menu would reduce the actions it is invited to propose; the same request must still be refused if it reaches the enforcing service through another path.

The opposite mismatch is also possible in a design: a tool named read_document might run through an account with far broader access than the task needs. A friendly name does not narrow that account's rights. Keep the tool's implemented operation, the caller's resource scope and the downstream connection's permissions aligned. Our example illustrates why those layers need to agree; it does not inspect any real plugin's implementation or claim that its name proves its behavior.

Distinguish tool exposure, implemented functionality and downstream authority. Removing unnecessary operations from a model's tool set constrains its normal action space, while a least-privilege service identity constrains what execution can accomplish. OWASP LLM06:2025 treats excessive functionality and excessive permissions as separate causes [5]; reducing one does not establish that the other has been addressed.

The toy dispatcher recognizes read and rename at the structural layer, but the active relation contains only (mina,read,H-7). Thus rename is valid as an operation name and still fails G. A production summarizer could expose only the narrower read operation, yet the protected resource must retain its authorization decision if another client, route or internal component requests a mutation.

A tool label is not an enforceable capability boundary by itself. The actual handler, parameters, service identity and downstream policy determine what happens. OWASP also places mediation in the executing systems and recommends acting within the user's scope [5]. The proposal here is to align those controls, not to claim that a specific framework automatically does so. No external plugin, service account or backend permission was inspected or changed by this article's finite example.

After an authorized read, an assistant may encounter a draft containing a label such as “administrator approved”. That phrase is part of the document's content. It does not add a rename grant to Mina's service record. A document may discuss permissions, describe a workflow or contain mistaken instructions; the receiving service still evaluates the next requested action using its trusted context and policy.

In our construction, reading H-7 does not expand the set containing Mina's one grant. If the assistant subsequently proposes renaming H-7, G remains false. The model can change its proposed operation after reading text, but the text cannot change the server's stored permission relation merely by being included in the model's context.

OWASP's 2025 guidance discusses unexpected or manipulated model outputs and calls for downstream authorization. [5] That separation helps contain an out-of-scope proposal, but it is not a claim that all content-related risks disappear. Authorized reading can still expose information to the system that receives the result. A real application's data-handling design therefore matters alongside its action checks. Our example proves only that document wording is not an input that updates its declared grant set.

Treat retrieved content as data with its own provenance, not as an authorization-policy update. The fictional grant relation changes only through a separate trusted policy event. A statement inside H-7, including one claiming administrator approval, does not insert (mina,rename,H-7) into that relation. A later rename proposal consequently continues to fail G.

This separates influence over planning from authority over execution. Model context may affect which operation is proposed, but the enforcing service must evaluate the resulting request independently. The OWASP excessive-agency discussion identifies manipulated or unexpected model outputs as possible triggers and recommends complete mediation outside the model's own permission judgment [5]. Our example applies that distinction without executing a prompt-injection attempt or measuring a model's resistance.

The boundary does not establish comprehensive confidentiality. Data legitimately returned to an authorized read is now available to the receiving application under its own handling rules. Preventing an unauthorized mutation does not prove that every later processing or disclosure path is appropriate. The constructed policy evaluates requested document operations; it does not model a full information-flow system. That limitation is why a successful permission check and an acceptable use of returned data remain separate questions.

At policy state v7, Mina's read grant for H-7 exists, so the original request passes all five conditions. Now suppose the trusted policy removes that grant and state v8 has taken effect before the next request is checked. The caller, document, request shape and intended service remain the same. G changes to no, and the repeated request fails.

This is an original state-change example, not a measurement of how quickly a real service revokes access. A distributed application may have caches, delayed updates or work already in progress. Those details determine when a policy change takes effect and need their own design. Our example assumes the new state is already available at the second decision; it does not solve that timing problem.

OWASP recommends checking permissions on every request. [1] That means the first successful call is evidence of an earlier decision, not a permanent substitute for later decisions. It also does not erase content that was legitimately returned before the change. A cached document response and a current permission decision serve different purposes. Reusing the former must not silently bypass the latter under a policy that requires current authorization.

Let G_v7 contain (mina,read,H-7) and G_v8 be empty. With V,C,A,T unchanged and true, the initial request passes under v7 and fails under v8. The identical request parameters therefore do not determine an invariant authorization result; the relevant policy state is also an input.

We stipulate that v8 is effective before the second decision. The construction does not implement distributed revocation, cache invalidation, transactional enforcement or cancellation of an operation already in flight. In a real service, the relationship between the authorization check and the protected action requires explicit handling. A Boolean demonstration cannot establish those timing and consistency properties.

OWASP's per-request guidance supports reevaluating the applicable permission rather than treating an earlier permit as an indefinite capability [1]. A response cache must be considered within the same enforcement boundary if serving cached content is itself protected access. Separately, refusing a future read does not retroactively remove an earlier authorized copy from model context or other storage. Our v7/v8 example concerns the new access decision, not remote deletion of previously disclosed information.

Some applications require a person to confirm selected actions before they happen. OWASP's 2025 guidance describes that control for high-impact operations. [5] Confirmation can help establish that an intended action matches the person's choice, but it is different from checking whether the service permits that caller to perform the action at all.

In our stored-grant example, Mina has permission to read H-7 and has asked for its summary. That authorized reading does not need an extra confirmation invented by this example. A separate rename request still lacks the required grant. If a workflow records confirmation for an operation, the confirmation needs a clear target and proposed change; an approval associated with one draft or change should not silently be transferred to another.

A real application may have an authorized process that updates permissions after user consent. If so, that policy change must actually occur through the intended control; it is not implied by arbitrary text in a tool response. Keep the service grant, the user's task scope and any operation-specific confirmation distinct. Our example demonstrates that distinction without implementing a consent system or prescribing the same approval experience for every application.

Distinguish service authorization from operation-specific intent confirmation. OWASP LLM06:2025 discusses human approval for high-impact actions [5]. Such a check can be an additional predicate for a designated operation, but it does not replace validated identity, resource binding or the service's grant relation.

The main example contains an already authorized read task, so no additional confirmation predicate is introduced for that read. A rename remains outside G. In a separately designed confirmation workflow, the recorded approval should refer to the actual target and proposed parameters; changing those parameters changes what the record describes. This is a reasoned design implication, not a claim that our five-condition model implements confirmation binding or replay prevention.

Consent can also participate in a legitimate authorization flow that issues or updates grants. That is a separate trusted transition with its own validation, not a role claim copied from model output. The article's narrow policy assumes no such transition except the explicitly described revocation. Keeping these layers distinct permits useful authorized work to proceed while preserving the meaning of a confirmation where the application genuinely requires one.

A useful review record can explain why read H-8 failed even though its format was valid. For our example, it would identify the request, trusted caller, requested operation, resolved resource, policy state and the failed grant condition. That is more informative than a generic note that the agent made a mistake. It separates an input problem from an access problem.

Keep detailed records available only to the people or systems allowed to inspect them. An error shown to a client need not reveal the contents or existence of an inaccessible document. OWASP warns against exposing sensitive debug information and against logging too much data; its input-validation guidance specifically discourages copying secrets or entire rejected request bodies into logs. [1][2] Credentials and full document text are not needed to explain our fictional policy decisions.

The review should also preserve the limits of its evidence. We have checked ten constructed requests and all 32 assignments of a simplified five-condition expression. We have not audited a deployed agent, authenticated a real user or tested every route in an application. The useful result is a sharper question to ask of a tool integration: where is the exact action-resource permission enforced, using whose trusted identity and which current policy?

A decision record should distinguish request representation, trusted security context, resolved resource metadata, policy state and outcome. In the toy H-8 case, V,C,A,T pass while G fails. Preserving those meanings makes the result inspectable without misclassifying it as a parser failure or assuming that an authenticated caller must receive the resource.

The detail belongs behind an appropriate access boundary. OWASP advises safe failure handling and deliberate limits on logged information [1]; its validation guidance excludes secrets and full rejected bodies from routine failure logging [2]. A record can retain an operation identifier, relevant policy version and bounded decision metadata without copying access tokens or complete document content. Client-facing errors should follow the application's disclosure policy rather than expose internal reasoning indiscriminately.

Our evidence consists of ten explicitly constructed cases, a 32-row Boolean enumeration, primary-source interpretation and independent review of those claims. It is not a production security assessment, OAuth implementation or guarantee of agent behavior. The conjunction demonstrates why one passing check does not grant an operation. A real integration must establish the trusted inputs and enforce the intended policy on every protected path; that is the concrete boundary to inspect when evaluating what an agent can actually do.