AI security platforms: test tenant isolation

Evaluate tenant isolation in an AI security platform across records, caches, background jobs, exports and recovery. Use two authorised test tenants with different synthetic data, then check that each identity receives only the resources and operations its current permissions allow.

An enterprise platform can hold sensitive policy, identity and investigation information even when it minimises conversation content. This guide translates OWASP's multi-tenant security guidance into procurement questions and a bounded acceptance exercise. No vendor platform was tested for this article.

Define the boundary the supplier promises

Ask what a tenant represents: a customer organisation, a business unit, an environment or a managed-service client. Establish whether one person can legitimately belong to several tenants and how they select their active context.

List tenant-owned resources, including policy versions, device records, detection events, saved searches, exports and connector configuration. Mark intentionally shared resources separately. A global documentation catalogue can be shared while an organisation's investigation records require restricted access.

OWASP describes database, schema, row-level and hybrid isolation strategies. Their suitability depends on enforced permissions and operational paths. Ask the supplier to name its boundary for each data class, including the administrators and service identities that can cross it.

Verify identity and resource ownership together

OWASP treats a client-supplied tenant identifier as a selector requiring server-side verification. A hard-to-guess identifier supplies no independent authority to access another organisation's resources.

Set up Tenant Cedar and Tenant Quartz in a vendor-approved test environment. Use fictional device names and event records with visibly different markers. Create an administrator and a restricted reader in each tenant, plus a separate identity authorised for both only if that reflects the intended deployment.

Write the expected read, export and policy-change permissions before testing. Through documented interfaces, confirm legitimate operations succeed and requests outside the test identity's tenant or role are rejected. Keep the exercise confined to the two controlled tenants; customer identifiers and production probing are unnecessary.

Exercise reused state

A successful first request leaves caches and sessions to check. Ask whether tenant-sensitive results and authorisation decisions include tenant scope in their cache boundaries. Record how a membership or role change invalidates reusable decisions.

For an identity legitimately allowed into both test tenants, visit the same report in each context and switch back. Use different synthetic totals so stale data is recognisable. Repeat with a fresh session and a previously opened report. The expected result should specify which cached information may remain visible after authority changes.

Include saved filters, search suggestions, downloads and dashboard counts. These can reveal information independently of the main event-detail screen. An empty detail page leaves a leaked count or export to be assessed on its own.

Follow queued work to its destination

Background exports and scheduled reports may execute after the original request. OWASP recommends carrying verified tenant context through asynchronous work and re-establishing authorisation at the consumer, including time-sensitive permissions when delayed execution could make them stale.

Ask the supplier to demonstrate a controlled export queued before a test user's membership changes. Agree the intended cancellation or completion rule first. Verify the job's owner, source records, destination and resulting download permissions against that rule.

Review retries and duplicate prevention too. Two tenants submitting similar jobs should retain separate ownership and results. Record what happens to failed jobs, who can inspect their diagnostic records and whether support staff require explicit cross-tenant authority.

Inspect exports and recovery

For an exported file, establish who can generate access, which exact object is authorised and how long the link remains valid. OWASP recommends limiting signed URLs to the required object and method, with an appropriate lifetime and revocation model.

A copied signed link may remain usable under its documented bearer-access design. Evaluate that behaviour against your requirements. Protect the link during testing and record the actual expiry and revocation limits.

Recovery needs a separate exercise. A shared backup can contain several tenants. Ask for a lab restore of Cedar while Quartz has distinct synthetic records in the source backup. Confirm that recovered Cedar data excludes Quartz records and that current access rules are reapplied.

This restore should occur in an isolated, approved environment. The exercise supplies evidence about recovery scoping without overwriting live data or giving a tenant operator access to a shared backup.

Retain a decision-ready evidence record

For each case, keep the tested identity and role, tenant, resource class, expected outcome, observed result, software version and remaining limitation. Use bounded identifiers and keep sensitive event content out of the procurement pack.

Assign unresolved paths an owner and an acceptance decision. A supplier statement, architecture diagram and controlled result provide different evidence. Keep untested support access or recovery behaviour explicit until the required proof is available.

Our privacy checklist for AI security monitoring covers what information a platform collects. Tenant-isolation testing adds the next question: which organisation and identity can obtain or change it throughout its lifecycle?

Map your AI security requirements with Promptective.