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; a workflow rule references it; the proxy injects it on the way out and scrubs it from the response on the way back (on by default).

This is one of the proxy's most important properties: the agent never holds the secret. It isn't in the agent's prompt, environment, or memory, so it can't be exfiltrated by prompt injection, and response scrubbing keeps it from being reflected back through the upstream's response. For encryption at rest, the gateway must be running with the KMS vault enabled — see Security → Credential isolation.

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.

Response scrubbing

When a credential is injected, the proxy strips that secret out of the upstream response so it can't be reflected back to the agent. This is a per-credential setting that is on by default — a toggle on the credential form, or --scrub-response / --no-scrub-response on the CLI. Leave it on: with it off, the secret is returned verbatim to the agent whenever the upstream echoes it, and unscrubbable responses are no longer withheld. asg proxy doctor flags any credential that has scrubbing disabled. Scrubbing is best-effort (a literal byte match over the value and the encodings the proxy produces) — see Security → Response scrubbing for exactly what it covers.

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 host patterns — it's only injected on requests whose destination matches one of them, so a credential scoped to api.stripe.com can never be sent elsewhere. Patterns support * wildcards that match across dots, so keep bindings as specific as you can: a broad pattern such as * or api.* authorizes the credential toward every host it matches.

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 a workflow rule.

Dashboard: CLIs / APIs → 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 it in the dashboard under CLIs / APIs → Credentials: add a credential, choose type AWS STS, and supply the Role ARN to assume, an optional External ID, the AWS Region and Service the requests are signed for (e.g. us-east-1 / s3), and a session TTL (15 minutes to 12 hours). Then reference it from a workflow rule for the relevant AWS host(s) like any other credential. SigV4 requires an AWS STS credential — it can't be attached to a static secret, and the CLI creates static credentials only.

---

What's next

• Workflows & Rules — reference a stored credential from a workflow rule.
• Security — how injected secrets are scrubbed from responses.
• Connecting Agents — route an agent's traffic so injection takes effect.