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 names it; the proxy injects it on the way out and scrubs it 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.

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

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

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.

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

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 — reference a credential from an allow rule with --credential.
• Security — how injected secrets are scrubbed from responses.
• Connecting Agents — route an agent's traffic so injection takes effect.