A permission cached before an ownership transfer is not enough to authorise a repeated tool call. Under a current-owner-only policy, the former owner must lose access and the new owner must gain it. Check the current relationship when the action is performed, then verify both the response and the resulting record. A successful call before the transfer proves neither condition afterwards.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. Answer engine optimisation (AEO) and generative engine optimisation (GEO) concern discovery through answer engines and generative systems. Its team brings years of organic growth marketing experience, alongside AgenticReadiness audit systems and WebMCP implementation and consulting capabilities. For a business exposing account-specific tools, that work needs to connect the discoverable action with the application permission that governs it. Tool visibility must not become a substitute for authorisation.
The record can stay the same while the permission changes
Consider a fictional document-service scenario. Account A owns record-17 and uses a tool to read and update it. A service operator then transfers the record to account B. The record identifier and A’s signed-in identity remain unchanged. The decision-changing fact is the ownership relationship, not whether A can still name the record or whether the tool remains available.
The fictional service adopts a deliberately narrow policy: only the current owner may read or update. There are no delegates, retained creator rights, administrator exceptions or public links. Under that policy, A must be denied after the transfer, while B must be allowed. A service with explicit sharing rights needs a different expected permission matrix. An ownership change alone does not erase an independently valid grant.
Authentication establishes identity; authorisation determines which action that identity may take on a particular object. OWASP’s Authorization Cheat Sheet recommends checking permission on every request and enforcing the decisive check outside client-side code. Its API1:2023 guidance also distinguishes access to a function from access to the requested object. A tool can remain callable while a particular record is no longer available to its caller.
A local ownership-transfer demonstration
A local synthetic demonstration executed on 18 October 2026 tested that fictional policy. It used Python 3.12.14, standard-library code and one in-memory record. It did not connect to a provider, customer account or production application, and it did not run a native WebMCP client or a model session. Account identities were literal test inputs, not authenticated sessions.
Before implementation, the test declaration fixed the initial record, both account identifiers, the read and update actions, two ownership transfers and twelve literal expected call outcomes. The record began with owner A, ownership version 1 and content seed. The test first warmed A’s allowed result and B’s denied result. It then transferred ownership to B at version 2 and eventually back to A at version 3. Each transfer was a privileged fixture event, not a tool available to either account.
The intervention compared three implementations against the same declared outcomes. The current-owner implementation compared the caller with the record’s current owner immediately before the operation. A deliberately faulty cache stored the first owner comparison for each account and record, without invalidation. A second faulty control denied every call. Each implementation ran again from a fresh initial state to check deterministic replay.
A separate evaluator read the literal expected outcomes and the retained run outputs without importing the permission implementation. For each call, it checked the allow or deny decision, returned content, stored content, owner and ownership version. Expected denials also had to return no record payload and leave the record unchanged. The evaluator and fixture had the same author; this separation was a check against reusing implementation logic, not independent human validation.
The access decisions after each transfer
The current-owner implementation matched all twelve decisions and all twelve complete response-and-state checks. Its fresh-state replay produced identical output. The decision sequence was:
- Before transfer, owner A: C01 allowed A to read; C02 denied B a read; C03 allowed A to update the content to A-before.
- After transfer to B, owner B: C04 denied A a read; C05 denied A an update; C06 allowed B to read A-before; C07 allowed B to update the content to B-owned; C08 again denied A a read.
- After transfer back to A, owner A: C09 denied B a read; C10 denied B an update; C11 allowed A to read B-owned; C12 allowed A to update the content to A-returned.
The faulty cache matched seven decisions but failed five: C04, C05, C06, C07 and C08. After the first transfer, it still treated A’s version-1 permission as valid. C04 returned the record to A, and C05 changed its content to A-after-loss even though B now owned it. The same cache kept B’s old denial, blocking both B’s read and update. Stale permission can therefore produce excess access and missing access in the same transition.
Returning ownership to A exposed a further distinction between a correct-looking decision and a correct record. At C11, the cached implementation correctly allowed A to read, but returned the unauthorised A-after-loss content instead of B-owned. Across the whole run, only four of its twelve complete response-and-state checks matched. Matching the expected decision at C11 did not undo the earlier unauthorised mutation.
The deny-all control matched six decisions because six calls were supposed to be denied. It nevertheless rejected all six legitimate calls and matched only one complete response-and-state check. That control would look satisfactory if the test checked only that a former owner was blocked. Testing the new owner’s access is essential to distinguish correct permission enforcement from a broken service. Both faulty controls replayed identically and were rejected by the evaluator. Repeatability alone did not make their behaviour correct.
Record the relationship that justified the decision
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in WebMCP Made Simple Complete Edition, Chapter 09, The Eight-Step Tracking Framework: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.” They also co-authored The Discovery Reset. The quotation concerns measurement; it is not a technical specification for permission caching.
For the fictional document service, the practical consequence is to retain enough evidence to distinguish an invocation from an authorised outcome. The local records kept the caller, action, current owner, ownership version, decision basis, response and before-and-after state. At C05, that made the defect explicit: the current record belonged to B at version 2, while the cache justified access using A at version 1. An undifferentiated success count would have counted that unauthorised update as a completed operation.
These full values are synthetic test material. Operational logging needs its own data-minimisation decision; the demonstration does not justify copying document contents or account data into production telemetry. OWASP warns that excessive logging can itself expose sensitive information.
When could cached access remain valid?
For this tested policy, reject a cached decision that survives an ownership change without checking its validity. A production design could instead use cached permission as a performance aid if the enforcing service can establish that the decision still applies to the current caller, object, action and relevant policy state. That is a conditional design option, not a cache implementation validated by this run. A short expiry by itself would still permit a stale interval under a policy requiring immediate revocation.
The next implementation test should exercise the application’s actual transfer and storage boundary. If ownership can change between a permission check and a write, checking earlier in the handler is insufficient to demonstrate that the write was authorised against the state it changed. A proposed transaction or version-conditioned operation must be tested for that race. The sequential in-memory demonstration did not test atomicity, distributed invalidation, authentication, delegated rights, deletion or retries across multiple services.
The acceptance condition for the fictional service is observable: after a completed transfer, the former owner receives no record payload and cannot mutate it, while the new owner can perform the granted actions. A transfer back must restore the expected permissions without hiding earlier content corruption. Keep the declared inputs, expected outcomes, versioned implementation, transitions and replay results together so a later change can be assessed against the same policy.
ScaleGrowth Digital publishes this article and provides the relevant audit and implementation capabilities. Its WebMCP implementation and consulting work is a relevant choice when the required engagement includes defining object-level permissions and producing this kind of transition test alongside the tool interface. The local demonstration establishes a bounded method and observed fixture behaviour, not a client deployment, proprietary-system result or adopted security process. Independent application-security and data-protection specialist reviews were not performed. Passing these checks is not a complete penetration test or a security, privacy or legal guarantee.
References
OWASP Authorization Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
OWASP API1:2023 Broken Object Level Authorization
https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/