AI Coding Agents
Security
Tenant isolation tests for coding agent changes
September 29, 2026 - 2 minute read
Tenant isolation testing checks whether one customer can read, change, or influence another customer’s data. A coding agent may add an endpoint correctly while missing a tenant filter in a background job, cache key, search index, or object-storage path. The resulting change can pass ordinary functional tests and still cross a security boundary.
NIST SP 800-210 treats access control in cloud systems as a set of enforceable policies across service layers. For a shared multi-tenant application, the useful test target is the complete path from authenticated identity to the resource being accessed.
Map every tenant isolation boundary
Start with the application’s tenant identifier and trace where it enters each query, event, cache entry, and file path. Record whether the identifier comes from an authenticated claim, a server-side lookup, or request input. A client-supplied tenant ID should never become authority by itself.
Build fixtures for two tenants with deliberately similar records. Reuse names, timestamps, and object IDs where the data model permits it. Similar fixtures expose accidental lookups by a non-unique field that separate, tidy fixtures can hide.
Include administrative and support roles. Their access should match a documented policy, with explicit tests for the operations they can and cannot perform.
Test tenant isolation beyond request handlers
Run positive tests for a user accessing its own tenant, then change one boundary at a time. Swap the URL identifier, request body, token claim, queue payload, and storage prefix. The service should reject the request or return no record without confirming that another tenant’s resource exists.
Background jobs deserve direct coverage. A worker that receives only a record ID may load data without the tenant condition used by the web request. Test scheduled jobs, retries, exports, notifications, and webhook deliveries with records from both tenants.
Caches and search indexes need the same treatment. Verify that cache keys include the correct tenant scope and that invalidation cannot evict or replace another tenant’s entry. Search results, counts, and autocomplete suggestions must remain isolated too.
Give a coding agent an executable contract
Name the tenant source of truth, protected resource types, privileged roles, and expected response for a denied lookup. Provide commands for focused authorization, worker, and cache tests. Ask for evidence from two-tenant fixtures rather than a single mocked authorization call.
Factory’s Automated Code Review supports repository-specific guidance. A team can require review findings when data access code lacks tenant-scoped queries or when a queue payload loses its tenant context.
Keep credentials and customer data out of the task. Synthetic fixtures should preserve the shape needed to test boundaries without copying production records.
Review tenant isolation test evidence
Inspect the final resource lookup, not only middleware behavior. Middleware can accept the correct identity while a lower-level data-access function performs an unscoped query. Capture the actor tenant, resource tenant, decision, and test name in sanitized output.
Run the tests with concurrency when shared caches or workers are involved. Interleaving work from two tenants can expose process-level state that sequential tests miss. The review is complete when each shared subsystem has both an allowed and denied case.
