Cloud sandbox security: buyer checklist

A temporary environment can disappear from a dashboard while leaving a harder question unanswered: what happens to the storage it used? Cloud sandbox security reviews should cover that entire lifecycle, from the information a workload receives to the evidence supporting its eventual deletion.

For a small IT team, the practical starting point is five questions: what persists, how customers are separated, what deletion covers, how the controls are tested and what evidence survives an incident. The worksheet below turns those questions into a supplier review you can use for hosted development environments and AI sandboxes.

What Cloudflare disclosed

On 24 September 2026, Cloudflare disclosed a vulnerability affecting Containers and Sandboxes. Researchers could recover residual disk data from previous workloads on the same host. They could not choose a particular victim or read another customer's actively attached disk. Cloudflare's technical report.

The issue was reported on 4 September. Cloudflare changed storage allocation and cleaned up existing disks and cached snapshots, completing the final cleanup on 19 September. The company says no customer remediation is required and its retained telemetry showed no evidence of malicious exploitation. Those findings are Cloudflare's reported investigation results, not an independent guarantee that no exposure occurred. Disclosure and timeline.

The useful procurement lesson is to ask for evidence about what happens after a workload finishes. The following checklist is a proposed approach for IT buyers, not an additional finding about Cloudflare or a claim that another provider has the same vulnerability.

Define the workload before reviewing the provider

Write down the job the environment will perform. A developer testing a public example and an agent processing customer records need different approvals, even when both use the same platform.

Record the inputs, outputs, credentials and destinations. Include the files downloaded during execution and any logs you choose to retain. Name the person who owns the business process and the person responsible for configuring the service.

Use a simple boundary statement: "This environment may process these categories of information, contact these systems and retain these outputs for this purpose." If the team cannot complete that sentence, a product demonstration is unlikely to settle the security decision.

Your existing vendor risk assessment should hold the commercial relationship and overall risk decision. Keep the workload-specific evidence alongside it so someone can understand exactly what was approved.

Five cloud sandbox security questions for suppliers

Ask for answers that identify the product, service tier and document version. A general security statement may be useful background, but it needs to connect to the environment you are buying.

An answer can be confidential without being unhelpful. Ask whether a relevant report is available under a confidentiality agreement, or whether the supplier can provide a scoped summary. Record the resulting limitation if evidence remains unavailable.

Avoid marking a question complete merely because a document exists. Note the page or section that answers it, the date checked and any conditions. For example, an assurance report may cover a different service or a period before the feature you intend to use was introduced.

Test what your team controls

Run an approved pilot with synthetic information that has a distinctive, harmless identifier. Exercise the normal create, stop, restart and delete operations, and inspect the outputs and logs available to your account. Compare what you observe with the documented lifecycle.

This checks your configuration and understanding of the service. It cannot establish how the provider sanitises physical storage or prove that another customer cannot access it. Do not attempt to inspect other tenants' resources; provider assurance and authorised security testing address that separate question.

Give the pilot a narrow set of credentials and a defined expiry. Check what the workload can read, change and contact. Ensure the team can withdraw its access without depending on the environment remaining available.

Data handling and action permissions deserve separate review. Your AI sandbox security discussion provides context for assessing agent behaviour; the checklist here focuses on supplier evidence for the information those environments handle.

Worked example: approving an invoice extraction pilot

Consider an illustrative SME testing an agent that extracts invoice fields into an accounting import file. This is a proposed review example, not a customer case study or an observed result.

Begin with fictional invoices and no connection to the live accounting system. Identify the input folder, temporary working files, generated CSV and retained execution logs. Ask the supplier how each relevant copy is handled when the job finishes and when the environment is deleted.

Assign an accounts colleague to check the extracted fields and an IT owner to review access and retention settings. Keep the initial output as a file for human inspection. Any later permission to write directly to the accounting system should be a separate decision.

Suppose the pilot behaves as documented, but the supplier has not explained snapshot retention. Record that specific gap. The business could continue with synthetic data while requesting clarification, or select another service whose evidence meets its requirements. A successful extraction does not resolve the storage question.

This keeps the next step proportionate to the evidence. It also gives the supplier a precise request that can be answered.

Keep a decision record someone else can use

Copy this structure into your normal change or supplier-review system. Keep sensitive credentials out of the record.

Revisit the record when the workload changes. Adding customer information, enabling a new integration or extending retention can change the decision even if the supplier stays the same.

For an existing service, first establish whether a disclosure applies to the product and configuration you use. Follow the provider's current guidance and record its status. Escalate evidence of possible exposure through your incident response plan rather than treating every supplier announcement as proof of a breach.

Put one supplier review on the calendar

Choose the hosted environment that handles your most sensitive approved workload. Give its owner the five questions above and ask for a short record of what is known, what is missing and what decision follows.

The deliverable is an approved use with supporting evidence and clear limits. If you need help structuring that review, discuss your cloud supplier assessment and bring the workload description, current settings and outstanding questions.