docs/documentation/platform/agent-proxy/proxied-services.mdx
A proxied service tells the agent proxy how to apply credentials to traffic bound for an external service. It lives in a folder alongside your secrets and defines which hosts it covers.
To create one, open a folder in the secrets dashboard, click the dropdown arrow next to Add Secret, and select Add Proxied Service.
A service applies each secret through a header rewrite, a secret substitution, or both; each is covered in its own section below.
Every service has these core fields, plus one or more credential rules described below.
<ParamField path="Service Name" type="string" required> A slug (lowercase letters, numbers, hyphens) that identifies the service, such as `github`. Names are unique within a folder. </ParamField> <ParamField path="Host Pattern" type="string" required> One or more comma-separated patterns describing which hosts this service applies to. See [Host patterns](#host-patterns) below. </ParamField> <ParamField path="Enabled" type="boolean" optional default="true"> Toggle a service off without deleting it. A disabled service is skipped entirely: its placeholder environment variables are not set, no credentials are applied, and traffic to its hosts falls back to the [unmatched host policy](/documentation/platform/agent-proxy/deployment#unmatched-hosts). </ParamField>A host pattern routes requests to the right service. Each pattern is a host[:port][/path], and multiple patterns can be combined with commas:
api.github.com # exact host
*.github.com # wildcard: matches api.github.com, not a.b.github.com
api.github.com:443 # specific port
api.github.com/repos/* # path prefix
internal.corp.com:3000/api/* # port and path
api.github.com, uploads.github.com # multiple patterns, matches either
A few rules to keep in mind:
*. wildcard matches exactly one label: *.github.com matches api.github.com but not a.b.github.com or bare github.com.https://); patterns are hosts, not URLs.When a request could match more than one service, the agent proxy picks the best match:
A header rewrite adds or replaces an HTTP header on the outbound request. The agent does not need to send any credential; if it sends a made-up one, the header is overwritten with the real value. This covers most APIs:
| Auth style | Configuration | Resulting header |
|---|---|---|
| Bearer token | Header name Authorization, prefix Bearer, one secret | Authorization: Bearer <secret> |
| API key header | Header name x-api-key, no prefix, one secret | x-api-key: <secret> |
| Basic auth | One secret as Username, and optionally a second as Password | Authorization: Basic base64(username:password) |
| Custom | Any header name and optional prefix | <name>: <prefix> <secret> |
The password is optional for basic auth. Many APIs pass an API key as the username with an empty password; omitting the password produces Authorization: Basic base64(username:).
A service can rewrite multiple distinct headers (for example, an API key header plus a tenant header), but each header name can only be set by one secret. To build one header value out of several secrets, or use a secret kept elsewhere, see using secrets from other folders and environments.
With secret substitution, the agent is handed a dummy placeholder value. The agent proxy swaps it for the real credential wherever it appears in the request. It is useful in two situations:
api.telegram.org/bot<token>/sendMessage.The placeholder is also delivered for you: infisical secrets agent-proxy connect sets it as an environment variable in the agent's environment, so there is nothing to hand out.
You cannot point a proxied service at another folder directly, but you can bring an outside value into its folder so the service can use it. There are two ways, both using features that already exist in Infisical:
| Approach | What you do | Example |
|---|---|---|
| Imported secret | Import another folder into the service's folder, then use the imported key by name | Import /shared-creds, then use its SHARED_API_KEY from the service's folder |
| Composed with references | Create a secret whose value is one or more secret references, then use that secret. Lets you combine several secrets, including ones from other folders or environments | A secret set to ${AUTH_USERNAME}:${prod.shared.AUTH_PASSWORD} resolves to the two values joined as username:password |
A credential can reference a dynamic secret instead of a static secret. Rather than injecting a fixed value, the agent proxy mints a short-lived lease and injects one of its output fields (for example a GCP access token, a GitHub App token, or a Kubernetes service-account token).
How the agent proxy handles the lease:
Proxied services can also be managed via the API. For example, creating the Telegram service described above:
curl -X POST https://app.infisical.com/api/v1/proxied-services \
-H "Authorization: Bearer $INFISICAL_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"projectId": "<project-id>",
"environment": "dev",
"secretPath": "/coding-agent",
"name": "telegram-bot-api",
"hostPattern": "api.telegram.org",
"credentials": [
{
"secretKey": "TELEGRAM_BOT_TOKEN",
"role": "credential-substitution",
"placeholderKey": "TELEGRAM_BOT_TOKEN",
"placeholderValue": "placeholder_tg_bot",
"substitutionSurfaces": ["path"]
}
]
}'
Header-rewrite credentials use "role": "header-rewrite" with headerName and an optional headerPrefix, or headerPurpose (username/password) for basic auth.
To reference a dynamic secret, replace secretKey on a credential with dynamicSecretName and dynamicSecretField:
{
"dynamicSecretName": "github-app-token",
"dynamicSecretField": "TOKEN",
"role": "header-rewrite",
"headerName": "Authorization",
"headerPrefix": "Bearer"
}