Skip to main content
This guide walks through connecting a custom agent to Agent Vault. Use this when you’re building your own sandboxed agent, a CI pipeline, or any process that needs to make authenticated API calls through Agent Vault.
If you’re using Claude Code, Cursor, or another supported agent, see the Quickstart guides instead. Those agents handle the connection protocol automatically.

Prerequisites

  • A running Agent Vault server with the transparent proxy enabled (default)
  • A user account with vault access (member or admin)

Get connection credentials

For local development, wrap your agent process directly:
vault run sets AGENT_VAULT_ADDR, AGENT_VAULT_TOKEN, and AGENT_VAULT_VAULT on the child, then pre-configures HTTPS_PROXY/HTTP_PROXY and the CA trust chain so standard HTTP clients route both HTTP and HTTPS traffic through the broker transparently.

Environment variables

Your agent needs these values to operate: For instance-level agent tokens (from agent create), the agent must also send the X-Vault header on /discover and /v1/proposals requests. For vault-scoped sessions (from vault run), the vault is embedded in the session. When the agent is launched via vault run, these additional variables are also set automatically on the child:

Make requests

When your agent is launched via vault run, HTTP and HTTPS traffic both route through Agent Vault transparently. Call the real API URL — standard HTTP clients honor HTTPS_PROXY/HTTP_PROXY automatically. Agent Vault intercepts the CONNECT (for https:// upstreams) or the absolute-form forward-proxy request (for http:// upstreams), matches the host against the vault’s services, and injects the stored credential into the auth header for that service.
Any HTTP method works (GET, POST, PUT, DELETE, PATCH). Query parameters, request bodies, and headers flow through unchanged.
Leave the upstream Authorization header blank or set it to a placeholder — Agent Vault strips whatever the client sends and attaches the real credential at the proxy boundary.

Set the proxy env vars manually

If your agent wasn’t launched via vault run (e.g. an agent created via agent create, a Docker container, a sandboxed runtime), configure the proxy yourself. The MITM listener is plain HTTP — deploy on a trusted/private network. Set HTTPS_PROXY and HTTP_PROXY to the same URL — the listener handles CONNECT (for https:// upstreams) and absolute-form forward-proxy requests (for http:// upstreams) on the same port.
For containerized agents, the TypeScript SDK provides buildProxyEnv(), which returns the complete environment block from a session’s containerConfig.

Discover available services

Your agent can call /discover to check which hosts have credentials configured before making requests.
Response
  • services lists the services configured in the vault. Each entry has a canonical name (slug) and a host pattern (which may carry an inline path glob like slack.com/api/*). Requests not matching any service go direct.
  • available_credentials lists credential key names in the vault (values are never exposed).
Discovery is optional. If your agent already knows which hosts are configured, it can skip straight to making requests. If it hits a host that isn’t configured, Agent Vault returns a 403 with a proposal_hint.

Handle errors

Next steps

Deploy your agent in a container

Ship your agent as a container image (k8s, Fly, ECS) using a pre-supplied AGENT_VAULT_TOKEN instead of an interactive auth login.

Agent protocol

Full HTTP reference for sessions, discovery, and proposals.

Proposals

Request access to new services via the proposal API.

Credentials

Managing secrets in Agent Vault.

Agents overview

Agent lifecycle, vault access, and management.