Organizations are rapidly deploying autonomous AI agents that execute complex toolchains, call external APIs, and read corporate data stores on behalf of real users. As the surface area of non-human identity (NHI)explodes, securing the identities powering these agents has become a primary security hurdle. Over time, SPIFFE and SPIRE have emerged as the leading open source standard and framework for workload identity, but the identity of an agent, or any other workload, means little if the infrastructure underpinning it has not been properly secured.

In this post, we’ll examine how the security of the identity plane can be enhanced by integrating SPIRE with OpenBao’s PKI and Transit secrets engines. By shifting the cryptographic heavy lifting to a centralised, hardened boundary, you can achieve true zero-exposure key management without changing how downstream clients interact with SPIRE.

SPIRE Meets OpenBao

SPIRE relies on a flexible plugin architecture to handle attestation, data storage, and key management. Traditionally, a SPIRE server might generate and store its server CA and JWT signing keys locally on disk. To improve upon this, we can leverage OpenBao by using two SPIRE plugins:

• Upstream authority “vault” plugin - used to integrate with OpenBao’s PKI secrets engine.
• Key manager “hashicorp_vault” plugin - used to integrate with OpenBao’s Transit secrets engine.

It is worth noting the naming convention here: while these SPIRE plugins are named vault and hashicorp_vault, OpenBao’s API compatibility with Vault generally makes it a seamless, drop-in replacement. You get the benefits of an open source, community-driven secrets manager without needing to rewrite your architectural specifications.

Configuring OpenBao as an Upstream Authority for SPIRE

A mature enterprise architecture requires SPIRE to hook into a centralised, corporate Public Key Infrastructure (PKI). This can be done using the upstream authority “vault” plugin, which allows SPIRE to delegate the signing of its intermediate CA to OpenBao’s PKI secrets engine.

In the SPIRE configuration example below, rather than relying on static, long-lived credentials to authenticate the SPIRE server to OpenBao, we can utilise Kubernetes native authentication. SPIRE leverages the short-lived, time-bound projected service account token automatically mounted by Kubernetes to seamlessly log in to OpenBao and exchange a Certificate Signing Request (CSR).

UpstreamAuthority "vault" {
    plugin_data {
        vault_addr = "https://openbao.openbao-server:8200"
        ca_cert_path = "/etc/ca/openbao-ca.pem"

        pki_mount_point = "pki" 

        k8s_auth {
            k8s_auth_mount_point = "kubernetes"
            k8s_auth_role_name = "spire"
            token_path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
        }
    }
}

Securing SPIRE’s private keys

While the upstream authority configuration above secures the certificate chain, the raw private keys used by SPIRE to sign workload X.509 SVIDs and JWTs could still traditionally reside within SPIRE’s own runtime memory or host storage. If an attacker gains root access to the underlying SPIRE server, those keys are at risk. The introduction of the Hashicorp_Vault KeyManager plugin completely changes this risk profile by leveraging OpenBao’s Transit secrets engine.

The Transit secrets engine acts as “Cryptography as a Service.” Instead of SPIRE generating keys locally, OpenBao generates and keeps the private keys strictly inside its own secure boundary. The raw private keys never leave OpenBao. When a workload requests an identity document, SPIRE sends the raw payload to OpenBao, which signs it remotely and returns the signature.

Here is how you configure the KeyManager plugin, utilising the same Kubernetes token authentication:

KeyManager "hashicorp_vault" {
    plugin_data {
        vault_addr = "https://openbao.openbao-server:8200"
        ca_cert_path = "/etc/ca/openbao-ca.pem"

        transit_engine_path = "transit"
        key_identifier_value = "spire"

        k8s_auth {
            k8s_auth_mount_point = "kubernetes"
            k8s_auth_role_name = "spire"
            token_path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
        }
    }
}

Ironclad Agent Identity

Even a total compromise of the SPIRE server host yields no private key material to an attacker. Furthermore, every signing operation now generates an audit log entry within OpenBao, giving your security operations team visibility over exactly when and how identity documents are minted.

Another benefit of this approach is reduced secrets sprawl. Sensitive key material used to secure agent identities is kept where it should be, and once an agent has been issued an identity, it can use that identity to authenticate with OpenBao and retrieve the other credentials needed to access the myriad of systems required to perform its tasks.

As AI agents gain autonomy across enterprise environments, combining SPIRE’s attestation power with OpenBao’s cryptographic boundaries ensures your non-human identity plane is audit-ready and resilient by design.

Ready to future-proof your identity platform? Reach out to ControlPlane’s security experts for hands-on guidance or explore ControlPlane Enterprise for OpenBao to run OpenBao with full production support.