Ask any vendor that runs coding agents in a cloud sandbox how each task is isolated, what the network can reach, how credentials are handled, what the agent may do in git, what is retained, and what evidence they can share. Get answers in writing and compare them with their public documentation.
Isolation
- What isolates one customer's task from another's? Ask whether it is a VM, a microVM, a user-space kernel, or a container, and who patches the host. Vendor docs for isolation technologies state that security depends on configuration, so ask about theirs.
- Is every task a fresh environment? And what persists between sessions?
- What is the maximum session lifetime and what happens on idle?
Network
- What is the default egress policy? Ask for the full list of hosts reachable, including proxies, connectors, and model traffic, not just the editable allowlist.
- Does the firewall cover every process, including tool servers and setup steps? One documented firewall does not directly cover MCP server processes or setup steps.
- Can an admin disable it, and is that change logged?
Secrets and git
- Do real credentials ever enter the sandbox? If they use a proxy, ask for the exceptions.
- Who can read environment variables and setup scripts? One platform notes that anyone who uses an environment can read them.
- What can the agent do in git? Look for single branch push, no merge, no approval, and workflow runs held for approval.
Data and evidence
- What source code is uploaded, what is retained, and for how long? Ask about local repository uploads and session transcripts.
- Who can view a shared session? One platform notes that sessions may contain code and credentials from private repositories, so sharing settings matter.
- What can you give us as evidence? Ask for current documentation, architecture descriptions, and any independent attestations they hold. Do not accept claims of certification without a report you can read.
How to score answers
| Answer quality | Meaning |
|---|---|
| Specific, matches public docs | Good sign |
| Specific but undocumented | Ask for it in the contract or security addendum |
| Vague or marketing language | Treat as unknown |
| "Not applicable" without reason | Ask why |
After the answers
- Map gaps to compensating controls you can apply yourself: scoped tokens, branch protection, held workflows, review.
- Run a pilot on a low sensitivity repository with logging on.
- Test the claims. Try an outbound request to an unlisted host, and see whether a branch protection rule stops a direct push.
- Record the decision and review it when the vendor changes features.
Worked example: turning answers into a decision
An illustrative evaluation of two hypothetical vendors, called A and B, on a few of the questions.
| Question | Vendor A | Vendor B |
|---|---|---|
| Isolation per task | Single use VM, documented | Shared container pool, not documented |
| Default egress | Limited allowlist, documented | Open, can be restricted by admin |
| Secrets in sandbox | Credential proxy, exceptions listed | Environment variables only |
| Git permissions | Single branch, no merge | Admin token required |
| Retention | Documented with options | Not stated |
| Evidence | Documentation and an architecture note | Marketing page |
Vendor A is not perfect, but its answers are specific and match published documentation. Vendor B's answers are gaps. You can still proceed with B, but only with compensating controls and a narrower scope, such as public repositories only.
Turning gaps into compensating controls
| Gap | Compensating control |
|---|---|
| No fresh environment per task | Do not use for sensitive repositories, wipe procedures required |
| Open egress | Put a proxy in front, or restrict at your network |
| Secrets as environment variables | Short lived, narrow tokens, setup only |
| Broad git token | Use a dedicated machine identity with repository limits and branch protection |
| Unknown retention | Limit content sent, ask for terms in the contract |
| No evidence | Run your own tests and keep the results |
Run your own tests during a pilot
- Attempt a request to a host that should be blocked.
- Attempt a direct push to a protected branch.
- Check whether an environment variable you set is readable by the agent.
- Ask the agent to print the list of tools and permissions it has.
- Check what appears in the session record afterward.
- Share a session within the permitted scope and see who can open it.
Write down results. If the vendor changes the product, repeat them.
Contract and procurement notes
- Ask that security descriptions in the proposal be attached to the agreement.
- Ask for notice of material changes to isolation, retention, and network defaults.
- Ask about incident notification and what you will receive.
- Ask which subprocessors handle code and transcripts.
- Do not accept claims of certifications without a report you can read, and take care to describe any report accurately in your own materials.
Who should be in the room
Security, the platform or developer productivity owner, legal or privacy for retention terms, and an engineering lead who will use the tool. Each asks different questions, and the answers are stronger when all four hear them.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you keep the answers and tests in one place, and its policies and gates apply to what agents propose. We do not claim any certification beyond what is publicly stated.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and see how controls are mapped to a framework, which is a useful way to organize vendor answers.
Quick check
Is a vendor's SOC 2 report enough to approve a sandbox?
It helps, but read the scope and period, and still test egress, secrets, and git controls yourself.
Should the questions go in a security questionnaire?
Yes, and in the contract where possible, so answers are tied to commitments.
What if the vendor will not answer in writing?
Treat unanswered questions as unknown risk. Narrow the scope, add compensating controls, and revisit once they commit to answers.
Sources
- Use Claude Code in the cloud (Anthropic documentation)
- Customize the Copilot cloud agent firewall (GitHub Docs)
- Risks and mitigations for Copilot cloud agent (GitHub Docs)
- What is gVisor?
- Firecracker microVM project
Last reviewed: 19 October 2026.
