Docs/Core concepts/Domain policy

Domain policy

Agents consume autonomously, so guardrails must be machine-enforced. Domain policy controls which targets a key may reach — enforced in the gateway, on every connection, before any traffic flows.

Two layers of policy

Platform blocklist — non-negotiable, applies to every key. High-risk categories (banking, government and healthcare login portals, and targets prohibited by our Acceptable Use Policy) are refused at the gateway. Visible read-only in your console.
Per-key allow/deny lists — your own guardrails. Pin a key to an allowlist so a runaway agent can only reach the domains its task needs, or deny specific domains while leaving the rest open.

How matching works

For HTTPS the gateway matches on the connection's target domain (SNI); for plaintext HTTP, on the request host. Wildcards (*.example.com) are supported. Denied connections fail fast with a machine-readable error so the agent can react instead of hanging.

Why this exists

Compliance as a product feature: it protects the shared IP pool reputation every customer depends on, and it is what makes autonomous agents safe to run with a real budget. Combined with budget caps and rate quotas, a misbehaving agent is contained — not a billing incident.

Policy checks happen on the request path and add no measurable latency; they never depend on asynchronous reconciliation.

Next steps

Acceptable Use Policy

The platform-wide prohibited-use list.

Billing model

Budget caps — the other half of the guardrails.