Skip to content
Quayside

Network egress

For Quayside to enforce — not just observe — you need to make sure agents can only reach LLM providers through the proxy. This is a deployment concern, not a Quayside feature.

The chain

   Agent (Claude SDK / your code)
       │
       │  ANTHROPIC_BASE_URL  → quayside
       ▼
   Quayside proxy ──── api.anthropic.com
       │
       └─ x-api-key validated
       └─ identity stamped on every audit row

If the agent goes around Quayside — by setting ANTHROPIC_BASE_URL back to api.anthropic.com and using its own provider key — it bypasses everything. To prevent that, three layers stack:

Layer 1: don’t issue users provider API keys

Engineers don’t get sk-ant-... keys. They get Quayside tokens (qsk_...). The provider key is held by the Quayside service.

This makes the easy bypass impossible — you can’t set ANTHROPIC_API_KEY to something you don’t have.

Layer 2: point harnesses at the proxy

Configure the standard env vars system-wide via MDM, dotfiles, or shell init:

Terminal window
export ANTHROPIC_BASE_URL=https://quayside.internal/api/v1/proxy/anthropic
export ANTHROPIC_API_KEY="$(cat ~/.config/quayside/token.json | jq -r .api_key)"

For Claude Code specifically, this is how it picks up Quayside automatically. Most LLM SDKs respect the same env-var convention.

Layer 3: network egress blocks

This is the real enforcement.

In your firewall / VPC egress policy, block outbound TCP/443 to LLM provider hosts for everything except the Quayside service:

Block outbound TCP/443 to:
  api.anthropic.com
  api.openai.com
  generativelanguage.googleapis.com
  api.cohere.ai
  ... (other provider hosts)


Allow outbound from <quayside-service-IP> to those hosts.

Without this, a determined user can always go around. With it, the only path to an LLM provider is through Quayside, and Quayside enforces.

What this isn’t

It isn’t a Quayside feature. We don’t ship a firewall. Quayside slots into your existing network egress controls (Zscaler, Symantec, AWS security groups, ingress/egress policies on your Kubernetes cluster).

If your org doesn’t have egress controls today, Quayside is still useful — you get the audit trail, the registry, and the policy enforcement for everyone who agrees to use it. You just don’t have an absolute guarantee that someone won’t bypass.

Edge cases

  • claude.ai web UI — cookie-based auth, no env vars. Only network egress controls help here.
  • IDE plugins with hardcoded endpoints — some refuse to read env vars. Document them; recommend network controls or replacement plugins.
  • Air-gapped LLMs — if you self-host the model too, the egress concern is moot. Just point the agent’s ANTHROPIC_BASE_URL at Quayside, which forwards to your self-hosted model.
  • MCP servers — each MCP server is its own process. Configure them to talk to Quayside’s proxy if they make LLM calls.

Verifying

Once the egress controls are live, test from a representative engineer’s laptop:

Terminal window
# This should fail (network egress blocks api.anthropic.com directly)
unset ANTHROPIC_BASE_URL
curl https://api.anthropic.com/v1/messages -H "x-api-key: bogus"


# This should succeed via Quayside
curl http://quayside.internal/api/v1/proxy/anthropic/v1/messages \
  -H "x-api-key: $(quayside login -p you@example.com -c your/class --json | jq -r .api_key)" \
  ...

If the first succeeds and the second fails, your firewall isn’t doing what you think.