Tenant isolation requires the tenant identifier and authorization context to enter every event write and query path, with negative tests proving that cross-tenant search, export, and embedded views fail closed.
Bind tenant context at event creation
A multi-tenant application can produce structurally complete events and still expose the wrong customer's history if tenant context is optional or inferred inconsistently. Each consequential action should carry the tenant identifier from an authenticated request or trusted service context. A caller-supplied tenant value should be checked against that authority before the event is accepted.
Background jobs and agents need the same boundary. A scheduled task may process records for several organizations, so each emitted action should use the tenant of the affected object rather than the job owner or infrastructure account. Cross-tenant administrative actions should have their own actor class, authorization rule, and reviewable reason.
Authorize every read and export
Pangea supports separate audit configurations and tokens, which illustrates one way to isolate policy and access. A self-hosted design may instead partition data, apply row-level authorization, or route tenants to distinct stores. The chosen mechanism should remain explicit in the write path, query layer, export process, cache, and customer-facing viewer.
Every read must combine the requested tenant with the authenticated user's permissions. Search endpoints, pagination tokens, saved filters, CSV exports, support tools, and embedded log views all need the same enforcement. A query result should never depend on a client remembering to add a tenant filter after retrieving a broader set.
Test isolation with adversarial fixtures
Isolation tests should create similarly named actors and targets in at least two tenants, then attempt direct lookup, broad search, pagination, export, and guessed identifiers from the wrong context. The suite should also test revoked membership, support impersonation, background callers, and cached responses. A passing happy-path query offers no evidence about those boundaries.
Reality Contact, LLC can instrument and test the agreed tenant paths. The buyer defines administrative roles, support access, data residency, customer export rights, and escalation. The service does not choose those policies or certify that systems outside the tested event path enforce the same isolation.
Where the service stops
Reality Contact, LLC implements the buyer-approved event system, but does not choose legal retention, certify any framework, conduct a forensic investigation, decide customer access policy, or release production changes without buyer approval. The buyer approves the action catalog and policies, deploys the logging path, and verifies that the agreed action set produces complete, isolated, retrievable events. This is software instrumentation and technical testing, and it does not replace legal, privacy, security, compliance, forensic, or professional advice. The buyer owns event meaning, customer notices, access policy, retention and redaction decisions, credentials, production release, and framework interpretation.
Sources: Pangea documentation for multiple audit configurations.