Skip to main content

HTTP Egress Proxy

Identity-aware control over every API call your agents make — not just their MCP tools.

The Permit MCP Gateway governs an agent's MCP tool calls. The HTTP Egress Proxy extends that same governance to an agent's arbitrary outbound HTTP and HTTPS traffic — the REST APIs, webhooks, and third-party services it calls directly, outside of MCP.

When an agent's runtime is pointed at the proxy, every outbound request is authenticated, matched against the workflow bound to its token, authorized, optionally routed for human approval, and audited — before it ever reaches the upstream API. Credentials for those upstream APIs are stored in the gateway and injected server-side, so your agents never hold the secrets they use.

Availability

The HTTP Egress Proxy is a newer capability and is enabled per environment. If you don't see the CLIs / APIs section in your dashboard, contact us to have it turned on for your account.

Why an egress proxy​

MCP governs the tools you import into the gateway. But a modern agent does far more than call MCP tools — it calls Stripe, GitHub, internal microservices, and any HTTP API a developer hands it. Without a control point on that traffic:

  • Secrets live in the agent. API keys get baked into prompts, env files, and agent memory, where they can leak or be exfiltrated by prompt injection.
  • There's no allow-list. A compromised or confused agent can call any host on the internet, including internal metadata endpoints (SSRF).
  • There's no record. You can't answer "which agent called which API, on whose behalf, and was it allowed?"

The HTTP Egress Proxy puts the same deny-by-default, identity-aware control plane you already use for MCP in front of all of that traffic. You define what an agent may reach as an API workflow — a named bundle of allowed domains and rules — and bind each agent token to one workflow.

What it enforces​

CapabilityWhat it gives you
Deny by defaultNo outbound request is allowed until a workflow rule permits its destination — by domain (for HTTPS) and, on plain HTTP or intercepted HTTPS, by path and method too.
API workflowsGroup the domains an agent may reach and the rules that govern them — matched by domain, path, and HTTP method, each carrying a required trust level. Every agent token is bound to one workflow.
Server-side credentialsUpstream API keys, tokens, and OAuth connections are stored in the gateway (encrypted at rest when the KMS vault is enabled) and injected into requests on the way out. The agent never sees them.
Human consent & trust ceilingsJust like MCP, a human can delegate egress access to an agent within an admin-defined trust ceiling — and revoke it at any time.
Human-in-the-loopHigh-risk requests can be routed to a human for approval before they're forwarded (optional, per host).
SSRF protectionInternal IP literals and known cluster-internal hostnames are rejected before any DNS lookup; a hostname that resolves into a private, loopback, link-local, or metadata range is rejected after resolution and before any connection.
Response scrubbingInjected secrets are stripped (best-effort, on by default) from upstream responses before they reach the agent.
Rate limitingPer-agent request budgets — by host and by domain — shed floods and contain runaway agents.
Full audit trailEvery decision — who, what host, which agent, allow or deny — is logged.

Two planes: configure once, govern continuously​

The feature has a control plane (configuration you set up, as an operator) and a data plane (live traffic your agents generate). They are separate surfaces with separate credentials.

  • Control plane — you enable the proxy for a host, define workflows, store credentials, and mint agent tokens. You do this in the dashboard or with the asg CLI (workflows are authored in the dashboard). It writes policy; it never carries live agent traffic.
  • Data plane — your agent's runtime is configured with standard HTTP_PROXY / HTTPS_PROXY environment variables pointing at the gateway, plus a short-lived access token. From then on, the agent's normal HTTP libraries route through the proxy automatically. See Connecting Agents.

How a request is governed​

Every outbound request runs through the same ordered set of checks. Cheap, fail-closed checks run first, and a denied request is never even resolved to an IP or connected — no traffic leaks to a host you didn't allow.

  1. Authenticate — the request must carry a valid, short-lived proxy access token bound to one of your workflows.
  2. SSRF guard — internal, loopback, link-local, and cloud-metadata targets are rejected immediately.
  3. Proxy enabled? — the host must have the proxy turned on.
  4. Workflow match — the request's host, path, and method are matched against the token's workflow. No matching rule means deny. (HTTPS in the default passthrough mode is matched on domain only — against a rule with method class all and no path, since the tunnel's inner path and method aren't visible. Path and method matching apply to plain HTTP and to HTTPS in intercept mode.)
  5. Rate limit — per-agent, per-host budgets are checked.
  6. Authorize — the matched rule is checked against your Permit policy: the agent must hold a role that covers the rule's required trust.
  7. Trust ceiling — for human-delegated agents, the effective access is capped at the trust level that human granted for the workflow.
  8. Forward — the matched credential is injected, the request is sent, and the response is scrubbed of any injected secret before returning to the agent. (Injection and scrubbing apply to plain HTTP and to HTTPS in intercept mode; a passthrough tunnel is forwarded opaquely.)

For the detail behind each gate, see Authorization & Trust and Security.

Start here​

  1. Quick Start — enable the proxy, define a workflow, store a credential, and route an agent through it.
  2. The asg CLI — install and use the command-line tool that drives the control plane.
  3. Workflows & Rules — the workflow model: domains, paths, methods, and trust levels.
  4. Credentials & Connections — store upstream secrets and connect OAuth providers.
  5. Authorization & Trust — how rules, Permit policy, and human consent compose.
  6. Connecting Agents — wire your agent runtime, Docker, or Kubernetes to the proxy.
  7. Security — SSRF protection, credential isolation, response scrubbing, TLS modes, and rate limits.

Contents