Deploying SPIFFE/SPIRE for AI agents means making three decisions before writing any policy: trust domain boundaries, the attestation policy that governs which properties earn a workload an SVID, and whether and how domains federate. Get those three right and the deployment scales cleanly as agent fleets grow across clusters and clouds. Get them wrong and you end up with a trust domain too broad to mean anything, or attestation loose enough that a compromised container looks identical to a legitimate one.
Trust domain design
A SPIFFE trust domain is the root of the naming and trust hierarchy — every SPIFFE ID issued within it shares that domain as its namespace (spiffe://trust-domain/...), and every SVID in it is signed by that domain's own certificate authority. The domain is the unit of trust, not the individual workload: anything that can prove membership in the domain and matches an attestation policy gets issued an identity within it.
For agent deployments, the practical question is how many trust domains to run. The common starting pattern is one trust domain per organizational or operational security boundary — production and staging as separate domains, and a genuinely separate business unit or a separately-operated agent platform as another. Splitting further, down to one domain per team or per agent fleet, buys stronger blast-radius containment (a compromised SPIRE server or CA in one domain cannot mint valid identities for another) at the cost of more federation relationships to manage. Most agent deployments land on a small handful of domains: rarely one for the whole company, rarely one per team, most often aligned to environments and to any genuinely separate agent platforms operated by different teams with different security postures.
Attestation policy: what earns an SVID
SPIRE issues SVIDs based on attestation — verifying properties of the workload requesting an identity before deciding what SPIFFE ID to grant it. Node attestation verifies the underlying host or cluster (a Kubernetes node's identity, a cloud instance's identity document); workload attestation then verifies the specific process on that node (its Kubernetes service account, its container image, its process attributes) before selecting which registration entry — and therefore which SPIFFE ID — applies.
The attestation policy decision that matters most for agent workloads is which properties to key on. Attesting only on a Kubernetes service account is the loosest useful option: it's simple to operate, but if ten different agents run under the same service account, they attest identically and receive the same SPIFFE ID, which collapses exactly the distinction covered in mTLS, SPIFFE, and workload identity for agents — one runtime identity standing in for many logical agents. Attesting additionally on image digest ties the identity to specific, verified code: a supply-chain compromise that swaps the running image shows up as an attestation failure rather than as normal traffic, a property covered in more depth in securing the agent supply chain. For agent fleets specifically, the practical recommendation is one registration entry per agent where the deployment topology allows it, keyed on service account plus image digest rather than service account alone.
Federation: crossing trust domain boundaries without merging them
Agents rarely stay inside one trust domain. An agent deployed in one cluster calling a tool hosted in another, or two organizations' agents needing to authenticate each other for a cross-org workflow, both need a way to trust identities minted by a different domain's CA without collapsing the two domains into one.
SPIFFE federation solves this by having trust domains exchange and periodically refresh each other's trust bundles — the set of public keys each domain uses to sign its SVIDs — so a workload in domain A can cryptographically verify an SVID issued by domain B's SPIRE server, without domain A's SPIRE server ever issuing identities on domain B's behalf. Each domain keeps its own registration policy, its own attestation rules, and its own operational boundary; federation only extends the ability to verify, not the ability to issue.
For agent deployments spanning clouds, this is the practical answer to the workload-identity half of cross-cloud operation: rather than trying to run one trust domain across providers (operationally awkward, since node attestation mechanisms differ by cloud) or falling back to shared secrets between clouds (exactly what workload identity was meant to remove), each cloud or cluster runs its own domain and federates the ones that need to talk to each other. Cross-organization agent calls follow the same shape at a coarser grain, and the governance layer on top of the federation relationship — deciding which calls a federated identity is actually authorized to make, not just which ones it can cryptographically prove — is covered in cross-org agent federation with trust manifests.
Operational pitfalls that show up first
SVID lifetime tuned for convenience, not security. Short SVID lifetimes (minutes) are the point of the system — they make a leaked SVID self-limiting. Extending lifetimes to reduce renewal traffic or debug friction quietly gives back the property that makes the whole model worth deploying. Tune renewal margins instead of extending TTLs.
Authorization policy is a separate layer to add. SPIRE issues identities; deciding who may talk to whom is a policy decision that sits on top of it. Deploying SPIRE and calling identity "done" without writing restrictive service-to-service authorization policy on top produces a fleet of workloads that are all authenticated and all still able to reach each other — the mesh-without-policy trap covered in the authorization section of mTLS, SPIFFE, and workload identity for agents.
Rotation that has never been exercised under load. SVID renewal is continuous by design, but a renewal path that has never been tested against real traffic volume, node churn, or a SPIRE server restart is a renewal path that will surface its failure mode during an incident rather than during a planned test. Force early expiry in a staging environment before trusting it in production.
Registration entries that outlive the workload. A registration entry for a decommissioned agent that is never removed is a standing credential-issuance path with no purpose — the workload-identity equivalent of the orphaned credentials described in NHI credential lifecycle management. Decommissioning an agent should include removing its registration entry as a required step, not an afterthought.
What good looks like
- Trust domain boundaries match real operational and security boundaries — environments, and genuinely separately-operated agent platforms — not an arbitrary split that adds federation overhead without adding isolation.
- Attestation keys on image digest plus node/service-account identity for agent workloads, not service account alone, so a supply-chain compromise is visible as an attestation failure.
- Federation, not merged trust domains, is the mechanism for cross-cluster and cross-cloud agent calls, keeping each domain's registration and attestation policy independent.
- Default-deny authorization policy sits on top of SPIFFE identity for every service-to-service path, evaluated separately from the identity issuance itself.
- Registration entries are removed as part of agent decommissioning, and SVID renewal has been exercised under simulated failure, not just assumed to work.
Sizing the deployment for agent scale
Agent fleets stress a SPIRE deployment differently than a fixed set of long-running services does. Autoscaling agent workers means a higher rate of node and workload attestation events than a typical microservice fleet of the same size, since agent instances can spin up and tear down far more often. Plan SPIRE server capacity and the agent-to-server ratio with that churn rate in mind rather than extrapolating from a services-only deployment, and monitor attestation latency specifically — a slow attestation path becomes a startup bottleneck for every new agent instance under load, which is a different failure mode than a slow attestation path being merely an inconvenience for a small number of long-lived services.
It's also worth deciding early where the SPIRE agent itself runs relative to agent workloads that may themselves be sandboxed or run in restricted containers for tool-execution safety, per tool use safety and sandboxing agent actions. A sandbox tight enough to block the local Unix socket SPIRE workloads use to fetch their SVID needs an explicit exception carved out, or the sandboxing and the identity layer end up fighting each other.
Common questions
How many trust domains should an agent platform run? Start with one per environment (production, staging) plus one for any separately-operated agent platform with its own security posture. Split further only when a specific team or fleet needs independent operational control over its own SPIRE server and CA, since each additional domain adds a federation relationship to maintain.
Does SPIFFE/SPIRE tell you which logical agent made a request? SPIRE issues identity to the workload — the runtime process — not to a logical agent inside it, and this is the most common misunderstanding in agent deployments. If many agents share a deployment, they share a SPIFFE ID, and distinguishing them requires a separate, application-level agent identity carried in the request, as described in how to give an agent an identity.
Is a service mesh required to run SPIFFE/SPIRE? No. SPIRE issues SVIDs to workloads independently of any mesh, and applications can use them directly for mTLS or token acquisition. A mesh adds transparent mTLS and centralized policy enforcement without application changes, which is convenient at scale but not a prerequisite for adopting the identity layer itself.