Tenant-isolation assessment
Assess separation between tenants sharing agent execution infrastructure
Several customers use a common sandbox pool or control plane. The decision is how to assess separation between tenants sharing agent execution infrastructure. The work begins with your actual workflow and looks for the evidence that separates intended behaviour from a consequential exception. It is particularly relevant to multi-tenant runtime owners and security architects. A useful outcome is an explicit account of what was examined, what remains uncertain, and which decision the evidence can support.
The runtime isolation relationship
- Tenant allocation rules
Establish the basis for scheduler identity.
- State namespace
Partition storage and cache lookup paths.
- Tenant isolation assessment
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around scheduler identity
Questions and the evidence they need
- Scheduler identity
- Inspect tenant allocation rules for the relevant constraint or observation.
- State namespace
- Inspect storage namespaces for the relevant constraint or observation.
- Artefact access
- Inspect cache keys for the relevant constraint or observation.
The decision is how to assess separation between tenants sharing agent execution infrastructure. This is relevant to multi-tenant runtime owners and security architects when several customers use a common sandbox pool or control plane. Name the affected workflow, the consequence of a wrong decision, and the owner who can act on the result. The initial discussion should establish which evidence is already available and which uncertainty is material enough to investigate.
The specific failure hypothesis is that isolation at the worker level is undermined by shared artefact or session indexes. It remains a hypothesis until examined in the deployment. Existing internal tests or operating records may already resolve it; identify the uncovered question before commissioning additional work.
Mechanism
Tenant separation spans scheduling through artefact retrieval
Relationships within runtime isolation
- Scheduler identity
- Preserve tenant context during worker assignment.
- State namespace
- Partition storage and cache lookup paths.
- Artefact access
- Check tenant binding when results are retrieved.
What this specialty examines
Tenant isolation extends through scheduling, storage and management interfaces. Separate workers can still share artefact indexes, logs or caches that identify resources incorrectly. Describe tenant context at each lookup and authorisation point rather than assuming compute separation covers everything.
The review should trace tenant identity through scheduling, execution, storage, logs and artefact retrieval. Identify the normal route, relevant exceptions and the authoritative record of the outcome. Inspect the relevant business-system record, enforcement event or process evidence alongside any reported status. Keep incomplete cases visible, with an explanation of what their absence prevents the owner from concluding.
The tradeoff to make explicit
For this decision, shared infrastructure reduces duplication while isolation must extend beyond the compute process. Compare the available design or operating choices against the same intended outcome. If one option removes a required control or changes the task boundary, describe that difference before treating its apparent simplicity, speed or lower effort as an improvement. The decision should expose the tradeoff instead of burying it in an aggregate score.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for scheduler identity
Illustrative working format
- Tenant allocation rules
- Confirm the applicable revision and who resolves disputed interpretation.
- Storage namespaces
- Check its relationship to the relevant workflow and expose missing context.
- Cache keys
- Name the custodian and the conditions requiring a refreshed version.
- Synthetic tenant cases
- Keep expected behaviour and the limits of the constructed example explicit.
Start with tenant allocation rules, storage namespaces, cache keys and synthetic tenant cases. Identify the owner, revision and operating context of each source. Sanitised examples may support initial design, but differences from actual conditions should remain explicit. Where direct access is unsuitable, a customer-controlled evidence or execution route may be considered, with agreed handling and retention.
The scope also needs the runtime owner, agreed expectations for a representative boundary test, and the authority to inspect the relevant boundary. Specify what evidence would distinguish the failure in which isolation at the worker level is undermined by shared artefact or session indexes from acceptable behaviour. If stakeholders disagree about intended behaviour, resolve the interpretation before classifying the observed difference as a defect.
How the work proceeds
Carry scheduler identity through to an accountable finding
From the scoped material to a decision record
- Tenant allocation rules
Declare the permitted environment and resources.
- State namespace
Apply the scoped check to artefact access.
- Tenant isolation assessment
Record the evidence, open dependencies, and the owner’s next decision.
Prepare the runtime boundary and fixtures
Use tenant allocation rules, storage namespaces, cache keys and synthetic tenant cases to identify the exact runtime and boundary claimed by multi-tenant runtime owners and security architects. Mark permitted resources and protected resources in a controlled fixture, including shared services where they are relevant. Define observable success, denial and incomplete setup before execution. The preparation output is a boundary map and fixture manifest that lets reviewers distinguish effective isolation from a test that never reached its target.
Exercise and inspect the boundary
Use paired tenants with similar filenames and task identifiers. Test ordinary access and management or retrieval paths included in scope. Preserve both attempted access and the returned resource identity so a false match cannot be mistaken for success.
Choose containment or configuration changes
Translate the observations into a tenant isolation assessment with cross-layer boundary findings. Locate each issue in the worker, shared service, policy rollout or cleanup path rather than attributing every symptom to the sandbox as a whole. Decide which configuration change, narrower resource exposure or specialist investigation is warranted. Retest the affected boundary and inspect residual state before treating the changed environment as equivalent to the intended design.
Indicative artefact
Make the tenant isolation assessment usable by its owner
Tenant isolation assessment
Illustrative working format
- Tenant isolation assessment
- Identify the assessed workflow, revision, and decision boundary.
- Cross-layer boundary findings
- Link observations and counterevidence to the case, configuration, and conclusion limit.
- State namespace evidence
- Link observations and counterevidence to the case, configuration, and conclusion limit.
A useful decision artefact is a tenant isolation assessment with cross-layer boundary findings. Supporting material may include selected cases, configuration or process records, evidence references, a disagreement log and prioritised actions. Retain the case selection rationale and material disagreements alongside the result; otherwise the result may be mistaken for complete coverage.
Illustrative scenario
Examine artefact access through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Scheduler identity
A correctly isolated worker exports an artefact through a shared namespace.
- State namespace
Trace the tenant identifier from scheduling to artefact download.
- Artefact access
Repair the export boundary even if worker execution itself is isolated.
Consider a fictional situation: two fictional customers have separate workers but an artefact endpoint accepts a filename without tenant context. The scenario is illustrative, with no client engagement, executed test or measured improvement implied.
For the filename-only artefact endpoint, request one tenant’s marker through the other’s context. A corrected design should bind lookup and authorisation to tenant ownership. The finding belongs to the artefact service even if worker isolation itself holds.
Scope and next action
Keep the conclusion within the authorised runtime boundary
Confirm fit before the next commitment
- Scheduler identity
- This review is limited to the authorised runtime boundary.
- Tenant allocation rules
- The relevant owner must confirm access and the intended operating conditions.
- Tenant isolation assessment
- Untested surfaces remain outside the conclusion.
Testing is confined to explicitly authorised environments and non-destructive cases. A bounded assessment cannot establish that escape or cross-boundary access is impossible. Any engagement depends on an agreed scope, qualified team, authorised access and confirmed availability. Bring the affected workflow, its current configuration or process, the triggering change and the evidence already available. The immediate scope question is prompted by the situation in which several customers use a common sandbox pool or control plane; confirm which missing observation would change the owner’s next action.
Ways to engage
Related engagement scopes
AI Agent Runtime Security Review
Make every delegation explicit. Examine who the agent acts for, where it can execute and which tools it can reach when instructions alone are not enough.
AI Agent Red Team
Challenge the boundaries that matter to your workflow. Test agreed attack scenarios against agent instructions, tools and data access.
AI Agent Sandbox Assurance
Examine the boundary between agent execution and the systems around it, including files, networks, secrets and cleanup.
Continue exploring
Related insights and resources
The permission boundary behind every agent action
An agent can only be evaluated in the context of what its tools allow. Examine identity, delegated authority and action boundaries before you put a workflow in motion.
Before your agent can act, define its authority
A working paper for the moment an AI system moves from advice to action. Map identity, permissions, approvals and recovery into an authority model your team can review and test.
Computer-use agents bring the interface back into the threat model
A computer-use agent treats pixels, accessibility data and interface state as both evidence and an action surface. Security must bind intent to effects beyond the screen.