It can, if you host the sandbox yourself on a cloud VM and leave the instance metadata service reachable. A command running inside the sandbox may be able to ask the metadata address for the host's role credentials. Requiring IMDSv2, keeping the hop limit low, and blocking the address from the sandbox all reduce that risk.
Why this matters for self-hosted sandboxes
Hosted agent platforms run sandboxes on their own infrastructure and say how they limit access. If you run sandboxes yourself, on VMs or containers inside your own cloud account, the host has an identity, and that identity may be reachable from a process on the box. A coding agent runs arbitrary commands by design, so "can a process on this host reach the metadata address" is a question you must answer.
What AWS documents
AWS describes two versions of its instance metadata service. By default an instance accepts either version, or both, and you can configure it to accept only IMDSv2. IMDSv2 is session oriented: a PUT request returns a token that must be included in later GET requests, and with token use set to required, requests without a valid token get a 401 error. The documentation also says:
- The token is an instance specific key and is rejected on other instances.
- PUT requests are rejected if they contain an X-Forwarded-For header.
- By default the response to the PUT request has a hop limit of 1 at the IP protocol level. A higher hop limit may be needed for container services running on the instance.
The AWS page links to a longer discussion of defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities. Other cloud providers have their own metadata services and settings, so read your provider's documentation.
What the hop limit means for containers
A hop limit of 1 means a response cannot cross an extra network hop. Containers on a bridge network sit behind one, so a default limit can keep container processes from using the token flow, while raising it for compatibility reopens the path. The AWS page notes that raising it may be needed for container services. That is a trade, so make it on purpose.
Controls to apply
| Control | Effect |
|---|---|
| Require IMDSv2 | Removes simple request forgery paths for IMDSv1 |
| Keep hop limit at 1 for sandbox hosts | Makes container access harder |
| Block the metadata address at the sandbox network | Stops the request before it leaves the namespace |
| Give the host role no useful permissions | Limits what a stolen credential does |
| Prefer a runtime with its own network stack | Adds a layer between agent and host |
| Run sandboxes in a separate account | Limits the neighborhood |
A test you can run
- Start a sandbox as the agent would run it.
- From inside, try to reach the metadata address with and without a token.
- Confirm the request fails, and that the host's role has no access to production data even if it succeeded.
- Record the result and repeat after any image, network, or instance change.
Worked example: testing your own sandbox host
An illustrative test plan for a self-hosted sandbox on a cloud VM. Use your own provider's address and commands.
- Launch a sandbox the same way production does, with the same image, network, and user.
- From inside it, make a plain request to the metadata address with no token. Expected result when IMDSv2 is required: an unauthorized error.
- Make the token request, a PUT with a time to live header. Record whether it succeeds. If it does, request the credentials path for the instance role.
- Repeat from a nested container if your sandbox runs containers inside the VM.
- Repeat after applying your controls: required IMDSv2, hop limit of 1, and a network rule blocking the address from the sandbox.
- Record the final result for each step, with date and image version.
If step 3 succeeds before controls and fails after, you have evidence. If it succeeds after controls, stop and fix before running agents.
How the pieces fit
| Control | What it does | Limitation |
|---|---|---|
| Require IMDSv2 | Needs a session token for every request | A local process can still request one |
| Hop limit of 1 | Responses to the token request do not cross an extra hop, which is how AWS describes the default | Raised for container compatibility in some setups |
| Network block to the metadata address | Stops the request from the sandbox namespace | Must cover IPv4 and IPv6 forms |
| Empty instance role | Nothing valuable to steal | Needs to be kept empty |
| Separate account | Contains the damage | Adds operations work |
The AWS page lists both an IPv4 address and an IPv6 address for the service, so a block rule that covers only one leaves a gap.
Beyond instance roles
The same idea applies to any local credential source the host exposes: mounted service account tokens in Kubernetes, credentials files in home directories, helper sockets, and cloud CLI profiles baked into images. For each, ask whether a process in the sandbox can read it.
- Does the image contain cloud CLI configuration?
- Is a service account token mounted into the pod by default?
- Are there Unix sockets for agents, helpers, or the container runtime?
- Are build secrets left in image layers?
Decide what the host role should be able to do
Assume the sandbox can reach it one day. Then give the host role the smallest possible permission: no read access to production data, no ability to create other roles, and no access to other sandboxes. A stolen low value credential is an incident ticket, a stolen high value one is a breach.
Hosted platforms
If you use a vendor hosted platform, the provider is responsible for this host layer. Ask them how they protect the host identity, and ask for it in writing. The question is fair and short.
Where Safeguard fits
Safeguard does not harden your cloud accounts. Its asset discovery and policy features help you see what agents and tools exist in your estate.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and think about the cloud tooling and libraries inside an image, since anything in the image can call the metadata address.
Quick check
Does IMDSv2 make the metadata service safe from a local command?
No. A process on the host that can send the PUT and GET requests can still get a token. IMDSv2 mainly raises the bar for forwarded or forged requests, so also block access from the sandbox.
Do hosted agent platforms expose me to this?
That depends on the platform's own design, which you should ask about. The risk described here applies directly when you host sandboxes in your own cloud account.
Is blocking the metadata address enough on its own?
It stops the direct path from the sandbox network. Pair it with required IMDSv2 and a low privilege host role, so that a missed rule does not become a credential leak.
Sources
- Use the Instance Metadata Service to access instance metadata (AWS documentation)
- Docker Engine security
Last reviewed: 19 October 2026.
