Security

This page is for security teams and operators who evaluate or run the HTTP Egress Proxy. The proxy is a trust boundary for the traffic AI agents send to external services. Each section describes one protection, its limits, and the setting it depends on.

Deny by default

The proxy denies every outbound request unless a workflow rule permits it. A request that matches no rule in the token's workflow is denied.

Authentication, the server-side request forgery (SSRF) check on the literal target, and the workflow match run before the proxy touches the destination. The proxy makes no DNS lookup and no TCP connection to the target until a rule authorizes the request, so the proxy never connects to a blocked target.

SSRF protection

In an SSRF attack, a caller tricks a server into sending requests to internal addresses. The proxy blocks SSRF in two stages:

1. Before any DNS lookup, the proxy rejects internal IP literals and known cluster-internal host name suffixes:
   • Loopback, private, and internal ranges.
   • Link-local and cloud metadata addresses, such as 169.254.169.254.
   • Carrier-grade NAT addresses.
   • Obfuscated and legacy IP encodings of those addresses.
   • Host name suffixes such as .local, .internal, and .cluster.local.
2. After DNS resolution, the proxy rejects a host name that resolves to a private, loopback, link-local, or metadata address, before any connection. The proxy checks every resolved address and pins the validated address, so a DNS rebinding attack cannot redirect the connection to an internal host between the check and the connection.

One blocked address rejects the whole connection. The proxy resolves the host name only after a rule authorizes the request.

Credential isolation

The gateway stores upstream secrets, binds each secret to specific host patterns, and injects secrets into requests on the server side, so the agent never holds them. Secrets are write-only: no interface returns a stored secret, and you can only overwrite or delete it. See Credentials and connections.

Enable the KMS vault before storing production secrets

Encryption at rest is off by default. Without the KMS vault, the gateway writes credentials to its store in plaintext. The gateway logs a warning but still stores the credential. With the vault enabled, the gateway encrypts credential records at rest with AES-256-GCM envelope encryption.

To enable the vault, set VAULT_ENABLED=true and AWS_KMS_KEY_ID on the gateway. Enable the vault before you store live upstream API keys. If someone else operates your gateway, confirm the vault setting with them.

Response scrubbing

When the proxy injects a secret into a request, response scrubbing removes that secret from the upstream response. Scrubbing is on by default and configurable per credential. Scrubbing is best-effort.

The scrubber checks response headers, trailers, and the streamed body. It matches the raw secret and the encodings the proxy produces:

• Standard base64 and URL-safe base64.
• Lowercase hex.
• Percent-encoding, only when the credential is injected as a query parameter.

Scrubbing has these limits:

• Literal byte match. The scrubber matches bytes. If the upstream reflects the secret in another form, such as different letter case or JSON \uXXXX escapes, the secret can reach the agent.
• Compressed or non-chunked bodies. If the upstream returns a compressed or non-chunked body while scrubbing is on, the proxy withholds the whole response instead of streaming it unscrubbed.

You can turn scrubbing off per credential with --no-scrub-response. With scrubbing off, the proxy returns any echoed secret to the agent, and it no longer withholds responses it cannot scrub. Keep scrubbing on. See Response scrubbing for credentials.

TLS modes

The proxy handles each HTTPS CONNECT tunnel in one of two modes. The domain's tunnel rule, the rule with method class all and no path, sets the mode. See HTTPS needs a tunnel rule.

Mode	Behavior
passthrough (default)	The proxy forwards the encrypted tunnel without reading it. Authentication and tunnel rule authorization apply. The proxy cannot see the path or body, inject credentials, or scrub responses inside the tunnel.
intercept	The proxy terminates TLS with your host's certificate authority and runs every check on each decrypted request: path and method rules, authorization, credential injection, and response scrubbing.

The proxy reads only the tunnel rule when a tunnel opens, so for HTTPS the TLS mode is set per domain. Set the mode in the dashboard workflow editor. See HTTPS interception.

In intercept mode, the proxy captures the rule set when a tunnel opens. A rule change applies to the next connection.

Revocation and open tunnels

The proxy checks revocation on each new request it inspects. Traffic inside an established passthrough tunnel is opaque, so the proxy does not re-check it. The traffic continues until the client closes the tunnel or the idle timeout ends it. If revocation or a policy change must stop an in-progress HTTPS connection, use intercept mode. See Revocation.

Rate limiting and DoS bounds

The proxy counts every request that matches a workflow rule against two per-agent budgets in a fixed time window. When an agent exceeds a budget, the proxy returns 429 with a Retry-After header. The budgets run before the Permit policy and approval checks, so the proxy rejects a flood of requests before doing policy work.

Budget	Gateway default	Gateway setting
Requests per agent and destination host	600 per window	PROXY_RATE_LIMIT_PER_HOST
Requests per agent and registrable domain (for example example.com for api.example.com)	1200 per window	PROXY_RATE_LIMIT_PER_ETLD
Window length	60 seconds	PROXY_RATE_LIMIT_WINDOW_SECS

These values are gateway defaults. A gateway operator can change them, and setting a budget to 0 turns that budget off.

Other limits protect the proxy itself: token size caps, timeouts for slow clients, and a cap on concurrent connections.

Rate limiting fails open

If the rate limiter's counter store is unreachable, the proxy allows requests without counting them. Treat rate limiting as availability protection, not as a security boundary.

Agent identity and drift protection

Agent identity is opt-in. Email Permit support to enable it for your account.

A host with agent identity enabled requires every agent session to register its intent. Before its first governed request, the agent declares its task in exactly twelve distinct words with asg proxy register-session. The gateway builds a behavioral baseline from these declarations.

A sharp change in an agent's declared intent can mean an attacker hijacked or steered the agent. When the gateway detects such a change, it blocks the session. The gateway denies the agent's registrations and governed requests until a person re-approves the agent.

Recover a drift-blocked agent

The person who runs the agent recovers it:

1. The block response the agent receives includes a re-approval link to your gateway's consent screen (/reconsent-agent). The agent shows the link to the person running it. The agent does not open the link.
2. The person opens the link and signs in.
3. The review screen shows what the agent last declared it was doing. The person chooses one of two actions:
   • Re-approve agent. The block lifts, and the agent's next registration starts a new baseline.
   • Keep blocked. Nothing changes, and the agent stays denied.

Only the account that authorized the agent can unblock it. Anyone else who opens the link sees an error instead of the review screen.

Other ways to clear a block:

• A new consent flow with asg proxy authorize clears the block.
• An operator can clear a block with asg proxy identity reconsent. For an automated agent that runs with an operator-minted token and no person delegating access, the operator command is the only way to clear the block.

The audit trail records each re-approval, including who cleared the block.

Review the declared intent before you re-approve

The review screen shows the words that triggered the block. If they do not match the task you gave the agent, keep the agent blocked and investigate. A drift block is often the first visible sign of prompt injection.

asg proxy doctor reports a drift-blocked session as a failed check and shows the re-approval link. For background on agent identity and drift detection, see Agent verification.

Audit trail

The proxy logs each decision on a best-effort, fire-and-forget path. Each record includes the agent, the target host and path, the matched rule, and the allow or deny outcome. Proxy records appear with your MCP audit data and in CLIs / APIs → Activity in the dashboard. See Audit logs.

The proxy audit log has these limits:

• Agent, not person. A record identifies the agent by its client ID, not the person who authorized it. To attribute a call to a person, match the agent's client ID against the consent grants.
• Authentication failures are metrics only. The proxy cannot attribute a request to a tenant before it verifies the token, so authentication failures are counted as metrics and not logged per tenant.
• Events can be dropped. If the audit ingestion falls behind, the proxy can drop events. Do not use the proxy audit log as a guaranteed-complete compliance record.

What the proxy does and doesn't do

The proxy governs only the traffic that goes through it. To make the proxy's controls effective:

• Send all of an agent's egress through the proxy. The proxy does not govern an agent that ignores the HTTP_PROXY settings or connects to IP addresses directly. In production, add network controls that block agents from reaching the internet except through the proxy.
• Use intercept mode where you need path-level and body-level control over HTTPS. In passthrough mode, the proxy governs HTTPS at the domain level only. Path and method rules, credential injection, response scrubbing, and revocation inside an open tunnel do not apply.
• Enable the KMS vault before storing production credentials. See Credential isolation.

Next steps

• Workflows and rules: the allow-list these protections enforce.
• Authorization and trust: the policy and consent gates.
• Connecting agents: routing traffic and TLS trust setup.