Guardrails Versus Access Control in a Multi-Tenant Assistant
A healthcare SaaS provider runs a generative AI assistant for clinic staff across 60 tenant organizations. Each tenant's patient notes are stored in its own S3 prefix and indexed into a shared vector store with tenant metadata. The assistant answers questions like 'summarize this patient's recent visits.' A penetration test finds that a crafted prompt can make the assistant return notes from a different tenant when the vector store returns a cross-tenant match. The team's first proposal is to add a prompt instruction saying 'never reveal other tenants' data' and to rely on the model's built-in safety filters. The system must meet HIPAA obligations and support audit requests.
1. Explain why the prompt-instruction proposal is inadequate and what control actually prevents cross-tenant leakage.
Read the worked answer
A prompt instruction is a soft control: it influences model behavior but does not enforce a boundary. The penetration test already shows the model can be steered past instructions with crafted input, and safety filters target harmful content, not tenant authorization. Neither is an access-control mechanism, and neither produces an auditable record that a specific tenant's data was never returned to another.
The real fix is enforcement outside the model. Tenant identity must be established from the authenticated session, not from anything in the prompt. Retrieval must be filtered by tenant ID at the data layer - for example, metadata filters on the vector query and separate S3 prefixes with per-tenant IAM conditions - so cross-tenant documents are never placed in the model's context. If the document never enters the context, the model cannot leak it, regardless of prompt.
Defense in depth: keep the prompt instruction and output checks as secondary layers, but treat them as supplements, not the boundary. Add a post-generation check that every cited source belongs to the requesting tenant, and log the tenant ID, retrieved document IDs, and response for audit.
2. What logging, monitoring, and audit design would let the provider answer a regulator's question about whether a specific tenant's data was exposed?
Read the worked answer
The provider needs records that reconstruct exactly what happened for each request, tied to tenant identity.
Log per request: authenticated tenant ID and user, timestamp, the query, the retrieved document IDs and their tenant metadata, the model output, and any guardrail or verification flags. Store logs in an immutable, access-controlled location with retention that meets HIPAA and contractual requirements, and encrypt them.
Monitoring: alert on any request where a retrieved document's tenant does not match the session tenant - this should be treated as a security incident, not a model quality issue. Track counts of such mismatches over time and review them.
Audit design: because the retrieval layer enforces tenant filtering, the logs can show that no cross-tenant document was ever placed in context. That is a stronger answer to a regulator than asserting the model was instructed not to leak. Include the penetration-test finding, the remediation, and the test re-run in the audit record.
Also document data flow, encryption at rest and in transit, IAM boundaries, and a breach-response procedure, since the provider must be able to show both prevention and detection.