Credentials & Connections

This guide is for operators who give AI agents access to third-party APIs through the HTTP Egress Proxy. You store an upstream API's credential in the gateway once, reference the credential from a workflow rule, and the proxy adds the credential to matching outbound requests.

The agent never holds the secret. The secret is not in the agent's prompt, environment, or memory, so a prompt injection attack cannot exfiltrate it from the agent. Response scrubbing removes the secret from upstream responses.

Enable the KMS vault before storing production secrets

The gateway encrypts credentials at rest only when it runs with the KMS vault enabled. Without the vault, credentials are stored in plaintext. See Credential isolation.

Credential types

Type	Use it for	How to create it
Static	A fixed API key, bearer token, or basic-auth password.	asg proxy credentials create, or the dashboard. See Static credentials.
OAuth connection	GitHub App, Notion, Google, or Atlassian APIs. The proxy injects a current access token.	asg proxy connect, or the dashboard. See OAuth connections.
AWS STS	AWS APIs. The proxy signs requests with AWS Signature Version 4 (SigV4).	The dashboard only. See AWS request signing.

Credentials are write-only

After you store a secret, no interface returns it: not the API, the asg CLI, or the dashboard, and not for admins. You can only overwrite or delete a stored secret.

Listing credentials shows each credential's name, target hosts, and whether a secret is set:

asg proxy credentials list acme

Static credentials

A static credential is a fixed secret you supply. Choose how the proxy injects the secret:

Injection method	What the proxy does
header	Adds a request header. You set the header name and a value template that contains {secret}, for example Bearer {secret} for an Authorization header.
query	Adds a query string parameter. You set the parameter name.
basic_auth	Sets HTTP Basic authentication from a username and the stored secret.

Save the secret to a file, then create the credential. The first argument is the credential name, and the second is the host subdomain:

# 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

To confirm the credential exists, run asg proxy credentials list acme. The new credential appears with its host and a set secret.

Bind credentials to specific hosts

Each credential is bound to one or more host patterns. The proxy injects the credential only on requests whose destination matches a pattern, so a credential bound to api.stripe.com is never sent to another host.

A * wildcard in a host pattern matches across dots. A broad pattern such as * or api.* lets the proxy send the credential to every host the pattern matches. Use exact host names where you can.

Keep secrets out of shell history

Pass the secret with --secret-file, or pipe it in, instead of --secret. A value passed with --secret is saved in your shell history and visible in the process list.

OAuth connections

For an OAuth provider, you do not paste a static token. You run a browser-based connect flow that completes the OAuth authorization and stores the resulting grant. The proxy then injects a valid access token on each request and refreshes the token as needed.

Supported providers:

• github_app
• notion
• google
• atlassian

Connect a provider with your OAuth app's client ID and client secret:

asg proxy connect github_app acme \
  --key github \
  --client-id <oauth-client-id> \
  --client-secret-file ./github-client-secret \
  --host api.github.com

asg proxy connect opens a browser to authorize the connection, then stores the credential under the key you chose (github in the example). Reference that key from a workflow rule.

In the dashboard, CLIs / APIs → Credentials creates OAuth connections and static credentials through a form.

AWS request signing

For AWS APIs, the proxy signs outbound requests with SigV4, so agents call AWS services without holding AWS keys. The gateway does not store a long-lived access key. It gets temporary credentials through AWS Security Token Service (STS) AssumeRole and signs each request.

Create an AWS STS credential in the dashboard:

1. Go to CLIs / APIs → Credentials and add a credential.

2. Choose the type AWS STS.

3. Enter these fields:

   Field	Description
   Role ARN	The IAM role the gateway assumes.
   External ID reference	Optional. The external ID for the role, if the role requires one.
   Region	The AWS Region requests are signed for, for example us-east-1.
   Service	The AWS service requests are signed for, for example s3.
   Session TTL	Lifetime of the temporary credentials, from 15 minutes to 12 hours.

4. Reference the credential from a workflow rule for the relevant AWS hosts.

SigV4 signing requires an AWS STS credential. You cannot use SigV4 with a static secret. asg proxy credentials create authors only the header, query, and basic_auth injection types, so create AWS STS credentials in the dashboard. The CLI does create OAuth connections, with asg proxy connect.

Response scrubbing

When the proxy injects a credential, it removes that secret from the upstream response so the upstream cannot reflect it back to the agent. Scrubbing is a per-credential setting and is on by default.

• In the dashboard, the setting is the Scrub from responses toggle on the credential form.
• In the CLI, use --scrub-response or --no-scrub-response.

Keep scrubbing on. With scrubbing off, the agent receives the secret whenever the upstream echoes it, and the proxy no longer withholds responses it cannot scrub. asg proxy doctor flags every credential with scrubbing off.

Scrubbing is best-effort: it matches the literal secret and the encodings the proxy produces. See Response scrubbing for what it covers.

Next steps

• Workflows and rules: reference a stored credential from a workflow rule.
• Response scrubbing in Security: what scrubbing removes and its limits.
• Connecting agents: route an agent's traffic so credential injection applies.