Skip to content

Credential Bindings#

Credential bindings attach credentials to policies. When an agent makes a request to a policy-governed domain, the platform injects credentials server-side via the proxy. The agent never sees the raw secret — not in environment variables, not in memory, not in tool output.

How credential injection works#

The credential injection flow has six steps:

  1. Agent request — the agent makes an outbound HTTPS request to a target domain (e.g., api.github.com).
  2. Domain match — the proxy matches the destination domain against policy rules to determine if the request is allowed and which credential binding applies.
  3. TLS termination — the proxy terminates the agent's TLS connection using an ephemeral certificate generated by the sandbox's internal CA.
  4. Header injection — the proxy injects credential headers (e.g., Authorization: Bearer ghp_...) into the request. The agent never sees these headers.
  5. Upstream connection — the proxy establishes a new TLS connection to the real destination using the upstream's actual server certificate.
  6. Forward — the request is forwarded with the injected credentials. The response returns to the agent through the same path.

The agent sees a successful HTTPS response. At no point does the credential enter the agent's process memory, environment variables, or tool output. This remains true even if the agent is compromised — credentials exist only in the proxy, and are injected at the network level.

Injection formats#

Credentials are injected as HTTP headers. Common formats:

Format Header example Use case
Bearer token Authorization: Bearer sk-... OAuth APIs, most SaaS services
API key x-api-key: key-... AWS-style APIs, custom services
Basic auth Authorization: Basic base64(user:pass) Legacy APIs
Custom header X-Custom-Auth: value Internal services

The injection format is configured per credential binding — you specify the header name and the value template.

Ephemeral CA#

Each sandbox generates its own certificate authority at startup:

Property Value
Algorithm ECDSA P-256
Storage In-memory only — never written to disk
Lifetime Sandbox process lifetime. Destroyed when the sandbox exits
Scope Per-sandbox. Each sandbox has its own CA. No CA is shared across sandboxes

The CA certificate is added to the sandbox's system trust store at startup. This allows the agent's HTTP client to trust the proxy's certificates for intercepted connections. Outside the sandbox, the CA has no validity — it cannot be used to intercept traffic anywhere else.

Kubernetes credentials#

For Kubernetes connections, credential handling is specialized — no long-lived credentials are stored or exposed:

Property Value
Token type JWT (JSON Web Token)
Lifetime 60 seconds
Rotation Automatic — the proxy requests a new token before the current one expires
Scope Scoped to the agent's team and project permissions
API access The proxy uses impersonation headers to forward requests as the agent's identity (agent:<name> with groups <org>/<team>)

The agent runs kubectl against a synthetic kubeconfig that points to the proxy. The proxy handles authentication with the real Kubernetes API server, including mTLS and token rotation.

For local CLI sandboxes, the proxy uses the client certificate from the user's kubeconfig to establish the mTLS connection. For managed agents, the platform provides the credentials.

AWS credentials#

For AWS connections, access uses STS (Security Token Service) for temporary session credentials:

Property Value
Mechanism STS AssumeRole
Credentials Temporary access key, secret key, session token
Session tags Agent identity, organization, project, and connection name included as session tags
Audit All API calls appear in CloudTrail under the assumed role, with session tags identifying the agent

Session tags allow AWS administrators to trace every API call back to the specific agent that made it, even when multiple agents assume the same role.

Credential storage#

Credentials stored on the platform are encrypted at rest:

Property Value
Encryption AES-256-GCM (authenticated encryption)
Key management Platform-managed encryption keys
Lookup Credentials are referenced by SHA-256 hash — the platform can verify a credential matches without decrypting it
Access Credentials are decrypted only at the moment of injection, in memory, and never written to disk in plaintext
Agent tokens Stored as SHA-256 hashes (one-way, original never retrievable)

For local CLI execution, credentials are stored on the user's machine with owner-only filesystem permissions. The sandbox proxy reads them at injection time; they are not written into the sandbox itself.

Why this matters#

Traditional approaches give agents credentials directly — as environment variables, config files, or API keys in the prompt. This means:

  • The agent can exfiltrate credentials (intentionally or through prompt injection)
  • Credentials appear in logs, memory, and tool outputs
  • There is no way to revoke access without rotating the credential everywhere

With proxy-based injection:

  • Credentials never enter the agent's environment
  • The proxy controls exactly which domains receive which credentials
  • Revoking access is instant — update the policy, and the proxy stops injecting
  • The audit trail records every credentialed request