Introduction
In Building Trustworthy AI Agents Starts with Distrust, I argued that trust is not something an AI model possesses. It is authority granted by the surrounding architecture through explicit boundaries, permissions, and controls.
That principle becomes concrete as soon as an agent needs to interact with external services. An agent may need an LLM provider, a code repository, a database, or another API to perform useful work. Traditionally, this means making the corresponding credential available to the runtime, even when the secret is stored securely elsewhere and injected only when the process starts.
But secure storage and secure runtime access are different problems.
For my own agent infrastructure, I wanted to move the real provider credentials outside the agent runtime altogether. The agents run on one Hetzner server, while an Infisical Standalone Agent Proxy runs on a second server connected through a Hetzner private network. The agent authenticates with its own identity; the broker authenticates separately and applies the real credential only to authorized outbound traffic.
The resulting architecture is less about hiding secrets more carefully and more about changing who is ever allowed to possess them.
Why Secret Storage Is Not Enough
Secret management usually begins with storage: credentials should not live in source code, committed configuration files, or broadly readable environment files. A dedicated secrets platform solves an important part of that problem by centralizing access, policy, rotation, and auditability.
The remaining question is what happens when the secret is used.
Many applications still retrieve the real credential and expose it to the process that needs to call an external service. For conventional workloads, that may be an acceptable trade-off. AI agents deserve more scrutiny because their execution surface is increasingly dynamic: they invoke tools, process untrusted input, call external systems, and make decisions that determine which action happens next.
If the process can read the real API key, compromising that process can expose the key as well.
The relevant distinction is therefore between protecting a secret at rest and protecting it during use. A stronger design allows the workload to prove what it is permitted to access without requiring possession of the provider credential itself.
That reframes secret management from a storage problem into an access-architecture problem.
Separating Service Access from Credential Possession
The more useful security distinction is between being authorized to use a service and being able to read the credential that authorizes it.
Infisical represents workloads through Machine Identities. Its documentation describes a machine identity as an entity that "represents a workload or application" requiring access to Infisical resources.
For proxied services, the agent can then receive permission to use a service without receiving permission to read the underlying secret. The broker operates under a separate identity with the authority required to retrieve the real credential.
That creates three distinct security concepts:
agent identity ≠ proxy identity ≠ provider credential
Each has a different role and a different blast radius.
The proxied-service model makes the separation concrete. As Infisical documents it, "the agent is handed a dummy placeholder value," while the proxy substitutes the real credential into the outbound request.
The significant property is where that substitution happens: outside the agent runtime.
This makes service access an authorization decision rather than a reason to distribute another long-lived secret into the runtime.
Identity Should Follow the Runtime Boundary
An AI agent system can contain many logical agents without running each of them as an independent operating-system process.
In this implementation, multiple specialist agents share a single long-running worker process. The worker receives tasks and passes them to an orchestration layer, which determines what type of work has arrived and selects the corresponding workflow. A blog task, for example, is routed into a blog workflow, which then invokes specialist agents for research, writing, review, or other parts of the task.
Those specialists are separate at the application level, but they are not separate Linux services. They execute through the same worker process and therefore share the same underlying runtime boundary.
This distinction matters because logical separation inside an agent framework does not automatically create an enforceable security boundary. If several specialists execute through the same worker process, the surrounding infrastructure still sees a shared runtime with shared authority.
In this design, the machine identity is therefore associated with the worker runtime rather than with an individual specialist agent. It represents the component that actually authenticates to the credential infrastructure and initiates proxied access to external services.
Agent roles, task types, and orchestration boundaries describe how work is organized inside an application. Security identities should reflect where execution and authority are actually isolated.
Identity becomes meaningful as a security control only when it maps to a boundary that the surrounding infrastructure can enforce.
A Credential Boundary Must Be Enforceable
Moving credentials outside the runtime creates a useful boundary, but only if the boundary can be enforced and observed.
The broker can decide which machine identity may use which configured service while keeping the corresponding secret unreadable to that identity. The permission model therefore separates the authority to use a service from the authority to retrieve the secret behind it.
That does not automatically make the broker a complete egress-security layer. Infisical explicitly notes in its Standalone Agent Proxy documentation that "a tool that ignores the proxy variables isn't brokered either." Network restrictions and egress controls remain separate architectural decisions when traffic must be forced through a particular path.
Observability is equally important. During validation of this deployment, the proxy logs exposed the requesting machine identity, target service, environment, brokering decision, and upstream response. This provided evidence that the expected identity was using the expected service and that credential substitution occurred outside the workload.
A useful credential boundary therefore has three characteristics: the workload cannot read the underlying credential, access can be constrained to explicitly authorized services, and the resulting activity can be attributed and inspected.
Without those properties, credential isolation may exist in the architecture design without being reliably enforced at runtime.
Scaling the Credential Boundary
Once credential brokering becomes shared infrastructure, scalability is no longer only a question of how much traffic the agents generate.
For the planned environment of roughly 40 agents, Infisical staff advised that 2 vCPU and 4 GB of RAM should be sufficient for a single proxy. More interestingly, their guidance was that hardware is not necessarily the first constraint: CPU demand depends more on actual traffic than on the number of connected agents.
The current documentation supports the other side of that observation. Infisical states that the proxy "keeps everything it needs in memory," allowing steady-state requests to be served without contacting Infisical on every request.
The less obvious scaling factor is the control plane.
Active-agent state is refreshed every 60 seconds by default. As the number of active agents grows, so does the polling load back to Infisical. A longer polling interval reduces that load, but also increases the time required for changed permissions or rotated credentials to propagate.
In direct guidance for this deployment, Infisical staff gave a rough estimate of approximately 30–50 agents per proxy under default settings, with more potentially supported when the polling interval is increased. They explicitly described this as guidance rather than a formal benchmark.
The documented scale-out model is multiple proxy instances behind a TCP load balancer. Each instance maintains its own in-memory cache and polls independently, which also means secret or permission changes may propagate at slightly different times across instances.
The architectural implication is more interesting than the capacity number itself. Once brokering becomes shared infrastructure, data-plane traffic, control-plane polling, propagation latency, and broker availability all become part of the security design.
Credential Isolation Is Not Runtime Isolation
Keeping provider credentials outside the agent runtime reduces one important part of the blast radius, but it does not make the runtime itself trustworthy.
A compromised or overprivileged agent process may still misuse the authority it has been granted. Even without access to the underlying API key, it could make valid requests through an authorized service, access local files available to its process, interact with reachable systems, or abuse whatever privileges the host operating system gives it.
This is where credential isolation reaches its boundary.
In the current deployment, the worker still runs as root. Moving it to a dedicated non-root account is a separate hardening problem, independent of whether credential brokering works correctly. The existing Python environment also depends on a root-scoped uv runtime, so that transition requires restructuring the runtime rather than simply changing the service account.
The distinction is important: protecting credentials limits what can be stolen, while runtime isolation limits what a compromised process can do.
As discussed in my previous article, Building Trustworthy AI Agents Starts with Distrust, runtime containment, least privilege, network restrictions, and other controls define how much authority an agent can exercise.
Credential brokering addresses one narrower part of that architecture. It reduces exposure of the credentials behind that authority, but it does not replace the controls around the runtime itself.
Conclusion
Secret management for AI agents should not end with storing credentials securely.
The more important architectural question is whether the agent needs to possess those credentials at all.
Separating agent identity, broker identity, and provider credentials changes the trust model. The workload can be authorized to use a service while the credential required by that service remains behind a separately controlled boundary. When that boundary is enforceable, observable, and aligned with the actual runtime architecture, compromising an agent no longer automatically means exposing every credential available to it.
The pattern also introduces its own engineering concerns. The broker becomes shared infrastructure, authorization must map to real execution boundaries, outbound traffic must follow the intended path, and control-plane behavior becomes relevant as the number of agents grows.
Credential brokering therefore does not remove the need for runtime isolation, least privilege, or network controls. It addresses a different question within the same security model: an agent can be authorized to use an external service without ever receiving the real credential behind that access.
The broader lesson is that secure agent architecture is not only about restricting what an agent may do. It is also about reducing what the agent needs to know and possess in order to do it.
Moving credentials outside the runtime is one concrete way to make that distinction enforceable.