Agentic Identity with OpenBao

We recently published a deep dive into hardening SPIRE with OpenBao, showing how OpenBao’s PKI and Transit engines can act as the cryptographic root of trust behind a SPIFFE identity plane. That post answers how to secure the infrastructure underneath workload identity. This post steps back a level, to a question that keeps coming up: why does an AI agent need an identity of its own at all? Isn’t sandboxing it, or tightly scoping its permissions, sufficient?

We already have decades of experience securing microservices with least-privilege IAM roles, mTLS, and short-lived tokens. Surely an agent is just another workload that we can secure with the same playbook?

Why standard workload identity isn’t enough

First, let’s focus on auditability. A traditional microservice is deterministic, so its identity can be directly mapped to its function. For example, payments-service calls ledger-service, every time, in the same way. An agentic system doesn’t work like that; instead, a single user prompt might spin up a planner, delegate to several subagents, call out to a code execution sandbox, and query an external API. If all of that is run under a single umbrella identity, then identifying which subagent did what when something goes wrong becomes a frustrating exercise of finding a needle in a haystack. Ultimately, if the system can’t track which agent took what action, you won’t be able to explain failures to your board or compliance teams.

Then there’s the blast radius of a leak. Agents ingest untrusted content, including web pages, documents, and tool output, directly into the same context window as the credentials they hold. Meaning a prompt injection or a careless tool call can exfiltrate a secret in plain text, in a way a conventional service mostly can’t, as it never mixes untrusted input and credentials. Static, long-lived service credentials that would be a minor exposure risk for a normal microservice become a much sharper, asymmetric liability when held by a system designed to read and act on arbitrary content. The consequence is what could have been a routine credential compromise escalating into a mandatory public breach disclosure.

The foundational problem is securing non-deterministic, autonomous agents with IAM patterns built for deterministic microservices. Static roles and long-lived tokens assume you know in advance what a workload will do, whereas agents are explicitly designed to be dynamic and flexible.

This context reframes the identity question itself. Human users and microservices have long used email addresses and third-party service accounts to identify themselves. Should an agent, or a group of agents, have its own email address? Its own GitHub seat? Would a GitHub App be enough, or does that just relocate the same ambiguity? These aren’t settled questions yet, and we don’t think anyone in the industry has a clean answer, but the fact that they’re live questions at all highlights that agent identity needs deliberate thought, not an assumption that existing workload identity covers it.

It’s clear to us that agentic identity is fundamentally still workload identity; the same building blocks apply. Each workload gets an identity, usually a SPIFFE SVID, a JWT, or a TLS certificate, which is authorised under least privilege and is handed a short-lived token scoped to the request. What’s different is the additional considerations which we believe should be layered on top:

• An agent’s authorisation must be ephemeral and scoped per request, since it may need access to a different set of services or credentials for each prompt rather than a fixed set assigned at deployment.
• Its identity has to trace back to the human who initiated the work, not terminate at “the agent platform did it.”
• An agent, or a subagent spun up to handle one step of a task, is transient. It isn’t a permanent or even semi-permanent fixture, unlike a long-running service, and might exist only for the duration of a single tool call.

That points toward a parent-child model: an agent’s identity is a subset of, or chained to, the identity of the human who invoked it, and a subagent’s identity is in turn a subset of its parent agent’s. Authorisation narrows as you go down the chain, never widening.

Proposals and specs worth watching

None of this is being solved in a vacuum. There’s a fast-moving landscape of specs and vendor patterns forming around this problem, and it’s worth looking at the direction each is taking.

On the identity provider side, Okta and Auth0’s cross-app access patterns and Microsoft’s Entra Agent ID both extend the “directory account” model to agents, effectively giving an agent an AD-style identity. This identity model aligns with other controls that are tracked on compliance checklists, but directory accounts weren’t built for authorisation that has to change on every prompt. While this enables a unique identity to be assigned to an agent, it doesn’t on its own close the workload identity gaps identified.

Agent-to-agent (A2A) protocols take a peer-to-peer view instead, handling identity assertion directly between communicating agents rather than routing everyone through a central directory. Where agents call out to tools over Model Context Protocol, MCP authentication via central, secure gateways has emerged as its own pattern: a gateway in front of the MCP server handles authentication, so individual tool servers don’t each have to. This is a different approach to the problem, and provides controls for common audit questions:

• Who can do what? (Authentication)
• What can it do? (Guardrails)
• What did it do? (Observability)

Kubernetes PodCertificates takes yet another infrastructure-native approach: short-lived X.509 certificates issued natively to pods, without requiring a service mesh sidecar. However, we’re not convinced service mesh identity, as it’s commonly deployed today, is actually fit for purpose here. It was built for stable service-to-service traffic, not the bursty, per-request nature of agent calls.

On the authorisation side, two IETF mechanisms already exist and are worth understanding, even though neither is agent-specific by design. RFC 9396 (Rich Authorisation Requests) allows an authorisation server to mint a new JWT carrying a narrower subset of claims and scope than the original, a natural fit for the parent-child narrowing we described above. Separately, RFC 8693 (OAuth Token Exchange) supports delegation by minting an agent JWT “on behalf of” a human, establishing a standard framework for managing downstream agent identity and access delegation. Two competing IETF drafts are also worth watching directly: the AI Identity Management System and the Agent Identity Protocol (AIP) draft. Neither has consolidated as the standard yet, but it’s worth engaging with both now rather than waiting for one to win.

Uber has gone a different route entirely, building their own internal Security Token Service and agent registry rather than waiting on external specs to mature. It’s a useful data point for how a team with the scale to justify it is solving this today.

How OpenBao fits in

OpenBao already covers a meaningful proportion of this today, without any new features. It supports both JWT auth and TLS auth, which means SPIFFE-issued identities can authenticate directly against OpenBao to pull credentials, no additional integration work needed. It can also sit underneath SPIRE itself, handling the cryptographic operations that back SPIRE’s own trust chain, which is the pattern our SPIRE integration post walks through in detail. Open source tooling is the natural foundation for agentic identity, just as it was for workload identity. Directing engineering effort here helps establish solid, widely adopted security patterns early.

Why we’re paying attention to this

This isn’t a topic we’re picking up opportunistically. Our team maintains a leadership role in OpenBao’s development and has been building out its secrets management and secure infrastructure story for some time, alongside deep hands-on SPIFFE/SPIRE integration work. Agentic identity is the next layer on top of the problems we’re already solving for workload identity generally. It just adds what we described above: authorisation that has to be ephemeral, identity that has to trace back to a human, and transience baked in from the start.

Where this goes next

Two things worth doing with this. First, several of the specs above, the IETF drafts especially, are still early enough that outside input matters. If you have a view, contribute or comment on the proposals directly. Second, if you’re wrestling with how to model identity for agents in your own systems and want a design grounded in current best practice rather than vendor lock-in, get in touch. This is exactly the kind of problem we are experts at solving.

Interested in learning more about how we can help you? Check out our AI Security services.