Skip to main content

Network Policy

Controls where your agent can make network requests and blocks access to internal resources.

note

This guard is primarily relevant to administrators and deployments where agents make network requests — for example, using web search tools, calling APIs, or connecting to databases. If your agents only handle text conversations, this guard runs silently in the background.

What It Does​

When your agent makes network requests — calling APIs, fetching data, accessing services — Network Policy makes sure those requests go where they should and nowhere else. It blocks access to internal network resources, private infrastructure, and cloud metadata services that should never be reachable from an AI agent.

The guard also detects sophisticated attacks where a domain that initially appears safe actually redirects to an internal address. This means an attacker can't simply disguise a dangerous destination behind a legitimate-looking URL.

Think of it as a network firewall built specifically for AI agent traffic. It understands the unique ways agents interact with the network and applies rules designed to keep that traffic safe.

Why It Matters​

A common attack technique is tricking an agent into making requests to internal services on the attacker's behalf. This can expose sensitive data, access internal APIs, or reach cloud infrastructure that should be off-limits. Without network-level controls, your agent could be used as a bridge into parts of your system that were never meant to be exposed.

Network Policy is especially important in environments where agents have access to tools that make HTTP requests, query databases, or interact with external services.

What Gets Caught​

  • Requests to private networks — attempts to reach internal IP addresses (e.g., 10.x.x.x, 192.168.x.x, 172.16.x.x) or localhost
  • Cloud metadata access — requests targeting cloud provider metadata endpoints that could expose infrastructure credentials
  • Internal hostnames — requests to .local, .internal, or similar internal-only domains
  • DNS rebinding — a technique where a domain resolves to different IP addresses at different times, initially appearing safe but later redirecting to an internal address to bypass security checks

What won't trigger it: Requests to public APIs and websites. If your agent needs to reach a specific internal or external service, add it to the exemptions with allowedHosts.

Example​

Scenario

An agent is using a web search tool and a crafted result tricks it into fetching http://169.254.169.254/latest/meta-data/ — the cloud metadata endpoint that could expose infrastructure credentials. Network Policy detects that the request targets a cloud metadata address and blocks it. The audit log shows a metadata_access event with the destination URL and the tool that made the request. The agent's web search continues normally for public URLs, but requests to internal or sensitive destinations are denied.

Settings​

SettingWhat It Controls
Loopback OnlyWhether to restrict the agent to local network binding
SSRF ProtectionWhether to block SSRF attempts (where a server is tricked into making requests to unintended internal destinations)
DNS ProtectionWhether to detect domain-based attacks that resolve to internal addresses
ExemptionsAllow specific skills to reach approved external hosts

How It Responds​

Unauthorized requests are blocked. There are no modes — if a destination is restricted, the request is denied. Blocked requests are logged as security events.

If This Guard Blocks You​

  1. Check the audit log. Navigate to Security > Audit Log in the CrabShack dashboard. Filter by Network Policy to find the relevant event. Click on the event row to expand it and see details including which skill and channel triggered it, the session key, and additional context.

  2. Understand the detection. The audit log shows the blocked destination and the reason — private_network (request to an internal IP address like 10.x.x.x or 192.168.x.x), metadata_access (cloud provider metadata endpoint), internal_hostname (request to a .local or .internal domain), or dns_rebinding (a technique where a domain resolves to different IPs at different times to bypass checks — the domain initially appeared safe but resolved to an internal address). If a skill legitimately needs to reach a specific internal or external host, create an exemption with allowedHosts for that skill.

  3. Adjust if needed. Create an exemption with allowedHosts and allowedPorts for skills that need to reach specific hosts. This guard doesn't have modes — requests are either allowed or blocked. See the Configuration page for details.

tip

Prefer creating a targeted exemption for a specific skill or channel over disabling the guard entirely. If you're seeing frequent false positives, a suppression lets you silence a specific detection label temporarily while you refine your settings.

Default Behavior​

SSRF protection and DNS protection are enabled. Requests to private and internal addresses are blocked automatically.

  • Tool Gate — controls which tools can make requests; Network Policy controls where those requests can go.
  • MCP Hardening — controls which external tool servers your agent connects to, complementing Network Policy's control over where requests are sent.