# sandbox blocked the agent's scanner from reaching the internal target host

## TL;DR
Sandboxes deny egress by default, so the scanner's connection to the internal target dies at the sandbox boundary. That is the sandbox doing its job. Add the specific target host and port to the sandbox's egress allowlist through the approved change path (nothing wider), verify DNS for the target resolves inside the sandbox, and re-run the scan.

```text
sandbox blocked the agent's scanner from reaching the internal target host
```

## Use this when
- An agent's scanner cannot reach an internal target from inside its sandbox
- The same scan works from outside the sandbox but fails inside it
- You see connection timeouts or DNS failures only in the sandboxed run
- You are setting up a new scan target for a sandboxed agent

## Not for this skill when
- The target's own firewall blocks the scanner (that is a target-side rule, fix it there)
- You are choosing a scanner tool
- You are choosing a sandbox product

## Steps
1. Prove the block is the sandbox: run a basic connection test to the target from inside the sandbox and from outside it.
   ```sh
   getent hosts target-host.example.com
   curl -s -o /dev/null -w "%{http_code}" https://target-host.example.com:8443/health
   ```
   Expected: it fails inside and works outside, which isolates the sandbox as the cause.
2. Check the sandbox's egress policy for an entry covering the target host and port.
   Expected: no entry found, confirming the allowlist gap.
3. Add the target host and port, and only that, to the egress allowlist through the approved change path.
   Expected: the entry is present and scoped to the one host and port.
4. Verify DNS for the target resolves inside the sandbox, then re-run the scan.
   Expected: the scan reaches the target and produces results.

### Variant: agent sandbox cannot reach internal host
Same fix. Start with the DNS check: sandboxes often use a different resolver, and a DNS failure looks exactly like a blocked connection.

### Variant: egress blocked scanner target host
If the policy change needs approval, file it with the scan window attached; approvers move faster when the exception has an expiry.

### Variant: sandbox network policy blocked security scan
For Kubernetes-style sandboxes, the fix is a network policy egress rule to the target's IP and port; for VM sandboxes it is the security group or firewall rule. Same principle, different control.

## Why this happens
Deny-by-default egress is the point of a sandbox: the agent cannot reach anything it was not explicitly allowed to reach. Scanners need explicit network exceptions for internal targets, and the scan was scheduled before the exception existed.

## Edge cases and pitfalls
- Allowlist the specific port, not all ports; a host-wide opening defeats the sandbox.
- DNS inside the sandbox may resolve differently; verify with the in-sandbox resolver, not your laptop.
- The target may also need to allowlist the sandbox's egress IP; the path has two ends.
- Time-box the exception to the scan window and remove it after; a permanent hole for a one-off scan is how sandboxes rot.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9UQjvfnVGLGclHaIxFFVUA