Not based on a specific customer deployment. The company, figures, decisions, and outcomes below are a constructed example that shows how Intended’s mechanism applies to this kind of problem. They are not measured results from a named customer. Where we publish a real, attributed customer outcome, we will say so explicitly.
Proving AI-Agent Tenant Isolation to Auditors and Customers
Consider a B2B SaaS platform whose AI agents handle customer onboarding, data migration, support automation, and cross-tenant analytics — and whose enterprise customers and auditors ask for proof of tenant isolation.
01 · the challenge
The kind of problem this addresses.
02 · how it works
See the difference.
AI agent (Tenant A context)
Authenticated as TenantA support agent
Requests Tenant B customer data
query: SELECT * FROM customers WHERE tenant_id = 'B'
Data returned
Application-layer check missed edge case
Tenant B data exposed
No audit trail of cross-tenant access
03 · the solution
What they deployed.
- — Started from Intended's customer-data-egress policy pack, which denies cross-tenant data movement and escalates bulk exports
- — Every agent request carries the calling tenant and the target tenant, and policy denies on a mismatch
- — Cross-tenant access set to automatic DENY with zero exception policy
- — Every tenant boundary check, pass or fail, is a decision in the tamper-evident, hash-chained audit trail
- — Auditors get the audit export of boundary decisions, and can check the hash chain themselves
04 · implementation
From zero to governed.
Week 1
Instrument
Add the Intended SDK to every AI agent service, passing the calling and target tenant with each request.
Week 2
Configure
Install the customer-data-egress pack. Define tenant isolation policies, cross-tenant deny rules, and a webhook for alerting.
Week 3
Audit-ready
Export tenant-isolation evidence for auditors and customer security reviews. Every boundary check can be verified against the hash chain.
05 · illustrative outcomes
What this is designed to deliver.
Modeled figures for this scenario — what the workflow above is built to achieve, not measured results from a named customer.
0%
Cross-tenant access denied
Zero-exception policy on tenant mismatch
0%
Boundary checks evidenced
Pass and fail, in the audit chain
0 min
Max token lifetime
Signed and single-use
0%
Decisions with a receipt
Verifiable against the tenant's public keys
06 · decision replay
Example decisions, full trace.
Sample decision records that show the shape of the evidence Intended produces. Illustrative, not drawn from a live customer’s logs.
saas.data.tenant-queryRISK: 8/100ALLOWSupport agent queries customer list for Tenant: Acme Corp (tenant_id: acme-001)
Resolved by: Policy: same-tenant data access, authenticated agent
saas.data.cross-tenant-accessRISK: 100/100DENYMigration agent (Tenant: Acme) attempts to read schema from Tenant: GlobalTech
Resolved by: Policy: cross-tenant access forbidden (tenant mismatch)
saas.onboarding.provision-tenantRISK: 32/100ALLOWOnboarding agent creates new tenant workspace for Pinnacle Industries
Resolved by: Policy: provisioning allowed for onboarding agents with valid contract
saas.analytics.cross-tenant-aggregateRISK: 45/100ESCALATEAnalytics agent requests anonymized usage metrics across all tenants
Resolved by: Data Privacy Officer (approved aggregated-only access)
the takeaway
Tenant isolation is hard to prove with application-layer logs alone. When every boundary check is recorded in a cryptographic chain, an auditor can verify isolation independently instead of taking the platform's word for it.
Why this pattern matters — not a customer quote.
Start proving tenant isolation
Free to start. See every AI decision from day one.