Skip to main content
A service represents one external API that an agent can access during a session. 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. For example, you might create a code-review access bundle and add services for Slack, GitHub, and Anthropic:
The code-review access bundle's Services table listing its GitHub, Slack, and Anthropic services with their credentials and hosts

​
Add a service

To add a service to an access bundle:
1
In Agent Vault, go to Access Bundles. Select your access bundle, then select Add Service.
2
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.
The Choose a template panel with Custom, OpenAI, Anthropic, Slack, GitHub, and Google Workspace
3
Follow the steps and paste your credentials in the Credential section.
4
Select Add Service. The service appears in the bundle’s list.

​
Credential types

When configuring a service, you have the option to set its credential type. This determines what the proxy attaches to outbound requests.
If you’re configuring a service with a template, you can usually leave the credential type set to the default.

​
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 would otherwise block the host. It lets the request reach the API without attaching a credential.
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.

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

​
Multiple hosts

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

​
Default port

A host without a port specified only matches requests to the standard HTTPS port 443:
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:

​
Wildcards

Wildcards match exactly one label. The pattern below matches api.atlassian.net, but not a.b.atlassian.net or 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.
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.