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

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.

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.

   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