Skip to main content
An access bundle is what you hand an agent: everything it needs for a job, granted and revoked as one unit. A bundle holds services, and names who may run agents with it. A service is one external API the agent may reach, with the hosts that API answers on and the credential the proxy attaches to requests bound for it. You grant access bundles and create sessions with them; the proxy brokers the services inside.

​
Access bundles

An access bundle has a name, an optional description, its services, and its members. Granting an access bundle to a user, machine identity, or group lets them create sessions with it. The grantee has to be an Agent Vault member first: see Access control.
The Access Bundles page listing four access bundles with their services and member counts
Access bundles are how you scope access. An agent for on-call work gets the incident tooling, an agent for code review gets GitHub, and neither reaches the other’s hosts. Removing a member from an access bundle, or from Agent Vault, takes effect on their running agents within one poll interval of the proxy. Deleting one removes its services from every session that carries it. See Sessions.

​
Services

Each service has a name, the hosts it covers, and a credential. Open an access bundle from Access Bundles and select Add Service to add one.
The code-review access bundle's Services table listing its GitHub, Slack, and Anthropic services with their credentials and hosts

​
Credential types

The first step offers a Template for common services, which fills in the hosts and the header. Choose Custom to set them yourself.
The Choose a template panel with Custom, OpenAI, Anthropic, Slack, GitHub, and Google Workspace
If the agent’s request already carries a header with the same name, the proxy replaces it with the service’s credential.

​
Host patterns

A host pattern is a comma-separated list of hosts, each with an optional port:
  • A host without a port means port 443. Credentials are attached to HTTPS traffic only.
  • *. at the start matches exactly one label. *.example.com covers api.example.com, not a.b.example.com or example.com.
  • Paths aren’t allowed. A service covers a host, not a route on it.
Keep patterns as narrow as the API allows. A wildcard covers every host under it, and the credential goes to all of them. Some templates carry a placeholder such as <your-tenant>.atlassian.net for this reason; replace it with your own tenant before saving.

​
When two services cover one host

Within one access bundle, two services can’t cover the same host with the same pattern. Infisical rejects the save and names the service that already covers it. An exact host and a wildcard that includes it can both exist, and the exact one wins: if one service covers api.example.com and another *.example.com, requests to api.example.com get the first service’s credential. Different access bundles can cover the same host with different credentials. An agent gets the credential from the access bundle its session carries.