Code-execution sandbox certification readiness
Prepare evidence for a separately defined sandbox certification assessment
A customer asks for certification evidence without naming the scheme or assessor. The decision is how to prepare evidence for a separately defined sandbox certification assessment. 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 platform sponsors and qualified certification advisers. 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
- Target scheme requirements
Establish the basis for target scheme.
- Evidence mapping
Link existing controls to required observations.
- Certification-readiness gap map
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around target scheme
Questions and the evidence they need
- Target scheme
- Inspect target scheme requirements for the relevant constraint or observation.
- Evidence mapping
- Inspect scope statements for the relevant constraint or observation.
- Reviewer dependency
- Inspect architecture evidence for the relevant constraint or observation.
The decision is how to prepare evidence for a separately defined sandbox certification assessment. This is relevant to platform sponsors and qualified certification advisers when a customer asks for certification evidence without naming the scheme or assessor. 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 readiness work is mistaken for certification or for an assessor’s acceptance decision. 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
Readiness work begins with named assessment criteria
Relationships within runtime isolation
- Target scheme
- Confirm the applicable criteria and scope.
- Evidence mapping
- Link existing controls to required observations.
- Reviewer dependency
- Identify missing evidence and eligible review roles.
What this specialty examines
Certification readiness starts with the exact scheme, scope and assessor requirements. Without those, evidence preparation lacks an acceptance target. Distinguish technical control gaps from missing documentation and from requirements that need a qualified external opinion.
The review should confirm the target criteria and map existing evidence, missing controls and reviewer dependencies. 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, preparation can organize evidence while formal assessment depends on the selected scheme and qualified assessor. 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 target scheme
Illustrative working format
- Target scheme requirements
- Confirm the applicable revision and who resolves disputed interpretation.
- Scope statements
- Check its relationship to the relevant workflow and expose missing context.
- Architecture evidence
- Name the custodian and the conditions requiring a refreshed version.
- Control-test records
- Establish permitted access, provenance, and which task conditions it represents.
Start with target scheme requirements, scope statements, architecture evidence and control-test records. 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 readiness work is mistaken for certification or for an assessor’s acceptance decision 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 target scheme through to an accountable finding
From the scoped material to a decision record
- Target scheme requirements
Declare the permitted environment and resources.
- Evidence mapping
Apply the scoped check to reviewer dependency.
- Certification-readiness gap map
Record the evidence, open dependencies, and the owner’s next decision.
Prepare the runtime boundary and fixtures
Use target scheme requirements, scope statements, architecture evidence and control-test records to identify the exact runtime and boundary claimed by platform sponsors and qualified certification advisers. 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
Map each selected requirement to existing evidence and identify what would be needed to address gaps. Preserve the assessor’s authority over formal acceptance. Preparation can organize work and reduce ambiguity, but cannot promise a certification result.
Choose containment or configuration changes
Translate the observations into a certification-readiness gap map and proposed evidence preparation plan. 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 certification-readiness gap map usable by its owner
Certification-readiness gap map
Illustrative working format
- Certification-readiness gap map
- Separate demonstrated practice from claims requiring a verified credential authority.
- Evidence preparation plan
- Link observations and counterevidence to the case, configuration, and conclusion limit.
- Evidence mapping evidence
- Link observations and counterevidence to the case, configuration, and conclusion limit.
A useful decision artefact is a certification-readiness gap map and proposed evidence preparation plan. 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 reviewer dependency through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Target scheme
A team requests certification without first choosing a specific scheme.
- Evidence mapping
Identify the target scheme and map its specific evidence requirements.
- Reviewer dependency
Prepare gaps for eligible review without claiming certification.
Consider a fictional situation: a platform team receives a procurement questionnaire requesting certified code isolation but the requested scheme is unspecified. The scenario is illustrative, with no client engagement, executed test or measured improvement implied.
For the unspecified procurement request, the first action is to clarify the requested scheme and assessed boundary. Only then can the team identify relevant artefacts and specialists. A generic sandbox report should not be relabeled as a certificate.
Scope and next action
Keep the conclusion within the authorised runtime boundary
Confirm fit before the next commitment
- Target scheme
- This review is limited to the authorised runtime boundary.
- Target scheme requirements
- The relevant owner must confirm access and the intended operating conditions.
- Certification-readiness gap map
- 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 a customer asks for certification evidence without naming the scheme or assessor; 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.