docs(mcp-gateway): outbound credential brokering + dynamic short-lived credentials (PR 4e)

cspell.json

@@ -7,6 +7,10 @@
       "JWKS",
       "colour",
       "customising",
-      "gitops"
+      "gitops",
+      "SigV4",
+      "IRSA",
+      "HashiCorp",
+      "EKS"
   ]
 }

docs/permit-mcp-gateway/advanced-features.mdx

@@ -115,6 +115,12 @@ Define what each agent is allowed to do by declaring its intended purpose up fro
 Intent-based access control is an emerging capability. [Contact us](mailto:support@permit.io) for current status and roadmap.
 :::
 
+## Outbound Credential Brokering
+
+Let agents call upstream APIs without ever holding the API's long-lived secret. The gateway injects the credential per request, scrubs it from the response, and can mint **short-lived, identity-scoped credentials just in time** — AWS STS temporary credentials (SigV4-signed) or OAuth access tokens minted from a vaulted refresh token that never leaves the gateway.
+
+See the dedicated **[Outbound Credentials](/permit-mcp-gateway/outbound-credentials)** guide for full documentation.
+
 ---
 
 ## Feature Maturity Summary
@@ -128,6 +134,7 @@ Intent-based access control is an emerging capability. [Contact us](mailto:suppo
 | **Session Monitoring** | Enterprise, early access | Anomaly detection capabilities under active development |
 | **Permission Receipts** | Enterprise | Available for enterprise plans |
 | **Intent-Based Access Control** | Enterprise, roadmap | Declared intent captured via Agent Interrogation, policy evaluation emerging |
+| **[Outbound Credential Brokering](/permit-mcp-gateway/outbound-credentials)** | Static available; dynamic (AWS STS, OAuth) active development | Per-request credential injection + response scrubbing; short-lived AWS/OAuth credentials minted just in time |
 
 :::info Items flagged on the marketing site but not yet detailed in documentation
 The following capabilities have been referenced in marketing materials but are not yet fully documented. Contact us for current status:

docs/permit-mcp-gateway/outbound-credentials.mdx

@@ -0,0 +1,77 @@
+---
+title: Outbound Credentials
+sidebar_label: Outbound Credentials
+description: Let agents call upstream APIs without ever holding a long-lived secret. The Permit MCP Gateway brokers outbound credentials — injecting them per request, scrubbing them from responses, and minting short-lived AWS and OAuth credentials just in time.
+sidebar_position: 8.5
+---
+
+# Outbound Credentials
+
+When an agent needs to call an upstream API — Stripe, GitHub, an AWS service, an internal microservice — it normally needs that service's credential. Handing the agent a long-lived API key is exactly the risk you adopted the gateway to avoid: the key lives in the agent's context, can leak through logs or prompt injection, and outlives the task.
+
+The Permit MCP Gateway acts as an **outbound credential broker**. The agent's outbound HTTP traffic is routed through the gateway; for each request the gateway authorizes the destination against policy, injects the right credential, forwards the request, and **scrubs the credential out of the response** before the agent sees it. The agent calls the API successfully but never observes the secret.
+
+:::note Plan availability
+Outbound credential brokering is part of the gateway's proxy capabilities. Dynamic / short-lived issuance (AWS STS and OAuth, below) is an Enterprise capability under active development — [schedule a demo](https://calendly.com/permit-io/demo) to discuss availability and fit.
+:::
+
+## How it works
+
+1. The agent is configured to send its outbound API traffic through the gateway.
+2. The gateway authorizes the destination host (and path/method) against your policy — the same identity-and-policy model used for MCP tool calls, including [human-in-the-loop approvals](/permit-mcp-gateway/human-in-the-loop) and rate limiting.
+3. The gateway injects the credential bound to that destination, and only toward hosts that credential is explicitly allowed to reach (a credential scoped to `api.stripe.com` can never be sent to another host, even if a broader rule allowed the request).
+4. The response is streamed back with the injected credential — and its common encodings — **redacted**, so an upstream that echoes the credential back (a diagnostic endpoint, an error message, a logging proxy) cannot leak it to the agent.
+
+The credential is stored encrypted at rest and is **write-only** in the admin surface — it is never returned once configured, and never exposed to the agent.
+
+## Credential types
+
+A credential is configured per destination. Three types are supported, spanning stored secrets and just-in-time issuance.
+
+### Static secret
+
+A stored long-lived secret (an API key, a token, a username/password) injected as a request header, a query parameter, or HTTP Basic auth. Use this for services that only issue long-lived keys. The secret is encrypted at rest and scrubbed from responses, but it is still a standing secret — prefer a dynamic type below where the provider supports it.
+
+### AWS STS — short-lived, role-scoped credentials
+
+Instead of storing an AWS access key, configure the **IAM role** the agent's calls should assume. For each request the gateway calls AWS STS to assume that role, receives **temporary credentials**, and signs the upstream request with AWS SigV4. **No long-lived AWS key is ever stored or injected** — the credentials are minted on demand, scoped to the role you choose, and expire automatically.
+
+The gateway authenticates to AWS with its own deployment identity (for example, an EKS IRSA role) — not a per-tenant standing secret — and can only assume the role configured in your own credential record. The temporary session token is scrubbed from responses like any other secret.
+
+### OAuth — minted from a stored grant
+
+For providers that issue refreshable OAuth tokens, the gateway stores the **refresh token** in its encrypted vault and mints a **short-lived access token** for each request window. The agent's request carries only the short-lived access token; **the refresh token never leaves the vault, is never injected into an upstream request, and is never logged**. When the access token nears expiry the gateway refreshes it transparently.
+
+:::info Why short-lived matters
+A leaked long-lived key is valid until someone notices and rotates it. A minted credential is scoped to a single role or grant and expires in minutes — so even in the worst case, the blast radius and the exposure window are small by construction. This is the same just-in-time model used by AWS STS, HashiCorp Vault dynamic secrets, and modern secrets brokers.
+:::
+
+## Caching and freshness
+
+To avoid calling AWS STS or your identity provider on every single request, the gateway caches a minted credential for a window **shorter than its real lifetime** and refreshes it before it expires — so a burst of agent traffic reuses one mint, and an expired credential is never reused. The cache is isolated per tenant: a credential minted for one organization's agent is never served to another.
+
+## Security summary
+
+- The agent never holds the upstream secret — the gateway injects it per request and scrubs it from responses.
+- Dynamic credentials (AWS STS, OAuth) are short-lived and identity-scoped; no standing secret is stored for them.
+- The OAuth refresh token and any client secret stay in the encrypted vault — never injected, never logged.
+- A credential is only ever sent to the hosts it is explicitly bound to.
+- Credentials and grants are encrypted at rest and isolated per tenant.
+
+## Requirements for AWS STS
+
+Using AWS STS credentials requires a small amount of AWS-side setup, typically handled by your platform team:
+
+- The gateway's deployment identity must be allowed to assume each configured role.
+- Each target role's trust policy must permit the gateway to assume it — in multi-tenant deployments, scoped with a per-tenant external ID.
+- The target role's maximum session duration must be at least the session lifetime you configure.
+
+See [Enterprise Deployment](/permit-mcp-gateway/enterprise-deployment) for customer-controlled deployment and infrastructure details.
+
+:::note Maturity
+Dynamic credential issuance (AWS STS and OAuth) is an Enterprise capability under active development. Static credential injection and response scrubbing are available today. [Contact us](mailto:support@permit.io) for current status, early access, and roadmap details.
+:::
+
+---
+
+**Interested?** [Schedule a demo](https://calendly.com/permit-io/demo) or reach out at [support@permit.io](mailto:support@permit.io). You can also find us on [Slack](https://io.permit.io/slack).