docs/documentation/platform/agent-proxy/security.mdx
This page covers the Agent Proxy's security model: how agents stay isolated from each other and from real credentials, how requests are authenticated and authorized, how TLS interception works, and what access each identity needs. None of this is required to get started (see the Quickstart), but it is worth reading before running the Agent Proxy in production.
The Agent Proxy is pinned to one organization, the one its own machine identity belongs to, but nothing narrower: no project, environment, path, or services are configured on it. It discovers those per agent. When an agent connects, the Agent Proxy uses the agent's token to look up which proxied services that agent may use in the agent's folder scope. It then fetches the real secret values with its own machine identity. One Agent Proxy instance can serve many agents across projects and environments in the org while keeping them isolated: an agent can never receive credentials it was not granted Proxy access to, even on a shared instance.
The Agent Proxy's security boundary is machine identity: what an agent can reach is decided entirely by its permissions:
407 and a Proxy-Authenticate: Basic response. A request whose token is present but invalid, expired, or revoked is rejected with 403. Both checks happen before anything else.For the Agent Proxy to read and modify HTTPS requests, agents must trust the certificates it presents. The chain has three tiers, and the sensitive part never leaves Infisical:
flowchart LR
A["Root CA
(in Infisical, per org)"] -->|signs| B["Intermediate CA
(in Agent Proxy memory)"]
B -->|signs| C["Leaf certificates
(one per hostname)"]
The root CA is generated automatically per organization and stored encrypted in Infisical; its private key never leaves the server, and all signing happens server-side. At startup, the Agent Proxy generates a keypair locally and has Infisical sign it into a short-lived intermediate certificate (7 days, re-signed automatically before expiry). This certificate can mint leaf certificates but no further CAs. Leaf certificates (valid 24 hours, cached in memory) are minted locally per hostname, for the exact hostname the agent requested, with no Infisical round-trip.
On the agent machine, the connect wrapper downloads the root CA to ~/.infisical/agent-proxy/mitm-ca.pem and points the standard trust environment variables (SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, GIT_SSL_CAINFO, DENO_CERT) at it. The Agent Proxy's connection to the real service is standard HTTPS with normal certificate verification, so real credentials always travel encrypted.
Proxied services have their own project-level permission subject. Alongside the usual Read, Create, Modify, and Remove actions for managing services, it adds the one that defines the security model: Proxy. An identity with Proxy has a service's secrets applied to its traffic without ever being able to read the values, which is why it is the permission you grant agent machine identities.
Grant each identity the minimum permissions it needs with a custom role or an additional privilege, scoped to the environments and paths its services live in. This is the minimum each identity needs:
| Identity | Minimum permissions | Notes |
|---|---|---|
| Agent | Proxy on Proxied Services, scoped to the environments and paths where its services live | This alone lets it route traffic and have credentials applied. It does not need to read any secret. |
| Agent Proxy | Read Value and Describe Secret on Secrets, covering every secret the services reference; plus Manage Leases on Dynamic Secrets for any dynamic secret a service brokers | This is the identity that actually fetches the real values and mints leases. Describe Secret determines whether a secret is visible to the identity at all, Read Value reveals its value, and Manage Leases lets it mint a brokered dynamic secret. It needs no proxied-service permission. |
The key thing to get right for the Agent Proxy: it needs Read Value on every secret referenced by every service any of its agents use, across the relevant environments and paths. If a referenced secret comes from a secret import, the read permission has to cover the secret's real location (the import source), not just the folder it is imported into. If a grant is missing, that credential is skipped.
For a service that brokers a dynamic secret, the Agent Proxy identity needs Manage Leases on that dynamic secret. The agent identity must not have Manage Leases on it, or agent-proxy connect refuses to start.