Skip to main content

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.

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 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 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.

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 for customer-controlled deployment and infrastructure details.

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 for current status, early access, and roadmap details.

Interested? Schedule a demo or reach out at support@permit.io. You can also find us on Slack.

Contents