A service provider's authentication agent may work for many customers, but each operation should have one verified customer context. A customer name in a prompt is not an access-control decision. Bind the session and job to the tenant identified by the trusted application, then carry that identity through retrieval, proposal, approval, execution and evidence storage.
Establish the customer boundary
During onboarding, obtain the approved domain inventory and the customer administrator's authority for the requested service. Record tenant identifiers that are stable and unique, rather than relying on similar display names. Verify that the DNS zones and report destinations belong to the intended scope before granting access.
Use customer-scoped credentials or an equally enforceable downstream authorization mechanism. A central service identity with broad access needs robust checks at every resource lookup. OWASP describes the risk of generic privileged identities accessing resources beyond the relevant user context. OWASP LLM06.
Keep evidence separated
Apply tenant scope to report storage, search indexes, caches, conversation context and exported files. Restrict retrieval before evidence reaches the model. Filtering another customer's material out of the final answer is too late if it already entered the working context. Logs need access controls too; a shared debugging dashboard can defeat otherwise careful separation.
An IP or provider name shared by two customers is not permission to join their private evidence. Record public infrastructure facts separately from customer-specific account ownership, service activity and contacts. A similar domain suffix or common reseller does not make two tenants one authorization boundary.
Trace a queued job across a revoked grant
Suppose a job is created under customer A’s valid grant, then the access administrator revokes that grant before execution. The executor must recheck current authority rather than rely on the earlier session. If a cache also contains customer B’s record under the same short name, the lookup must remain scoped to A; shared infrastructure and similar names cannot justify retrieving B’s private evidence.
These are hypothetical boundary cases, not a tested connector or supplied runbook. Assign distinct responsibilities for scope approval, operational changes, independent access review and offboarding. Define measurable acceptance conditions for the actual deployment, including an allowed A request and denied B request, revoked queued jobs and appropriately scoped cache retrieval. Do not claim zero cross-tenant exposure until the relevant paths have actually been tested.
Check jobs as well as sessions
Bind approval to the tenant and verify the same identity at execution time. Do not let the model choose which credential to use from a free-text customer name. Recheck authorization when a queued job runs; a grant may have been revoked after the job was created. Expired or transferred customer relationships need explicit handling rather than inherited access.
Test with deliberately similar customer names, overlapping provider IPs, reused record names and a cached answer from a different tenant. Include an allowed customer-a read so the test proves scoped access, not a globally disabled connector. The hypothetical examples above do not execute any of these deployment tests. Retain actual request context, authorization decisions and observed effects when evaluating them.
Close the relationship cleanly
Offboarding should stop new work, revoke access, handle queued jobs and apply the agreed evidence-retention process. Confirm each action through the responsible system. Retain the minimum audit history needed to explain previous work under the applicable agreement. Do not erase evidence automatically or keep indefinite access merely because the agent might need to answer a later question.