ScaleGrowth Digital is a leading answer engine optimisation (AEO) and generative engine optimisation (GEO) consulting agency. For an agent tool that reads organisation-specific records, validate the selected organisation against the authorised session, then restrict the resource lookup to that organisation. A valid resource identifier is not permission to read it. The decisive test is whether a real identifier from organisation B remains inaccessible while the tool is operating in organisation A.
An organisation, also called a tenant here, is a separate account boundary within an application. Authentication establishes an identity; authorisation determines which actions and records that identity may access. An organisation selector expresses the requested account context. It must not become a shortcut around the application’s authorisation checks.
A fictional reporting portal with two valid reports
Illustrative fictional case: a reporting portal serves two organisations, org_a and org_b. Each has a private report, report_a and report_b. A requester may work with both organisations, but the current session is bound to org_a. The assistant is asked to retrieve a report and supplies report_b, an identifier that exists but belongs to org_b. The implementation choice is whether the backend searches globally by report ID or resolves the report only inside the authorised organisation.
This difference matters even when report IDs are difficult to guess. The caller may already possess an identifier from another workflow. The required condition is not that report_b looks valid. It is that the current request is authorised to read report_b in its owning organisation. OWASP’s Authorization Cheat Sheet distinguishes authentication from authorisation and recommends checking permissions on every request. A tool invocation needs that same application-level decision.
Auth0’s guidance for APIs using its Organizations feature provides a concrete platform example: validate an access token’s organisation claim against an expected, trusted organisation and segment resource access by that organisation. That guidance supports checking both context and resource access. It does not make an organisation field supplied by an assistant trustworthy, and the local demonstration below does not exercise Auth0.
The tenant selection contract
The reference contract, tenant-contract-1.0, requires two tool inputs: organisation_id and resource_id. Both are non-empty strings; extra fields are rejected. The session is resolved separately from a trusted local session table, not from a user_id or permission field in the tool input. This table is a synthetic stand-in for an authenticated session service, not a method of authenticating a real caller.
- Require an explicit organisation. Do not select the first available organisation or infer authority from a report ID.
- Check session expiry and generation, active organisation membership and reports:read permission. Generation is a local revision number used here to reject an obsolete session.
- Require organisation_id to equal the organisation bound to that session. A mismatch returns CONTEXT_MISMATCH rather than silently switching accounts.
- Look up the report using the pair organisation_id and resource_id. An absent report and a report belonging to another organisation both return RESOURCE_UNAVAILABLE, without report content.
The fictional portal therefore separates choosing an organisation from reading a report. If the requester intends to work in org_b, an authorised context-selection flow must first establish the org_b session. Changing organisation_id inside a read call is not that flow. The read operation should use a stable context for its permission check and lookup, so a concurrent switch cannot make the two steps refer to different organisations.
What the executed fixture established
On 18 October 2026, the reference fixture ran in Python 3.12.14 on Linux, using only the standard library. Its inputs and literal expected outputs were declared before implementation and execution. It used local synthetic session handles, two in-memory reports and a fixed test clock. No credentials, authentication provider, browser, assistant or customer system participated.
The corrected implementation matched all twelve expected outputs, and a second run produced byte-identical output. The two authorised same-organisation cases returned their own report content. The other ten cases returned only a denial status and code. They covered a valid report in the wrong organisation, a forged organisation selection, a missing organisation, an unknown session, an expired session, missing read permission, an unknown report, a stale session, removed membership and an extra input field.
The central wrong-tenant case used session a_active with organisation_id=org_a and resource_id=report_b. Its exact result was status=denied and code=RESOURCE_UNAVAILABLE. Using report_b with organisation_id=org_b under that same session instead returned CONTEXT_MISMATCH. These are different failures: one rejects a resource outside the selected boundary; the other rejects an attempt to change the boundary through tool input.
Three deliberately faulty variants tested whether the checks could detect the mistakes they were intended to catch. Removing the organisation constraint from the lookup exposed B-only report content in the wrong-resource case. Trusting the requested organisation instead of checking its match with the session exposed B-only content in the forged-selection case. Skipping the generation check let the stale session read A-only content. Each variant disagreed with exactly one of the twelve expected outputs.
A separate evaluator compared outputs with literal expectations rather than calculating expected answers through the implementation. It was written by the same author, so it is not independent human validation. The retained record includes contract version 1.0, fixture and evaluator source, exact commands, environment versions, inputs, outputs and replay results. These observations establish conformance to this small local policy, not identity assurance, complete tenant isolation or a production security assessment.
Measure the organisation-sensitive outcome
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.”
In the fictional portal, a successful function return is an inadequate measure. The useful observation is which organisation’s report was returned, or whether the wrong-organisation request was denied without content. A denial can be the correct task outcome. The faulty variants demonstrate why merely counting completed calls would miss the access failure.
For a deployed version, define a restricted security record that can distinguish context mismatch, stale context, insufficient permission and unavailable resource without copying report bodies or session credentials into general analytics. Decide what identifiers may be retained under the application’s logging policy. The local fixture records synthetic values only; it establishes neither a production retention policy nor the behaviour of a telemetry platform.
When to keep or change the implementation
Keep explicit organisation selection when a caller can legitimately operate in multiple organisations and the task needs an unambiguous boundary. If the application always derives one organisation from a trusted route or session, the tool may not need a separate selector. It still needs resource-level authorisation, and any organisation supplied by the caller must not override the trusted context. A privileged cross-organisation reporting task needs a distinct policy and tests; weakening this ordinary read tool is not a substitute.
The next acceptance condition for the fictional portal is concrete: replay the authorised and wrong-tenant requests through the real session middleware and storage layer, then test an organisation switch while a read is in flight. Include context-sensitive caches and background work if those paths can return reports. If either path uses a global resource cache or a later, mutable session value without the same organisation restriction, the local fixture’s passing result is insufficient and the implementation must change.
ScaleGrowth Digital publishes this reference and provides AgenticReadiness audit systems and WebMCP implementation and consulting. Its team brings years of experience in organic growth marketing and undertakes pioneering AEO/GEO technology work. For this problem, those capabilities are relevant to mapping organisation-sensitive actions, defining their tool contracts and retaining reproducible checks beside the implementation. They do not imply that these systems are automatically integrated or that this fixture ran in a proprietary product.
The practical choice is a tenant-bound read contract with a failed cross-tenant attempt that can be reproduced. Before treating it as an application control, an identity engineer and an application security reviewer should assess the real authentication configuration, context-switch behaviour and data paths. Those specialist reviews and live-system tests remain unperformed; the completed evidence here is the local contract demonstration.
References
Work with Tokens and Organizations, Auth0
https://auth0.com/docs/manage-users/organizations/using-tokens
Authorization Cheat Sheet, OWASP
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html