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

# Services

> External APIs that an AI agent can securely call during a session.

A service represents one external API that an agent can access during a [session](/docs/documentation/platform/agent-vault/sessions). Each service defines the external API’s host URL, its authentication method, and a real credential to attach when forwarding requests from the agent.

You can configure services within an [access bundle](/docs/documentation/platform/agent-vault/access-bundles). For example, you might create a **code-review** access bundle and add services for Slack, GitHub, and Anthropic:

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

## Add a service

To add a service to an access bundle:

<Steps>
  <Step>
    In Agent Vault, go to **Access Bundles**. Select your access bundle, then select **Add Service**.
  </Step>

  <Step>
    On the **Choose a template** panel, pick the template for the API you want to reach, or select **Custom** to configure the host and header 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>
  </Step>

  <Step>
    Follow the steps and paste your credentials in the **Credential** section.
  </Step>

  <Step>
    Select **Add Service**. The service appears in the bundle's list.
  </Step>
</Steps>

## Credential types

When configuring a service, you have the option to set its credential type. This determines what the proxy attaches to outbound requests.

<Tip>
  If you're configuring a service with a template, you can usually leave the credential type set to the default.
</Tip>

### Bearer

The proxy attaches one header in the format `<header name>: <prefix> <value>`, which defaults to `Authorization: Bearer <value>`.

Bearer is the right choice for most APIs. If the API expects a bare key instead of a `Bearer`-prefixed one, change the header name to `X-API-Key` and clear the prefix.

### Basic

The proxy attaches the header `Authorization: Basic <base64 of username:password>`. Either the username or the password can be left blank.

Basic is the right choice for APIs behind HTTP basic authentication, including ones that put the entire key in the username field.

### Pass-through

The proxy attaches nothing, and forwards the agent's request to the API unchanged.

Pass-through is the right choice when the proxy's strict [traffic policy](/docs/documentation/platform/agent-vault/proxies#traffic-policy) would otherwise block the host. It lets the request reach the API without attaching a credential.

<Note>
  For **Bearer** and **Basic** services, if the agent's request already carries a header with the same name as the one the service sends, the proxy replaces it with the service's credential.
</Note>

## Host patterns

When configuring a service, you have the option to set which host patterns it matches. A host pattern controls which outbound requests get the service's credential attached.

<Tip>
  For security reasons, we recommend keeping host patterns as narrow as the API allows. If you're configuring a service with a template, you can usually leave the host set to the default.
</Tip>

### Multiple hosts

A single pattern can cover multiple hosts by listing them, separated by commas:

```text theme={"dark"}
api.github.com, uploads.github.com
```

### Default port

A host without a port specified only matches requests to the standard HTTPS port `443`:

```
api.github.com
```

This pattern matches `api.github.com:443`, but not `api.github.com:80` or `api.github.com:8080`.

### Non-standard ports

To match a port other than `443`, include it in the host:

```text theme={"dark"}
internal-api.example.com:8443
```

### Wildcards

Wildcards match exactly one label. The pattern below matches `api.atlassian.net`, but not `a.b.atlassian.net` or `atlassian.net`.

```text theme={"dark"}
*.atlassian.net
```

### Paths/routes

You can't configure a specific path/route on a host. Patterns like `api.github.com/repos` aren't supported.

## Host conflicts

Two services within an access bundle can't cover the same host with the same pattern. For example, if you have a service that defines its host as `api.github.com` and you try to create a second service with that same host, Infisical will stop you from saving the second service.

However, two services can match the same host if they define the host pattern differently. When the agent makes a request to that host, the request will match the service that defines the host more explicitly. For example:

* One service defines its host as `api.github.com`
* Another service defines it as `*.github.com`

In the above example, requests to `api.github.com` would get the credential from the first service.

<Note>
  Different access bundles can cover the same host with different credentials, since an agent only gets the credential from the access bundle its session is scoped to.
</Note>