Tenant isolation

When one agent serves many customers, a new and severe failure appears: one tenant's session reaching another tenant's data. It is severe because the victim is not the attacker — a breach of customer B triggered from customer A's session is exactly the kind of incident that ends contracts.

The tempting implementation is to tell the agent which tenant it is serving and trust it to stay in its lane. That is prompt-level isolation, and it fails the same way every prompt-level control fails: it holds until the model is confused, retrieves the wrong record, or is talked across the line. And here the cost of the model being wrong once is another customer's data.

Real isolation lives at the data layer. The credential the agent uses is scoped to the tenant, so a lookup for another tenant's id does not return a refusal the model might argue with — it returns nothing, because the query is not authorised at the source. The agent cannot leak what its credential cannot fetch. This is least privilege applied to the isolation boundary, and it is the same pattern as the secrets proxy: move the control from the model's judgement to the infrastructure.

The lab runs two probes — an Acme session reaching for Globex's account, and the reverse — with isolation enforced by the prompt only, then at the data layer. Prompt-only might hold on any given run, which is the trap: it teaches false confidence. Turn isolation on and the probes stop returning data at all, because the boundary is no longer a request the model can be persuaded to make.