Autonomous AI agents are moving into production faster than the security tooling around them. They behave nothing like the deterministic services your secrets management was built for: they process natural language and call each other across trust boundaries. That combination creates a new failure mode.
Consider a typical setup. Agent A queries a production database to answer internal questions; Agent B fetches information from the public web. In isolation, both are fine. Combined, they create an attack surface: a malicious payload reaching Agent B can instruct Agent A to disclose what it knows. In poorly designed systems, that includes raw credentials sitting in environment variables.
This is a classic Confused Deputy problem, and the answer belongs in the architecture. LLMs will remain susceptible to prompt injection, so build systems in which a compromised agent can leak only the narrow scope it was given.
The strongest guarantee is to keep the real credential entirely outside the agent, behind a brokering layer between the agent and upstream APIs.
A common pattern: the agent receives an opaque reference (a short-lived OpenBao token or workload identity) and sends outbound calls through a sidecar or egress proxy. The proxy fetches the real credential from OpenBao and attaches it to the forwarded request. The credential lives in the request layer, beyond the agent's reach.
You build this interception layer around OpenBao. OpenBao Agent in proxy mode is the standard starting point, or a service mesh if you already operate one. OpenBao supplies the credential broker; the wiring is up to you.
This contains the secret. The action a compromised agent triggers is a separate concern, addressed by audit logging and rate limiting at the proxy. Treating those as optional is how teams get caught off guard during incident reviews.
Non-deterministic workloads need credentials with non-deterministic lifetimes. OpenBao's secret engines generate credentials on demand and revoke them automatically. Policies grant the agent nothing beyond the ability to request a fresh credential for a specific role.
With a 5-minute TTL and a 30-minute max lease, a credential exfiltrated at minute zero often expires before an attacker can use it. If your detection pipeline flags anomalous behavior, a single bao lease revoke call invalidates all outstanding credentials for that role.
The pattern applies broadly: databases, cloud IAM, PKI, SSH, Kubernetes service account tokens. Wherever you inject long-lived secrets today, a dynamic engine usually exists.
Every workflow gets its own principal and policy, scoped to exactly what it needs. Choose the auth method based on where the agent runs:
We keep our policies minimal and path-scoped, granting access only to the paths the workflow actually touches.
If Agent B manipulates Agent A, the worst case is that Agent A asks OpenBao for something outside its policy. OpenBao denies the request. The boundary holds at the authorization layer, where the agent's behavior is irrelevant to the outcome.
A well-designed OpenBao deployment pays off during incidents. The compromised component never held the real credentials, so most exfiltration stays contained to the agent's narrow scope. Whatever short-lived token it did hold has usually expired before an attacker can act on it, and the audit trail records exactly what was requested for the post-mortem.
Prompt injection will keep finding paths through agent reasoning. The architectural goal is a blast radius you can actually manage.
OpenBao is MPL 2.0, community-governed under the Linux Foundation, with the kind of predictable licensing one of the main reasons teams have moved off proprietary alternatives. That matters if your security architecture needs to remain auditable end-to-end and survive a strategy change at an upstream vendor.
If you are running AI agents in production and your secrets are still environment variables. Adfinis helps teams make this transition end-to-end, from initial credential inventory to operating OpenBao at scale.