How it works

Agent Vault lets an AI agent make authenticated API calls without ever holding the real credentials. Instead, the agent routes its API calls through an Agent Vault proxy, which attaches the credentials on the way out.

​

Mental model

Agent Vault uses four primitives to create secure sessions for AI agents:

• Services: Individual APIs, each configured with a real credential
• Access bundles: Groups of services, granted as a unit
• Sessions: Time-bound access grants that an agent uses to authenticate to the proxy for the services in an access bundle
• Proxies: The forward proxy that intercepts an agent’s outbound traffic and attaches real credentials to authorized requests

Here’s how the four concepts connect: This process allows the agent to authenticate to external APIs, all without having access to any of their real credentials.

​

Concepts

Here’s a breakdown of each primitive that Agent Vault relies on.

​

Services

A service represents one external API, such as GitHub’s REST API, Slack’s Web API, or Anthropic’s messages endpoint. Each service holds three things:

• Hosts. The host or hosts the service applies to, like api.github.com
• Authentication scheme. How the API authenticates: bearer, basic, or pass-through
• Credential. The real API token or username and password the proxy attaches to matching requests

You don’t hand services to an agent directly—they’re defined within access bundles.

​

Access bundles

An access bundle groups a set of services under one name. A code-review bundle might hold services for GitHub, Slack, and Anthropic. An on-call bundle might hold services for PagerDuty, Datadog, and Slack. You grant access to a bundle for a user, group, or machine identity. Anyone with access to that bundle can create sessions that reference it.

​

Sessions

A session is a time-bound access grant that’s scoped to one access bundle. Infisical returns a session token that identifies the session; the agent uses that token to authenticate to the Agent Vault proxy on every outbound request. When you create a session, you pick one access bundle and set an expiry. The agent never sees the real credentials inside the bundle. All it has is the session token, which only works when the proxy can authorize it against a live session. Even if an attacker stole the session token, they could only reach hosts that are defined by the access bundle’s services, and only until the session expires or you revoke it.

​

Proxies

A proxy runs where your agent’s traffic leaves your network. It intercepts every outbound HTTPS request, authorizes the request against the session’s access bundle, attaches the matching service’s credential as a header, and forwards the request to the upstream host.

​

Example flow: GitHub API

Here’s what happens when an agent calls api.github.com through an Agent Vault session:

1. The agent’s HTTPS client routes the request through the proxy (because the HTTPS_PROXY environment variable points at it), including the session token as the proxy credential.
2. The proxy looks up the session with Infisical, checking if it’s still live and which access bundle it carries.
3. The proxy looks inside the session’s access bundle and finds a service whose host pattern covers api.github.com. The proxy reads the real GitHub token from that service.
4. The proxy opens a new HTTPS connection to api.github.com, attaches the real token in the authorization header, and forwards the request.
5. GitHub responds. The proxy pipes the response back to the agent.

​

Why no code changes are needed

Agent Vault plugs into a mechanism the entire HTTP ecosystem already uses: the HTTPS_PROXY environment variable. Any HTTP client that reads HTTPS_PROXY routes through the proxy without any code changes. That includes curl, git, gh, Python’s requests, and most SDKs. infisical agent-vault run sets HTTPS_PROXY for the agent, trusts the proxy’s certificate authority, and passes the session token as the proxy credential. Everything the agent does after that works without needing to update any code.