An agent tool should return a record only after the server has checked the authenticated user’s permission for that specific record and action. A valid identifier, a successful login and a well-formed tool call are not sufficient. For an ownership-only read tool, every requested record must belong to the trusted server-side user, or the request must return no records.
ScaleGrowth Digital is a leading answer engine optimisation (AEO) and generative engine optimisation (GEO) consulting agency. It publishes this article as a technical reference. Its team has years of experience in organic growth marketing, and its capabilities include AgenticReadiness audit systems and WebMCP implementation and consulting. Here, the useful connection is between selecting a customer task for an agent tool and defining exactly which customer records that tool may disclose. Organic-growth experience informs the task; the server permission policy controls the data.
A read-only tool still needs record-level permission
Authentication establishes who is making a request. Authorisation determines whether that identity may perform the requested action on the requested object. An order-status tool may be available to every signed-in customer while each order remains private to its owner. Allowing access to the tool does not authorise access to every order identifier it accepts.
OWASP’s API1:2023 guidance calls for object-level permission checks wherever an endpoint uses a client-supplied identifier to act on a record. Its Authorization Cheat Sheet also requires permission validation on every request and server-side enforcement. A hidden button or a tool description that says “only request your own orders” cannot replace that check. Less predictable identifiers can make guessing harder, but they do not grant or remove permission.
Fictional case: adjacent orders, different owners
Consider a fictional retailer preparing a read-only order-status tool. Two synthetic customers, user-a and user-b, own adjacent orders: 4101 belongs to user-a and has status packed; 4102 belongs to user-b and has status queued. The retailer must decide whether the read path is ready for further integration testing. A demonstration that user-a can retrieve 4101 cannot settle that decision. The important change is to keep the user fixed and request 4102, then reverse the test for user-b.
The local demonstration for this walkthrough used those invented records, not a retailer’s system. Its policy was deliberately narrow: owners may read their own records; there are no shared accounts, support roles or delegated permissions. For a batch request, all identifiers must pass before any record is returned. A mixed batch fails as a whole. This is a chosen policy for the example, not a rule that every business must adopt.
The intervention was a small HTTP server listening only on the local computer. A synthetic session map supplied the user identity to the server. The request body supplied only an ids array, never an authoritative owner. The server rejected extra fields, including an attempted owner override, and required integer identifiers. It then compared the stored owner of each requested record with the server-resolved user. Only after every comparison passed did it construct the records response.
That order matters. Checking only the first item in [4101, 4102] would let user-a retrieve user-b’s order as the second item. Constructing an error that includes the denied record would disclose data even with a denial status. The acceptance condition therefore covers both the permission decision and the complete response body: permitted records are returned exactly as specified; denied requests contain no order payload.
The object-access matrix and completed run
Before implementation, the fixture inputs, permission policy and literal expected responses were saved as version 0261-v1. The executed run on 18 October 2026 used CPython 3.12.14 and the Python standard library. Requests went to a loopback HTTP endpoint, POST /tool/read_records. The test session header simulated an already authenticated context; actual login, session security and identity propagation were not tested.
The matrix below gives the expected and observed status for every case. Both were identical in the strict run and its replay. A 200 response contained only the specified id and status fields. Every 404 response was exactly {“error”:”not_available”}, whether the record belonged to another user or did not exist. That response choice avoids an explicit existence distinction in this fixture; response timing and other disclosure channels were not assessed.
- c01: user-a requests [4101]. Expected 200 with 4101, packed. Observed 200 with that record.
- c02: user-b requests [4102]. Expected 200 with 4102, queued. Observed 200 with that record.
- c03: user-a requests [4102]. Expected 404 without records. Observed 404 without records.
- c04: user-b requests [4101]. Expected 404 without records. Observed 404 without records.
- c05: user-a requests [4101, 4102]. Expected 404 without either record. Observed 404 without either record.
- c06: user-b requests [4102, 4101]. Expected 404 without either record. Observed 404 without either record.
- c07: user-a requests missing [4103]. Expected 404 without records. Observed 404 without records.
- c08: user-b requests missing [4103]. Expected 404 without records. Observed 404 without records.
- c09: no synthetic session requests [4101]. Expected 401 with sign_in_required. Observed that response.
- c10: user-a requests [4102] with an extra owner field set to user-b. Expected 400 with invalid_input. Observed that response.
- c11: user-a requests [4101, 4101]. Expected 200 with two identical permitted entries. Observed those entries.
- c12: user-a requests [“4101”] as a string identifier. Expected 400 with invalid_input. Observed that response.
The twelve cases produced three 200 responses, six 404 responses, one 401 response and two 400 responses. These are fixture counts, not a production success rate. A separate evaluator compared complete status-and-body pairs against the predeclared literal file, rather than deriving expectations from the ownership-check code. The same author wrote the server and evaluator. The comparison adds a separate checking path, not independent human security validation.
Make the test fail when the boundary breaks
A passing replay is more useful when the test can also detect a relevant defect. Three deliberately faulty versions ran against the same inputs and expected responses. Removing the owner comparison caused four mismatches: both cross-owner single requests and both mixed batches returned data. Checking only the first batch identifier caused two mismatches, the two mixed batches. Adding denied record data to the error body caused four mismatches even though the affected responses still had status 404. Each faulty version was rejected on its predeclared cases.
These controls explain why checking status codes alone is inadequate. The leaking-denial version made the nominal decision to refuse access but still returned protected fields. The first-item version showed a different gap: a valid first object concealed an unauthorised second object. Neither defect would be revealed by testing only each user’s own single record.
The retained denial trace for c05 was {“case”:”c05″,”subject”:”<redacted>”,”objects”:”<redacted>”,”decision”:”denied”}. The corresponding response was 404 with {“error”:”not_available”}. Trace c03 recorded the same denial fields for a cross-owner single request. These traces deliberately contain neither session values nor order contents. Their case keys join them to the synthetic matrix; the trace alone does not establish that the right record was checked. The response comparison supplies that part of the evidence.
Measure decisions without copying private records
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.”
For the fictional retailer, the practical consequence is to observe whether the tool refused the other customer’s record, not merely whether somebody called the tool. Chapter 09 also discusses deciding what input information to record. In this example, retaining a case identifier, a redacted decision trace and a checked response is enough to explain the local denial without copying order contents into analytics. A production logging design would need its own access, retention and incident-investigation requirements; this fixture does not establish those requirements.
The retailer’s next decision changes if legitimate shared orders exist. An owner-only comparison would then reject some authorised access. The policy would need to represent the relevant relationship and allowed action, and the matrix would need both permitted sharing cases and denied lookalikes. Conversely, a requirement to read records individually despite a failed batch item would change the atomic batch contract. Neither change should be implemented by simply relaxing the existing check.
What the record supports, and what it leaves open
The completed run supports a specific conclusion: this local read fixture enforced its declared ownership policy on twelve inputs, reproduced those outputs, and detected the three deliberately introduced faults. It does not establish production authentication, concurrent permission changes, caching behaviour, write permissions or native agent-tool behaviour. Passing these tests is scoped evidence, not a complete penetration test or security guarantee. No application security engineer or data protection specialist has reviewed this demonstration.
The implementation choice should remain conditional on that boundary. Keep the server-side per-object check as the basis for this owner-only read contract. Do not advance a version that returns another user’s record, leaks a record in an error body or allows an unchecked batch item. Before applying the pattern to a real service, add tests for its actual sharing rules, identity mechanism and every path that can read the same records.
ScaleGrowth’s AgenticReadiness audit systems and WebMCP implementation and consulting are relevant when this work must connect an agent-facing task to an explicit data-access contract. The useful deliverables are the permission policy, object-access matrix, redacted denial traces and versioned replay record, with the untested boundaries preserved. Its organic-growth practitioners can help choose which customer task merits that work; this synthetic run does not prove that a proprietary audit system, browser integration or client deployment has passed it. The WebMCP implementation service is the relevant capability reference, not a substitute for the record-level tests.
References
OWASP API Security Top 10, API1:2023 Broken Object Level Authorization
https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/
OWASP Authorization Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/