Sandbox platform assessment
Decide what a collaborative platform assessment can establish about the intended boundary
When a sandbox platform is considered for a specific agent deployment, this area becomes relevant. For the platform security or procurement owner, the concern is specific: a product feature list is treated as proof of isolation in the customer's configuration. The collaboration qualification starts from that consequence and follows the relevant evidence through the customer workflow. The assessment should connect platform properties to the deployment being considered. Any technical boundary testing requires explicit authorisation and qualified reviewers; product selection should remain separate from unsupported claims of escape resistance.
The collaboration responsibilities relationship
- Execution model
Establish the basis for configuration assumption.
- Evidence access
Confirm observations the platform can expose.
- Sandbox boundary assessment plan
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around configuration assumption
Questions and the evidence they need
- Configuration assumption
- Inspect execution model for the relevant constraint or observation.
- Evidence access
- Inspect network and storage configuration for the relevant constraint or observation.
- Test authorisation
- Inspect platform responsibility terms for the relevant constraint or observation.
For the platform security or procurement owner, this becomes relevant when a sandbox platform is considered for a specific agent deployment. The immediate decision is what a collaborative platform assessment can establish about the intended boundary. The scope should be narrow enough that the proposed collaborators can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that a product feature list is treated as proof of isolation in the customer’s configuration. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Mechanism
Sandbox collaboration must separate platform and customer proof
Relationships within collaboration responsibilities
- Configuration assumption
- Identify settings the customer controls.
- Evidence access
- Confirm observations the platform can expose.
- Test authorisation
- Qualify the people and boundary for technical challenges.
Customer configuration assumptions
For this scope, customer configuration assumptions should be examined alongside execution model. Map platform documentation to the customer’s intended sandbox configuration and surrounding agent workflow. Distinguish documented properties from observed behaviour. Qualification should identify secrets, egress, persistence, artefacts, and ownership questions that product-level descriptions cannot settle for a specific deployment.
Evidence access
For this scope, evidence access should be examined alongside network and storage configuration. Establish what evidence the platform and customer can provide within approved access boundaries. Missing visibility limits conclusions. The proposed assessment should record unresolved provider dependencies and avoid inferring isolation or escape resistance merely because the platform advertises a sandbox feature.
Specialist test authorisation
For this scope, specialist test authorisation should be examined alongside platform responsibility terms. Use qualified specialists to define any authorised boundary tests. Integration review and adversarial security testing are different scopes. The proposed collaboration should preserve the permitted environment, methods, and findings handoff before discussing broader claims or making a procurement recommendation based on unverified assumptions.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for configuration assumption
Illustrative working format
- Execution model
- Match this description to the deployed or proposed boundary being examined.
- Network and storage configuration
- Match this description to the deployed or proposed boundary being examined.
- Platform responsibility terms
- Identify the accountable role and verify its decision rights or availability.
The starting material is execution model, network and storage configuration, and platform responsibility terms. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include a customer-side sponsor, a technical owner, and the people who would accept delivery and support responsibilities. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Carry configuration assumption through to an accountable finding
From the scoped material to a decision record
- Execution model
Qualify the customer need and participation required.
- Evidence access
Apply the scoped check to test authorisation.
- Sandbox boundary assessment plan
Record the evidence, open dependencies, and the owner’s next decision.
The assessment plan should identify which platform evidence is documentation, which is configuration evidence, and which requires observed testing. Ask how the customer will control secrets, egress, persistence, and cleanup in its intended integration. Where access prevents verification, preserve an explicit unknown rather than borrowing a product-level claim.
A practical first slice would focus on customer configuration assumptions and then follow its consequences into evidence access. Keep specialist test authorisation visible as a separate review question rather than assuming it is satisfied by the first result. The proposed collaborators should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefact
Make the sandbox boundary assessment plan usable by its owner
Sandbox boundary assessment plan
Illustrative working format
- Sandbox boundary assessment plan
- Identify the assessed workflow, revision, and decision boundary.
- Shared responsibility map
- Name the role, decision right, handoff, and unresolved ownership boundary.
- Unresolved proof requests
- Name the missing evidence, responsible owner, and condition for revisiting the decision.
Indicative outputs include sandbox boundary assessment plan, shared responsibility map, and unresolved proof requests. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Examine test authorisation through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Configuration assumption
A managed code sandbox connects to internal enterprise tools.
- Evidence access
Separate customer sandbox settings from provider-enforced controls.
- Test authorisation
Record unavailable platform evidence and separately authorise specialist testing.
Consider an illustrative situation in which a team wants agents to execute code in a managed sandbox connected to internal tools. This is a constructed example, not a client engagement or an observed Softlander outcome.
For the code-execution example, a proposed collaboration would first map trust boundaries and permitted outputs. Qualified specialists could then define authorised tests for the material boundaries. The customer’s procurement decision should consider both findings and unverified dependencies, with no implication that platform selection certifies the surrounding agent system.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves specialist test authorisation unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and next action
Keep the conclusion within the proposed collaboration scope
Confirm fit before the next commitment
- Configuration assumption
- This review is limited to the proposed collaboration scope.
- Execution model
- The relevant owner must confirm access and the intended operating conditions.
- Partnership and capacity
- Neither an existing relationship nor available delivery staffing is established here.
A public partnership, certified status, staffing commitment, or response obligation would require separately verified evidence and authorisation. This collaboration model is presented for qualification; it does not announce an existing relationship.