diff --git a/docs/permit-mcp-gateway/http-egress-proxy/authorization.mdx b/docs/permit-mcp-gateway/http-egress-proxy/authorization.mdx
new file mode 100644
index 00000000..1b61ab1c
--- /dev/null
+++ b/docs/permit-mcp-gateway/http-egress-proxy/authorization.mdx
@@ -0,0 +1,85 @@
+---
+title: Authorization & Trust
+sidebar_label: Authorization & Trust
+description: How egress rules, Permit.io policy, and human consent compose — including per-human trust ceilings that cap how much access a person can delegate to an agent.
+sidebar_position: 5
+---
+
+# Authorization & Trust
+
+An allowed outbound request passes through **two independent gates**. Both must say yes. This mirrors how the gateway authorizes MCP tool calls, so the same mental model — and the same Permit policy environment — governs both planes.
+
+## The two gates
+
+```mermaid
+flowchart TB
+    Req["Outbound request"]
+    Rule{"1. Egress rule<br/>host / path / method"}
+    Permit{"2. Permit policy<br/>agent's role on the host"}
+    Ceiling{"Trust ceiling<br/>(delegated agents)"}
+    Allow["Forwarded"]
+    Deny["Denied"]
+
+    Req --> Rule
+    Rule -->|"no match or block"| Deny
+    Rule -->|"allow"| Permit
+    Permit -->|"deny"| Deny
+    Permit -->|"allow"| Ceiling
+    Ceiling -->|"over ceiling"| Deny
+    Ceiling -->|"within ceiling"| Allow
+```
+
+### Gate 1 — Egress rules
+
+The [egress rules](./egress-rules) you author are the coarse "is this host/path/method even on the menu" check. A request with no matching `allow` rule is denied before any policy evaluation. This is the operator-controlled allow-list.
+
+### Gate 2 — Permit.io policy
+
+For requests that an `allow` rule permits, the gateway then asks your **Permit.io** policy whether *this agent* is allowed to perform *this kind of action* on *this host*. The request's method class maps to an action (read, write, delete, and so on), and the host becomes a Permit resource. Because every gateway host maps 1:1 to a Permit environment, you manage these policies in the same place as your MCP policies — see [Permit.io Integration](/permit-mcp-gateway/permit-integration).
+
+This split means an operator can broadly allow a host at the proxy while your central policy still decides, per agent, what that host's access actually permits.
+
+## Human consent and trust ceilings
+
+Agents usually act **on behalf of a human**. The proxy supports the same delegation-with-consent model the gateway uses for MCP: a person explicitly authorizes an agent to make egress calls for them, and the access an agent gets through that person is capped by a **trust ceiling**.
+
+### Trust ceilings
+
+An admin sets, per human and per host, the **maximum** trust level that person is allowed to delegate — `low`, `medium`, or `high`. When a human consents to an agent, the access that agent receives is the **lesser** of what the human grants and the admin-defined ceiling. A person can never delegate more than their ceiling allows.
+
+This has an important security property: an agent that acts for **several** humans does **not** get to combine their ceilings. Each human caps their own delegation independently, so one person's grant can't be used to escalate another's.
+
+### Human consent
+
+To have a human delegate egress access to an agent, run the consent flow:
+
+```bash
+asg proxy authorize <agent-client-id> --host api.github.com
+```
+
+This opens a browser where the human signs in and chooses what to allow:
+
+1. **Sign in** — the human authenticates.
+2. **Review the hosts** — the agent is requesting egress to specific hosts.
+3. **Choose an access level** — defaulting to least privilege, and capped at the admin's ceiling for that human and host.
+4. **Approve** — a short-lived, human-bound token is issued for the agent.
+
+Pass multiple `--host` flags to request several hosts at once. The optional `--trust low|medium|high` flag lets the human (or the operator preparing the request) propose a lower cap than the ceiling; omit it to default to least privilege.
+
+The result is a token whose access is bound to that specific human's consent — and which the human can revoke.
+
+### Revocation
+
+A human can revoke an agent's delegated access at any time from their account. Revocation is enforced **immediately**: in-flight and subsequent requests using a revoked delegation are denied, not just future token issuance. This is the egress equivalent of revoking an MCP consent.
+
+## How automated agents differ
+
+Not every agent acts for a human. A CI job or backend service can be issued a token directly with [`asg proxy token create`](./quickstart#4-mint-an-agent-access-token). Such a token isn't bound to a human, so the per-human trust ceiling doesn't apply — its access is governed purely by the egress rules and the agent's own Permit policy. Use direct tokens for machine-to-machine automation, and the consent flow whenever a real person is accountable for what the agent does.
+
+---
+
+## What's next
+
+- [**Egress Rules**](./egress-rules) — the operator allow-list that forms the first gate.
+- [**Permit.io Integration**](/permit-mcp-gateway/permit-integration) — the policy model behind the second gate.
+- [**Security**](./security) — the protections that wrap both gates.
diff --git a/docs/permit-mcp-gateway/http-egress-proxy/cli.mdx b/docs/permit-mcp-gateway/http-egress-proxy/cli.mdx
new file mode 100644
index 00000000..beba333e
--- /dev/null
+++ b/docs/permit-mcp-gateway/http-egress-proxy/cli.mdx
@@ -0,0 +1,110 @@
+---
+title: The asg CLI
+sidebar_label: asg CLI
+description: Install and use the asg command-line tool — the operator's front door for enabling the HTTP Egress Proxy, managing rules and credentials, minting agent tokens, and wiring agents into the proxy.
+sidebar_position: 2
+---
+
+# The `asg` CLI
+
+`asg` is the command-line tool for managing the Permit MCP Gateway, including the entire HTTP Egress Proxy control plane. Anything you can do in the **Proxy** section of the [dashboard](https://app.agent.security) — enable the proxy, manage rules and credentials, mint tokens, run diagnostics — you can do with `asg`, scripted and CI-friendly.
+
+The CLI is the operator and automation surface. End users who simply delegate access to an agent normally do that through the browser consent flow, not the CLI.
+
+## Install
+
+```bash
+npm install -g @permit-io/agent-security-cli
+```
+
+Verify the install:
+
+```bash
+asg --help
+asg proxy --help
+```
+
+## Configure
+
+`asg` resolves settings in priority order: environment variables, then a config file at `~/.agent-security/`, then built-in defaults.
+
+```bash
+# Point at your gateway and store an admin token (saved with restrictive permissions).
+asg config set gateway-url https://gateway.example.com
+asg login --token <admin-token>
+
+# Verify the token against the gateway.
+asg whoami
+```
+
+You can also supply settings through environment variables, which is the preferred approach in CI:
+
+| Variable | Purpose |
+| --- | --- |
+| `AGENT_SECURITY_API_KEY` | Admin token used to authenticate control-plane commands. |
+| `AGENT_SECURITY_GATEWAY_URL` | Your gateway's admin URL. |
+| `AGENT_SECURITY_SUBDOMAIN` | Default host subdomain, so you can omit it from each command. |
+| `AGENT_SECURITY_CONSENT_URL` | Consent origin used by `asg proxy authorize` (usually auto-derived). |
+| `AGENT_SECURITY_PROXY_TOKEN_FILE` | Path to the agent's proxy token file (set by `asg proxy env`). |
+
+:::warning Treat the admin token as a high-value secret
+Prefer the interactive prompt or `AGENT_SECURITY_API_KEY` over passing the token as a `--token` flag — command-line flags are visible to other users on the machine via the process list. The CLI scrubs secret-shaped strings from its own error output, but the process list is outside its control.
+:::
+
+## Output and exit codes
+
+Every command supports machine-readable output so agents and CI can drive it deterministically:
+
+```bash
+asg proxy rules list acme --json --quiet
+```
+
+- `--json` emits structured JSON to stdout.
+- `--quiet` drops decorative output (spinners, hints).
+- `--yes` accepts confirmation prompts non-interactively.
+
+Exit codes are stable:
+
+| Code | Meaning |
+| --- | --- |
+| `0` | Success |
+| `1` | User error — bad input, missing token, cancelled prompt, or a human-denied approval |
+| `2` | Server error — gateway unreachable, 5xx, or network failure |
+
+## The `asg proxy` command tree
+
+| Command | What it does |
+| --- | --- |
+| `asg proxy config <host> --enable\|--disable` | Turn proxy mode on or off for a host. |
+| `asg proxy rules list\|add\|update\|delete\|reorder` | Manage egress rules. See [Egress Rules](./egress-rules). |
+| `asg proxy credentials list\|create\|update\|delete` | Manage stored upstream secrets (write-only). See [Credentials](./credentials). |
+| `asg proxy connect <provider>` | Connect an OAuth provider (`github_app`, `notion`, `google`, `atlassian`) and store the resulting credential. |
+| `asg proxy token create <host> --client-id <id>` | Mint a short-lived agent proxy token (`--out <file>` writes it securely). |
+| `asg proxy authorize <client_id>` | Run the browser consent flow so a human can delegate access to an agent within a trust ceiling. |
+| `asg proxy preset list\|apply` | Browse and apply preset rule + credential packs for common providers. |
+| `asg proxy env <host>` | Print the `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY` environment for the current shell. |
+| `asg proxy container-config <host>` | Emit Docker, Docker Compose, or Kubernetes ConfigMap bootstrap config. |
+| `asg proxy ca status\|download\|rotate\|trust-shell` | Manage the per-host TLS-interception certificate authority. See [Connecting Agents](./connecting-agents#https-interception). |
+| `asg proxy doctor <host>` | Diagnose proxy setup end to end. |
+
+Run `asg proxy <command> --help` for the full flag list of any command.
+
+## Passing the host subdomain
+
+Most commands take the host subdomain as a positional argument (e.g. `asg proxy config acme`). If you've set a default with `asg config set subdomain acme` (or `AGENT_SECURITY_SUBDOMAIN`), you can omit it. Commands that already take another positional accept the host as a `--subdomain` flag instead.
+
+## Shell completions
+
+Enable tab-completion for your shell:
+
+```bash
+asg completion --shell zsh >> ~/.zshrc    # or: --shell bash >> ~/.bashrc
+```
+
+---
+
+## What's next
+
+- [**Egress Rules**](./egress-rules) — the rule model in depth.
+- [**Credentials & Connections**](./credentials) — static secrets, OAuth connections, and request signing.
+- [**Connecting Agents**](./connecting-agents) — `asg proxy env`, `container-config`, and `doctor` in context.
diff --git a/docs/permit-mcp-gateway/http-egress-proxy/connecting-agents.mdx b/docs/permit-mcp-gateway/http-egress-proxy/connecting-agents.mdx
new file mode 100644
index 00000000..e06b84cf
--- /dev/null
+++ b/docs/permit-mcp-gateway/http-egress-proxy/connecting-agents.mdx
@@ -0,0 +1,96 @@
+---
+title: Connecting Agents
+sidebar_label: Connecting Agents
+description: Route an agent's outbound traffic through the HTTP Egress Proxy — shell, Docker, and Kubernetes setup, the proxy access token, HTTPS interception, and the doctor diagnostic.
+sidebar_position: 6
+---
+
+# Connecting Agents
+
+The proxy uses the standard `HTTP_PROXY` / `HTTPS_PROXY` convention, so most HTTP client libraries route through it automatically once the environment is set. Connecting an agent has two parts: **the environment variables** that point traffic at the gateway, and **a proxy access token** the agent presents to authenticate.
+
+## The pieces
+
+| Piece | What it is |
+| --- | --- |
+| `HTTP_PROXY` / `HTTPS_PROXY` | Point your agent's outbound HTTP and HTTPS at the gateway. |
+| `NO_PROXY` | Hosts that should bypass the proxy (e.g. localhost). |
+| Proxy access token | A short-lived token the agent presents to the proxy. Minted with [`asg proxy token create`](./quickstart#4-mint-an-agent-access-token) or the [consent flow](./authorization#human-consent), and referenced via a token file. |
+
+You rarely set these by hand — `asg proxy env` and `asg proxy container-config` generate them for you.
+
+## Shell / local process
+
+```bash
+eval "$(asg proxy env acme)"
+```
+
+This exports `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`, and the path to the agent's token file into the current shell. Any process launched from that shell now routes its outbound traffic through the proxy. Mint the token first (step 4 of the [Quick Start](./quickstart)).
+
+## Docker and Kubernetes
+
+Generate ready-to-use container configuration:
+
+```bash
+# Docker env file or Compose snippet.
+asg proxy container-config acme --format docker-env
+asg proxy container-config acme --format docker-compose
+
+# Kubernetes ConfigMap.
+asg proxy container-config acme --format k8s-configmap
+```
+
+Mount or reference the emitted configuration in your agent's container so the proxy variables are present in its environment. Supply the proxy token through your platform's normal secret mechanism (a mounted file or secret), and point `AGENT_SECURITY_PROXY_TOKEN_FILE` at it.
+
+## HTTPS interception
+
+By default the proxy handles HTTPS in **passthrough** mode: it authenticates and applies host-level rules, but the encrypted tunnel is forwarded opaquely — the proxy does not see the request path or body, and it can't inject a credential or scrub the response inside the tunnel.
+
+To apply **full** governance to HTTPS — path-level rules, credential injection, response scrubbing, and approval gates inside the encrypted connection — switch the relevant rule to **intercept** mode. You set a rule's TLS mode in the [dashboard](https://app.agent.security) rule editor (**Proxy → Rules**, edit the rule, set **TLS mode** to **Intercept**); the CLI creates rules in passthrough mode.
+
+In intercept mode the proxy terminates the agent's TLS using a **certificate authority issued for your host** and re-applies every check to the decrypted request. For your agent to trust those connections, it must trust that CA certificate — manage it with the CLI:
+
+```bash
+# Inspect your host's interception CA.
+asg proxy ca status acme
+
+# Download the CA certificate to install in your agent's trust store.
+asg proxy ca download acme --output ./agent-security-ca.pem
+
+# Print a shell snippet that points common tools at the CA.
+asg proxy ca trust-shell acme
+
+# Rotate the CA, keeping the previous one valid during a grace window.
+asg proxy ca rotate acme --grace-days 7
+```
+
+:::note Choosing a mode
+Use **passthrough** when host-level control is enough, or for very large uploads, downloads, and long-lived streaming connections. Use **intercept** when you need path-level rules, credential injection, or response scrubbing on HTTPS traffic. Mode is per rule, so you can mix the two across your rule set.
+:::
+
+## Diagnose with `doctor`
+
+When something isn't connecting, run the built-in diagnostic:
+
+```bash
+asg proxy doctor acme
+```
+
+`doctor` checks, end to end:
+
+- Gateway reachability
+- Whether the proxy is enabled for the host
+- How many rules and credentials are configured
+- Your local proxy environment variables
+- The interception CA's status and expiry, and whether your environment trusts it
+- The token file's permissions and the token's expiry
+
+Each check reports a clear pass/fail with a suggested fix, so it's the first thing to run whenever an agent's traffic isn't behaving.
+
+---
+
+## What's next
+
+- [**Quick Start**](./quickstart) — the end-to-end setup these commands fit into.
+- [**Security**](./security) — what the proxy enforces on the traffic you route through it.
+- [**The `asg` CLI**](./cli) — full command reference.
diff --git a/docs/permit-mcp-gateway/http-egress-proxy/credentials.mdx b/docs/permit-mcp-gateway/http-egress-proxy/credentials.mdx
new file mode 100644
index 00000000..8efa76db
--- /dev/null
+++ b/docs/permit-mcp-gateway/http-egress-proxy/credentials.mdx
@@ -0,0 +1,99 @@
+---
+title: Credentials & Connections
+sidebar_label: Credentials & Connections
+description: Store upstream API secrets in the gateway and inject them into outbound requests server-side — static keys, OAuth connections, and AWS request signing — so your agents never hold the credentials they use.
+sidebar_position: 4
+---
+
+# Credentials & Connections
+
+The proxy can attach an upstream API's credential to outbound requests **server-side**, so your agents call third-party APIs without ever holding the keys. You store the secret once in the gateway; an [egress rule](./egress-rules) names it; the proxy injects it on the way out and [scrubs it](./security#response-scrubbing) from the response on the way back.
+
+This is one of the proxy's most important properties: **the secret never leaves the gateway**. It isn't in the agent's prompt, environment, or memory, so it can't leak through logs or be exfiltrated by prompt injection.
+
+## Credentials are write-only
+
+Once stored, a secret can never be read back through the API, the CLI, or the dashboard — only **overwritten** or **deleted**. Listing credentials shows their names, target hosts, and whether a secret is set — never the secret value itself. This holds for everyone, including admins.
+
+## Static credentials
+
+A static credential is a fixed secret (an API key, bearer token, or basic-auth password) that you supply. You choose **how** it's injected:
+
+| Injection method | What it does |
+| --- | --- |
+| **`header`** | Adds a request header. You set the header name and a value template containing `{secret}` (e.g. `Authorization: Bearer {secret}`). |
+| **`query`** | Adds a query-string parameter. You set the parameter name. |
+| **`basic_auth`** | Sets HTTP Basic authentication from a username plus the stored secret. |
+
+```bash
+# Bearer token in an Authorization header.
+asg proxy credentials create stripe acme \
+  --host api.stripe.com \
+  --injection header \
+  --header-name Authorization \
+  --value-template "Bearer {secret}" \
+  --secret-file ./stripe.key
+
+# API key as a query parameter.
+asg proxy credentials create weather acme \
+  --host api.weather.example \
+  --injection query \
+  --param-name apikey \
+  --secret-file ./weather.key
+```
+
+Each credential is **bound to one or more hosts** — it's only ever injected on requests to those hosts, so a credential for one API can never be sent to another.
+
+:::tip Supply secrets without exposing them
+Prefer `--secret-file` (or piping the secret in) over `--secret` on the command line, so the value doesn't land in your shell history or the process list.
+:::
+
+## OAuth connections
+
+For providers that use OAuth, you don't paste a static token — you run a browser-based connect flow that completes the OAuth handshake and stores the resulting grant. The proxy then injects a valid access token on each request and handles refresh for you.
+
+Supported providers:
+
+- `github_app`
+- `notion`
+- `google`
+- `atlassian`
+
+```bash
+asg proxy connect github_app acme \
+  --key github \
+  --client-id <oauth-client-id> \
+  --client-secret-file ./github-client-secret \
+  --host api.github.com
+```
+
+This opens a browser to authorize the connection, then stores the credential under the key you chose (`github` above) — ready to be referenced from an [egress rule](./egress-rules).
+
+**Dashboard:** **Proxy → Credentials** lets you create OAuth connections and static credentials through a guided form.
+
+## AWS request signing
+
+For AWS APIs, the proxy can sign outbound requests with **AWS SigV4**, so your agents can call AWS services without ever holding AWS keys. Rather than storing a long-lived access key, the gateway mints **temporary credentials** (via STS `AssumeRole`) and signs each request server-side.
+
+You configure AWS request signing in the [dashboard](https://app.agent.security) under **Proxy → Credentials** as an AWS credential, then bind it to the relevant AWS host(s) like any other credential.
+
+## Preset packs
+
+Presets bundle a ready-made set of rules plus a credential placeholder for a common provider, so you can wire up a known API in one step instead of authoring rules by hand. Browse and apply them:
+
+```bash
+asg proxy preset list
+asg proxy preset apply <preset-name> acme --secret-file ./provider.key
+```
+
+`apply` previews what it will create before writing, so you can review the rules and credential it adds.
+
+**Dashboard:** **Proxy → Presets**.
+
+---
+
+## What's next
+
+- [**Egress Rules**](./egress-rules) — reference a credential from an `allow` rule with `--credential`.
+- [**Security**](./security#response-scrubbing) — how injected secrets are scrubbed from responses.
+- [**Connecting Agents**](./connecting-agents) — route an agent's traffic so injection takes effect.
diff --git a/docs/permit-mcp-gateway/http-egress-proxy/egress-rules.mdx b/docs/permit-mcp-gateway/http-egress-proxy/egress-rules.mdx
new file mode 100644
index 00000000..d4169a94
--- /dev/null
+++ b/docs/permit-mcp-gateway/http-egress-proxy/egress-rules.mdx
@@ -0,0 +1,122 @@
+---
+title: Egress Rules
+sidebar_label: Egress Rules
+description: Define which outbound requests your agents may make — ordered allow, block, and require-approval rules matched by host, path, HTTP method, and the calling agent.
+sidebar_position: 3
+---
+
+# Egress Rules
+
+Egress rules are the **allow-list** for outbound traffic. They decide, for each request an agent makes, whether it is allowed, blocked, or routed to a human for approval — before any credential is injected or any connection is made.
+
+The proxy is **deny-by-default**: if no rule matches a request, the request is denied. You grant access by adding rules.
+
+## What a rule matches
+
+Each rule matches a request on up to four dimensions:
+
+| Field | Matches | Example |
+| --- | --- | --- |
+| **Host** | The target hostname (supports glob patterns). | `api.stripe.com`, `*.githubusercontent.com` |
+| **Path** | The request path (supports glob patterns). Optional — omit to match all paths. | `/v1/customers/*` |
+| **Method** | The HTTP method class: `read`, `write`, `delete`, or `all`. | `read` |
+| **Agent** | Restricts the rule to specific agents. Optional — omit to apply to all agents. | a specific agent's client ID |
+
+The **method class** groups HTTP verbs by risk so you don't have to enumerate them: `read` covers safe methods like `GET` and `HEAD`, `write` covers `POST`/`PUT`/`PATCH`, `delete` covers `DELETE`, and `all` matches any method.
+
+## What a rule does
+
+Every rule carries one of three **actions**:
+
+| Action | Effect |
+| --- | --- |
+| **`allow`** | The request proceeds to authorization and is forwarded. An `allow` rule can also name a [credential](./credentials) to inject. |
+| **`block`** | The request is denied immediately — no authorization check, no connection. Use this to carve exceptions out of a broader allow. |
+| **`require_approval`** | The request pauses and a [human-in-the-loop](#human-approval-on-egress) approval is requested. It proceeds only if a human approves. |
+
+## HTTPS handling per rule
+
+For HTTPS targets, each rule also carries a **TLS mode** that decides how deeply the proxy inspects the encrypted connection:
+
+- **`passthrough`** (default) — the rule is enforced at the host level only; the encrypted tunnel is forwarded without decryption, so no credential injection, path matching, or response scrubbing happens inside it.
+- **`intercept`** — the proxy decrypts the connection (using a certificate authority issued for your host) and applies the rule in full, including credential injection and response scrubbing.
+
+TLS mode is set per rule in the [dashboard](https://app.agent.security) rule editor; rules created with the CLI default to passthrough. See [Connecting Agents → HTTPS interception](./connecting-agents#https-interception).
+
+## Ordering and precedence
+
+Rules are an **ordered list**, evaluated top to bottom; the **first matching rule wins**. Order matters: a narrow `block` must come before a broad `allow` to take effect.
+
+Two precedence guarantees help here:
+
+- **Agent-scoped rules win over unscoped rules.** A rule restricted to a specific agent is considered before general rules, so you can grant one agent extra access (or extra restriction) without rewriting your global rules.
+- **`block` is absolute for the requests it matches.** A matched `block` denies regardless of any Permit policy, trust ceiling, or rate-limit budget.
+
+Reorder rules with the CLI or by dragging them in the dashboard:
+
+```bash
+asg proxy rules reorder acme <rule-id-1> <rule-id-2> <rule-id-3>
+```
+
+## Managing rules
+
+```bash
+# List the current rules in evaluation order.
+asg proxy rules list acme
+
+# Allow read-only access to a path on one host, injecting a stored credential.
+asg proxy rules add acme \
+  --host api.stripe.com \
+  --path "/v1/customers/*" \
+  --method read \
+  --action allow \
+  --credential stripe
+
+# Block a sensitive sub-path even though the host is otherwise allowed.
+asg proxy rules add acme \
+  --host api.stripe.com \
+  --path "/v1/account*" \
+  --action block
+
+# Require human approval for deletes against a host.
+asg proxy rules add acme \
+  --host api.github.com \
+  --method delete \
+  --action require_approval
+
+# Scope a rule to a single agent.
+asg proxy rules add acme \
+  --host internal-api.example.com \
+  --action allow \
+  --agent-match <agent-client-id>
+
+# Update or delete by rule ID.
+asg proxy rules update acme <rule-id> --action block
+asg proxy rules delete acme <rule-id>
+```
+
+**Dashboard:** **Proxy → Rules** shows the same list with the evaluation order made explicit, plus inline add, edit, reorder, and delete.
+
+:::tip Start tight, then widen
+Begin with a small set of `allow` rules for the exact hosts your agents need, and let deny-by-default handle everything else. Widen only as real traffic requires it — it's far easier than starting open and trying to lock down later.
+:::
+
+## Human approval on egress
+
+A `require_approval` rule turns an outbound request into a [Human-in-the-Loop](/permit-mcp-gateway/human-in-the-loop) decision. When an agent hits such a rule:
+
+1. The request **pauses** at the proxy — it is not forwarded yet.
+2. An approval request is created and your reviewers are notified (email / Slack).
+3. If a reviewer **approves**, the request is forwarded. If they **reject** or the request **times out**, it is denied (fail-closed).
+
+This is the same approval machinery used for MCP tool calls, applied to raw HTTP egress — so you can gate, say, any `DELETE` to a production API behind a human, while routine reads flow through untouched.
+
+When an agent is driven by the CLI, approval outcomes are reported distinctly so automation can tell *"a human said no"* from *"blocked by policy"* from *"the request timed out."*
+
+---
+
+## What's next
+
+- [**Credentials & Connections**](./credentials) — what the `--credential` on an allow rule injects.
+- [**Authorization & Trust**](./authorization) — how rules combine with Permit policy and human trust ceilings.
+- [**Security**](./security) — SSRF protection and rate limiting that run alongside rule matching.
diff --git a/docs/permit-mcp-gateway/http-egress-proxy/index.mdx b/docs/permit-mcp-gateway/http-egress-proxy/index.mdx
new file mode 100644
index 00000000..de315c24
--- /dev/null
+++ b/docs/permit-mcp-gateway/http-egress-proxy/index.mdx
@@ -0,0 +1,111 @@
+---
+title: HTTP Egress Proxy
+sidebar_label: Overview
+description: Govern every outbound HTTP and HTTPS call your AI agents make — with the same identity-aware authentication, authorization, consent, and audit the gateway applies to MCP tool calls.
+sidebar_position: 0
+---
+
+# 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 your egress rules, 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.
+
+:::note Availability
+The HTTP Egress Proxy is a newer capability and is enabled per environment. If you don't see the **Proxy** section in your [dashboard](https://app.agent.security), [contact us](mailto:support@permit.io) 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.
+
+## What it enforces
+
+| Capability | What it gives you |
+| --- | --- |
+| **Deny by default** | No outbound request is allowed until an egress rule explicitly permits its host, path, and method. |
+| **Egress rules** | Ordered allow / block / require-approval rules matched by host, path, HTTP method, and (optionally) which agent is calling. |
+| **Server-side credentials** | Upstream API keys, tokens, and OAuth connections are stored encrypted in the gateway and injected into requests on the way out. The agent never sees them. |
+| **Human consent & trust ceilings** | Just 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-loop** | High-risk requests can pause for a human approval before they're forwarded. |
+| **SSRF protection** | Requests to internal, loopback, link-local, and cloud-metadata addresses are blocked before any DNS lookup or connection. |
+| **Response scrubbing** | Injected secrets are stripped out of upstream responses before they reach the agent. |
+| **Rate limiting** | Per-agent request budgets — by host and by domain — shed floods and contain runaway agents. |
+| **Full audit trail** | Every 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.
+
+```mermaid
+flowchart LR
+    Operator["Operator / CI"]
+    Agent["Agent runtime"]
+
+    subgraph Control["Control plane (configuration)"]
+        UI["Dashboard<br/>app.agent.security"]
+        CLI["asg CLI"]
+    end
+
+    subgraph Gateway["Permit MCP Gateway"]
+        GW["HTTP Egress Proxy"]
+    end
+
+    Permit["Permit.io<br/>policy + audit"]
+    Upstream["Upstream API<br/>(Stripe, GitHub, internal services)"]
+
+    Operator --> UI
+    Operator --> CLI
+    UI --> GW
+    CLI --> GW
+    GW --> Permit
+
+    Agent -->|"outbound HTTP/HTTPS"| GW
+    GW -->|"inject credential, forward"| Upstream
+    Upstream -->|"scrubbed response"| GW
+    GW --> Agent
+```
+
+- **Control plane** — you enable the proxy for a host, define egress rules, store credentials, and mint agent tokens. You do this in the [dashboard](https://app.agent.security) or with the [`asg` CLI](./cli). 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](./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 issued for your host.
+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. **Rule match** — the request's host, path, and method are matched against your ordered egress rules. No match means deny.
+5. **Rate limit** — per-agent, per-host budgets are checked.
+6. **Authorize** — `allow` rules are checked against your Permit policy; `require_approval` rules pause for a human; `block` rules are denied outright.
+7. **Trust ceiling** — for human-delegated agents, the effective access is capped at the trust level that human granted.
+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.
+
+For the detail behind each gate, see [Authorization & Trust](./authorization) and [Security](./security).
+
+---
+
+## Start here
+
+1. [**Quick Start**](./quickstart) — enable the proxy, add a rule, store a credential, and route an agent through it.
+2. [**The `asg` CLI**](./cli) — install and use the command-line tool that drives the whole control plane.
+3. [**Egress Rules**](./egress-rules) — the rule model: hosts, paths, methods, actions, ordering, and agent scoping.
+4. [**Credentials & Connections**](./credentials) — store upstream secrets and connect OAuth providers.
+5. [**Authorization & Trust**](./authorization) — how rules, Permit policy, and human consent compose.
+6. [**Connecting Agents**](./connecting-agents) — wire your agent runtime, Docker, or Kubernetes to the proxy.
+7. [**Security**](./security) — SSRF protection, credential isolation, response scrubbing, TLS modes, and rate limits.
diff --git a/docs/permit-mcp-gateway/http-egress-proxy/quickstart.mdx b/docs/permit-mcp-gateway/http-egress-proxy/quickstart.mdx
new file mode 100644
index 00000000..03179374
--- /dev/null
+++ b/docs/permit-mcp-gateway/http-egress-proxy/quickstart.mdx
@@ -0,0 +1,141 @@
+---
+title: Quick Start
+sidebar_label: Quick Start
+description: Enable the HTTP Egress Proxy for a host, add an allow rule, store an upstream credential, mint an agent token, and route an agent through the proxy — end to end.
+sidebar_position: 1
+---
+
+# Quick Start
+
+This walkthrough takes you from zero to a governed outbound API call: you'll enable the proxy for a host, allow one upstream API, store its credential, and route an agent through the proxy so its calls are authenticated, authorized, and audited.
+
+You can do every step in the [dashboard](https://app.agent.security) or with the [`asg` CLI](./cli). This guide shows the CLI because it's copy-pasteable; the dashboard equivalents are noted at each step.
+
+:::note Prerequisites
+- A host (tenant) in your [Permit MCP Gateway dashboard](https://app.agent.security). If you don't have one, follow the [gateway Quick Start](/permit-mcp-gateway/quickstart) first.
+- The proxy enabled for your account (see the availability note on the [Overview](./)).
+- The `asg` CLI installed and pointed at your gateway — see [The `asg` CLI](./cli#install).
+:::
+
+Throughout this guide, replace `acme` with your own host's subdomain.
+
+## 1. Enable the proxy for your host
+
+The proxy is off by default for every host. Turn it on:
+
+```bash
+asg proxy config acme --enable
+```
+
+**Dashboard:** go to **Proxy → Overview** and toggle the proxy on.
+
+## 2. Add an allow rule
+
+Rules are deny-by-default: until you allow a host, every outbound request to it is blocked. Allow one upstream API — here, the Stripe API:
+
+```bash
+asg proxy rules add acme \
+  --host api.stripe.com \
+  --action allow \
+  --credential stripe
+```
+
+This says: *requests to `api.stripe.com` are allowed, and the stored credential named `stripe` should be injected.* See [Egress Rules](./egress-rules) for paths, methods, ordering, and agent scoping.
+
+**Dashboard:** **Proxy → Rules → Add rule**.
+
+## 3. Store the upstream credential
+
+Store the API key the proxy should inject. Secrets are **write-only** — once stored, they can never be read back out, only overwritten.
+
+```bash
+asg proxy credentials create stripe acme \
+  --host api.stripe.com \
+  --injection header \
+  --header-name Authorization \
+  --value-template "Bearer {secret}" \
+  --secret-file ./stripe.key
+```
+
+The agent never holds this key. The proxy injects it on the way out and [scrubs it](./security#response-scrubbing) from responses on the way back. For OAuth providers like GitHub, Google, Notion, and Atlassian, use [`asg proxy connect`](./credentials#oauth-connections) instead of a static key.
+
+**Dashboard:** **Proxy → Credentials → Add credential**.
+
+## 4. Mint an agent access token
+
+The agent authenticates to the proxy with a short-lived token. For an automated agent (no human in the loop), mint one directly:
+
+```bash
+asg proxy token create acme \
+  --client-id ci-runner \
+  --out ~/.agent-security/tokens/acme.token
+```
+
+The token is written to a file with restrictive permissions. To instead let a **human** delegate access to an agent within a trust ceiling, use [`asg proxy authorize`](./authorization#human-consent) — that's the consent flow.
+
+## 5. Point your agent at the proxy
+
+The proxy speaks the standard `HTTP_PROXY` / `HTTPS_PROXY` convention, so most HTTP libraries pick it up automatically. Export the right variables for your shell:
+
+```bash
+eval "$(asg proxy env acme)"
+```
+
+This sets `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`, and points the proxy at the token file you created. Now any process in that shell routes its outbound HTTP/HTTPS through the gateway. For Docker and Kubernetes, see [Connecting Agents](./connecting-agents).
+
+## 6. Verify the allow-list
+
+Confirm that the host you allowed is reachable through the proxy:
+
+```bash
+curl https://api.stripe.com/v1/customers
+```
+
+Then confirm a host you did **not** allow is denied:
+
+```bash
+curl https://api.openai.com/v1/models
+# → blocked by the proxy (deny-by-default)
+```
+
+This proves the allow-list is enforced for **all** outbound traffic, including HTTPS, at the host level. If you only need allow/deny control over which hosts your agents can reach, you're done here.
+
+## 7. Inject credentials into HTTPS traffic
+
+To have the proxy actually inject the credential you stored in step 3 — and apply path-level rules and response scrubbing — the proxy needs to open the encrypted connection. By default HTTPS runs in **passthrough** mode (an opaque tunnel: host-level rules only, no injection). Switch the rule to **intercept** mode to unlock the full pipeline:
+
+1. **Enable intercept on the rule.** In the [dashboard](https://app.agent.security), open **Proxy → Rules**, edit your `api.stripe.com` rule, and set **TLS mode** to **Intercept (decrypt + inject credential)**. (Intercept is configured per rule in the dashboard; the CLI creates rules in passthrough mode.)
+2. **Provision and trust the certificate.** Intercept terminates TLS with your host's own certificate authority, so your agent must trust it:
+
+   ```bash
+   asg proxy ca rotate acme          # provisions the CA on first run
+   asg proxy ca download acme -o ./agent-security-ca.pem
+   asg proxy ca trust-shell acme     # prints how to point common tools at the CA
+   ```
+
+3. **Re-verify.** Make the same request again — this time the credential is injected for you (you never send the key), and it's scrubbed from the response:
+
+   ```bash
+   curl https://api.stripe.com/v1/customers
+   ```
+
+Use intercept where you need credential injection, path rules, or scrubbing on HTTPS; keep passthrough for hosts where host-level control is enough, or for very large uploads, downloads, and long-lived streams. See [HTTPS interception](./connecting-agents#https-interception) for the full picture. (Over plain HTTP, injection works with no intercept setup at all.)
+
+## Troubleshooting
+
+If something isn't working, run the built-in diagnostics:
+
+```bash
+asg proxy doctor acme
+```
+
+`doctor` checks gateway reachability, whether the proxy is enabled, your rule and credential counts, your local environment variables, and your token file's permissions and expiry.
+
+---
+
+## What's next
+
+- [**Egress Rules**](./egress-rules) — refine rules with paths, methods, approval gates, and per-agent scoping.
+- [**Credentials & Connections**](./credentials) — OAuth connections, injection methods, and AWS request signing.
+- [**Authorization & Trust**](./authorization) — delegate access to agents through human consent and trust ceilings.
+- [**Connecting Agents**](./connecting-agents) — Docker, Kubernetes, and HTTPS interception setup.
diff --git a/docs/permit-mcp-gateway/http-egress-proxy/security.mdx b/docs/permit-mcp-gateway/http-egress-proxy/security.mdx
new file mode 100644
index 00000000..f1703848
--- /dev/null
+++ b/docs/permit-mcp-gateway/http-egress-proxy/security.mdx
@@ -0,0 +1,67 @@
+---
+title: Security
+sidebar_label: Security
+description: The security properties of the HTTP Egress Proxy — SSRF protection, server-side credential isolation, response scrubbing, TLS modes, rate limiting, and a complete audit trail.
+sidebar_position: 7
+---
+
+# Security
+
+The egress proxy is a trust boundary for everything your agents send to the outside world. This page summarizes the protections it applies to that traffic.
+
+## Deny by default
+
+No outbound request is allowed unless an [egress rule](./egress-rules) explicitly permits it. A request that matches no rule is denied — and a denied request is never resolved to an IP address or connected to, so nothing leaks to a host you didn't allow. The cheap, fail-closed checks (authentication, SSRF, deny-by-default) all run **before** any network I/O.
+
+## SSRF protection
+
+Server-Side Request Forgery — tricking a server into calling internal addresses — is a top risk for any proxy that forwards on behalf of an agent. The proxy defends against it in two stages:
+
+- **Before any DNS lookup**, the literal target is checked against blocklists for loopback, private/internal ranges, link-local and cloud-metadata addresses (such as `169.254.169.254`), and carrier-grade NAT — including obfuscated and legacy IP encodings that attackers use to slip past naive filters.
+- **After DNS resolution**, **every** resolved address is re-checked, and the validated address is **pinned** so the connection can't be re-pointed at an internal host between the check and the connection (a DNS-rebinding / time-of-check-to-time-of-use defense).
+
+A single blocked address rejects the whole connection.
+
+## Credential isolation
+
+Upstream secrets are **encrypted at rest** in the gateway using envelope encryption, bound to specific hosts, and injected into requests **server-side**. The agent never receives them.
+
+Credentials are **write-only** — once stored they can't be read back through any interface, only overwritten or deleted. See [Credentials & Connections](./credentials).
+
+## Response scrubbing
+
+When the proxy injects a secret into a request, it also **removes that secret from the upstream response** — across response headers and the streamed body, including common encodings of the value (such as base64, hex, and percent-encoding). If a response can't be safely scrubbed, it fails closed rather than risk leaking the secret back to the agent. This keeps an injected credential from being reflected back and captured by the agent.
+
+## TLS modes
+
+`CONNECT` (HTTPS) tunnels are handled in one of two modes, chosen **per rule**:
+
+| Mode | Behavior |
+| --- | --- |
+| **`passthrough`** (default) | The encrypted tunnel is forwarded opaquely. Host-level rules and authentication apply, but the proxy does not see the path or body, and cannot inject credentials or scrub responses inside the tunnel. |
+| **`intercept`** | The proxy terminates TLS with your host's own certificate authority and re-applies the full check set — path-level rules, authorization, credential injection, response scrubbing, and approval gates — to every decrypted request. |
+
+Each rule's TLS mode is set in the [dashboard](https://app.agent.security) rule editor. See [HTTPS interception](./connecting-agents#https-interception) for how to enable intercept and trust the CA. In intercept mode the rule set is captured when a tunnel opens, so a rule change takes effect on the **next** connection — with one exception: **revoked consent is enforced live**, denying in-flight requests immediately.
+
+## Rate limiting and DoS bounds
+
+The proxy meters every request against per-agent budgets — both per **host** and per **registrable domain** — and sheds excess with a `429` and a `Retry-After`. These budgets run **before** the policy and approval checks, so a flood is rejected cheaply and can't be used to amplify load on your policy engine or your reviewers. Additional bounds — token size caps, slow-client timeouts, and a ceiling on concurrent connections — protect the proxy itself.
+
+## Audit trail
+
+Every decision the proxy makes is logged — the agent, the human it acts for, the target host, the matched rule, and the allow/deny outcome — so you can answer "which agent called which API, on whose behalf, and was it allowed?" after the fact. Proxy activity appears alongside your MCP audit data; see [Audit Logs](/permit-mcp-gateway/audit-logs).
+
+## What the proxy does and doesn't do
+
+The proxy governs the traffic that is **routed through it**. To make that governance effective:
+
+- **Route all of an agent's egress through the proxy.** An agent configured to bypass the `HTTP_PROXY` settings, or one that dials raw IPs directly, isn't governed. In production, pair the proxy with network controls that prevent agents from reaching the internet except through it.
+- **Use `intercept` mode where you need body- and path-level control over HTTPS.** In `passthrough` mode, HTTPS rules are host-level only.
+
+---
+
+## What's next
+
+- [**Egress Rules**](./egress-rules) — the allow-list these protections enforce.
+- [**Authorization & Trust**](./authorization) — the policy and consent gates.
+- [**Connecting Agents**](./connecting-agents) — routing traffic and TLS trust setup.
diff --git a/docs/permit-mcp-gateway/index.mdx b/docs/permit-mcp-gateway/index.mdx
index a51919f3..d1942d9b 100644
--- a/docs/permit-mcp-gateway/index.mdx
+++ b/docs/permit-mcp-gateway/index.mdx
@@ -56,6 +56,7 @@ See [Permit.io Integration](/permit-mcp-gateway/permit-integration/) for the det
 - [**Platform Reference**](/permit-mcp-gateway/platform/) — Admin UI for managing hosts, servers, and users
 - [**Humans & Agents**](/permit-mcp-gateway/managing-humans-and-agents/) — Managing users and the AI agents acting on their behalf
 - [**Host Setup Guide**](/permit-mcp-gateway/host-setup/) — Multi-host patterns, onboarding at scale, and rollout guidance
+- [**HTTP Egress Proxy**](/permit-mcp-gateway/http-egress-proxy/) — Govern an agent's arbitrary outbound HTTP/HTTPS API calls, not just its MCP tools
 - [**Authentication Methods**](/permit-mcp-gateway/authentication-methods/) — SSO, OAuth, and sign-in configuration
 - [**Consent Service**](/permit-mcp-gateway/consent-service/) — The user consent journey in detail
 - [**Audit Logs**](/permit-mcp-gateway/audit-logs/) — Reading, filtering, and investigating activity logs
diff --git a/sidebars.js b/sidebars.js
index 8485b4da..ccbb886e 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -214,6 +214,20 @@ const sidebars = {
             "permit-mcp-gateway/audit-logs",
             "permit-mcp-gateway/architecture",
             "permit-mcp-gateway/human-in-the-loop",
+            {
+              type: "category",
+              label: "HTTP Egress Proxy",
+              link: { type: "doc", id: "permit-mcp-gateway/http-egress-proxy/index" },
+              items: [
+                "permit-mcp-gateway/http-egress-proxy/quickstart",
+                "permit-mcp-gateway/http-egress-proxy/cli",
+                "permit-mcp-gateway/http-egress-proxy/egress-rules",
+                "permit-mcp-gateway/http-egress-proxy/credentials",
+                "permit-mcp-gateway/http-egress-proxy/authorization",
+                "permit-mcp-gateway/http-egress-proxy/connecting-agents",
+                "permit-mcp-gateway/http-egress-proxy/security",
+              ],
+            },
             "permit-mcp-gateway/permit-integration",
             "permit-mcp-gateway/advanced-features",
             "permit-mcp-gateway/enterprise-deployment",