Skip to main content

What You’ll Learn

  • That 169.254.169.254 is blocked by default on every Declaw sandbox — no opt-in required
  • Verifying the metadata endpoint is unreachable (SSRF protection)
  • Verifying normal internet access still works in the same sandbox
  • How to add an explicit deny_out rule as belt-and-suspenders documentation of intent
  • Understanding why blocking the metadata service matters

Why This Matters

In cloud environments (AWS, GCP, Azure), the instance metadata service at 169.254.169.254 can expose:
  • IAM credentials and access tokens
  • Instance identity documents
  • User data scripts (which may contain secrets)
  • Network configuration details
An SSRF vulnerability could allow untrusted code inside a sandbox to reach this endpoint and steal credentials. Declaw blocks 169.254.169.254 by default — it is a hardcoded rule applied to every sandbox, so the metadata endpoint is never reachable even with no network policy set. Adding 169.254.169.254/32 to deny_out is therefore redundant; the example below uses it to make the intent explicit and to verify the default protection holds, not to provide it.

Prerequisites

This example is available in Python. TypeScript version coming soon.

Code Walkthrough

The metadata IP is already blocked by default. The explicit deny_out rule below documents that intent and lets you assert it in tests — it does not change the behavior:
The metadata test script tries to open a TCP connection to port 80 on the metadata IP:
Test 1 — metadata endpoint should be blocked:
Test 2 — normal internet should still work (only metadata is denied):

Expected Output