> ## Documentation Index
> Fetch the complete documentation index at: https://infisical.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Access bundles and services

> How access bundles group services and who can run agents with them, and what a service sends and where.

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](/docs/documentation/platform/agent-vault/access-control).

<Frame>
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/infisical/images/platform/agent-vault/access-bundles-list.png" alt="The Access Bundles page listing four access bundles with their services and member counts" />
</Frame>

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](/docs/documentation/platform/agent-vault/sessions#what-a-running-agent-can-reach).

## 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.

<Frame>
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/infisical/images/platform/agent-vault/access-bundle-services.png" alt="The code-review access bundle's Services table listing its GitHub, Slack, and Anthropic services with their credentials and hosts" />
</Frame>

### Credential types

| Type             | What the proxy sends                                                                        | When to use it                                                                                                                                              |
| ---------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Bearer**       | One header, `<header name>: <prefix> <value>`. Defaults to `Authorization: Bearer <value>`. | Most APIs. Set the header name to `X-API-Key` and clear the prefix for APIs that take a bare key.                                                           |
| **Basic**        | `Authorization: Basic <base64 of username:password>`. Either half can be blank.             | APIs behind HTTP basic auth, including ones that put the whole key in the username.                                                                         |
| **Pass-through** | Nothing. The request is forwarded unchanged.                                                | To make a host reachable on a proxy that allows only access bundle hosts. See [Traffic policy](/docs/documentation/platform/agent-vault/proxies#traffic-policy). |

The first step offers a **Template** for common services, which fills in the hosts and the header. Choose **Custom** to set them yourself.

<Frame>
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/infisical/images/platform/agent-vault/service-template-picker.png" alt="The Choose a template panel with Custom, OpenAI, Anthropic, Slack, GitHub, and Google Workspace" />
</Frame>

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:

```text theme={"dark"}
api.github.com, uploads.github.com
*.atlassian.net
internal-api.example.com:8443
```

* 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.