Skip to main content
An inline service is a service that you send in the request that creates a session, instead of adding the service to an access bundle. Only that session can use the inline service. A session can have inline services on their own, or together with one access bundle. Use inline services when the code that creates sessions, such as an agent orchestrator or a job runner, already knows which APIs an agent needs and holds their credentials. That code sends the services with each session, so nothing has to be set up in Agent Vault in advance, and a credential that exists for only one run is deleted when the session ends. You can also use inline services to give one session access to an API that isn’t in its access bundle, without giving the API to the other sessions that use the bundle.

​
Prerequisites

​
Create a session with inline services

You can send inline services only through the API, not from the dashboard or the CLI. Call the endpoint that creates a session as the machine identity, and list the inline services in services. In this example, the session gets one HTTP service for api.github.com with a bearer token, and the agent can send only GET requests to that host:
An inline service has the same fields as an HTTP API or an MCP server in an access bundle, with these differences:
  • name is optional (without a name, the service goes by its first host on the Sessions page and in the session logs)
  • Credentials, custom header values, and substitution values can’t use variables, so they can’t contain text in double braces, such as {{GITHUB_TOKEN}}
  • An MCP server can’t use OAuth, or limit the agent to some of its tools
  • A credential can’t use member-provided values
  • You can’t change an inline service after you create the session
A session can have up to 20 inline services, and no two of its services can have the same name, including the services in its access bundle. A service sent without a name counts as its first host. The reference for the endpoint that creates a session lists every field and its limits. Start the agent with the session token from the response, as Step 4 of Create sessions with the API describes. When the agent finishes, revoke the session.
A machine identity can also send inline services with a session that it creates on behalf of a user. The user doesn’t need the Admin role, and the inline services don’t use the user’s personal values.

​
Combine inline services with an access bundle

To give a session an access bundle as well as inline services, name the access bundle in accessBundles in the same request. A session can have only one access bundle. When you create the session, Infisical compares the host patterns of the inline services with each other and with the access bundle’s services, using the same host conflict rules as for the services in one access bundle:
  • If two of the services use the same host pattern, creating the session fails
  • If an inline service and a service in the access bundle cover the same host with different patterns, such as api.github.com and *.github.com, requests to that host use the service with the more specific pattern

​
Find a session’s inline services

To see a session’s inline services, go to Sessions in Agent Vault, select View Session Logs on the session’s row, and look under Inline Services. The endpoint that reads a session and the endpoint that lists sessions return the inline services in services, and the audit event for creating the session lists them too.

​
When the session ends

Infisical deletes the inline services’ credentials, custom header values, and substitution values once the session ends:
  • If someone revokes the session, Infisical deletes the values right away
  • If the session expires, Infisical deletes the values within an hour
If you set ttl to never, revoke the session when the agent finishes, so that Infisical deletes the values. Infisical keeps the rest of each inline service, such as its name and hosts, so you can still find the session’s inline services after the session ends.

​
Troubleshooting

The machine identity has the Member role in Agent Vault. Either give it the Admin role, or add the services to an access bundle and grant the bundle to the machine identity.To give the machine identity the Admin role:
1
In Agent Vault, go to Access Control > Machine Identities.
2
Open the machine identity’s menu and select Change Role.
3
Choose Admin in Product Role, then select Save.
The user or machine identity that created the session no longer has the Admin role in Agent Vault. Give the role back, or create a new session as an admin.

​
Next steps

Session logs

Record every request an agent makes during a session.

HTTP APIs

Limit an HTTP service’s methods and paths, and add custom headers and substitutions.