The agent was allowed to choose an account to investigate, but that is not the same as choosing its authorization scope. A tenant ID found in retrieved text is task data, not a grant. If the tool trusts that argument and runs under a broad service credential, a model mistake or malicious document can become a cross-tenant read. OWASP's broken object-level authorization guidance calls for checking the caller's access to each requested record. The check must apply at the server-side tool boundary, independently of whether the LLM asked politely or whether search should have returned the note.

I would trace the authenticated principal, customer context selected by the real user, delegated scope presented to the tool, returned search document and exact tool parameters. The server derives or validates tenant scope from an authenticated session or delegated capability, not from an untrusted model-supplied tenant field. For a cross-account support workflow, require an explicit approved role and reason, a scoped token, audit, and a UI that makes the account switch visible. A generic database credential with unrestricted tenant access makes one missed check catastrophic.

Defense in depth matters. Filter retrieval by authorized tenant, label snippets with provenance, and reject mismatched tenant IDs in the tool. Test crafted notes that contain plausible IDs for other customers, including indirect references and tool-call-looking text. Log the attempted cross-tenant call without copying B's private response into the agent's context. If the tool did return it, investigate downstream use, caches, traces and retention. The answer must account for exposure, not just fix the next request.

An interviewer may say the search index was already permission filtered. Good, but a document belonging to A can legitimately mention B. That mention still cannot authorize reading B's account. A new tool field can bypass the old authorization check covers a newly added tool field that bypasses an old check, and The SQL tool uses parameters. Why can the agent still choose the wrong table? covers agent-selected SQL tables. This question is narrower: a valid object identifier learned from content must be bound to the acting principal at execution time.