Provisioning and Attestation: Issuing, Binding, and Proving an Agent's Identity

Consider the moment an autonomous agent first comes into existence: a fresh process or container, holding no secret, that must somehow obtain a credential proving who it is. If the platform simply hands it a long-lived key baked into an image, that key is copyable, leaks through the image registry, and identifies every copy identically — the very failure that machine identity was meant to avoid. If instead the platform demands the agent authenticate to receive its first credential, we have a regress: authenticate with what? This is the bootstrapping problem, sometimes called the secret-zero problem, and it is the reason provisioning an agent's identity is not a matter of distributing keys but of establishing evidence. The mechanism that breaks the regress is attestation, and getting it right is what separates an identity you can trust from a name anyone can claim.

The Bootstrapping Problem: Secret Zero

An identity system for agents must answer a deceptively simple question: how does a workload that holds no credential obtain its first one, safely? The naive answers all fail. Embedding a shared secret in the deployment artifact makes that secret the identity of every instance built from it, so a leaked image compromises the whole population and no instance is distinguishable from another. Passing a secret through an environment variable or orchestration parameter moves the problem rather than solving it, because whatever channel delivers the secret is now the thing that must be authenticated. Manually provisioning each agent contradicts the defining property of agent fleets — that principals are created and destroyed by automation faster than any human process can act.

The regress only breaks if the authority can decide to trust a brand-new workload based on something other than a secret the workload presents. That something is evidence about the workload itself: what platform it is running on, what code it is, what labels or attributes the orchestration layer has assigned it. If the authority can independently verify such evidence, it can issue a credential to a workload it has never met, without any pre-shared secret changing hands. Reframing provisioning this way — from 'deliver a key' to 'verify evidence, then mint a key' — is the conceptual move the rest of this article builds on.

This is a recognizable pattern from human identity, and naming the analogy sharpens it. NIST SP 800-63-3, the Digital Identity Guidelines, separates identity proofing — establishing that a person is who they claim before any credential is issued — from authentication, the later act of proving you hold the credential. Attestation is identity proofing for workloads: the one-time (or continuous) establishment of what a workload is, on which the issuance of an authenticator depends. The difference is that a workload's evidence is not a passport or a utility bill but verifiable facts about its execution environment.

Attestation, Defined

Attestation is the production of evidence about the properties of a running workload, together with the verification of that evidence by a party that decides whether to act on it. Two roles matter: the attester, which produces or gathers the evidence, and the verifier, which checks it against a policy. The evidence is a set of claims about the workload — the platform identity of the machine it runs on, the identity of the software, attributes assigned by the orchestrator — that the verifier can corroborate through a channel the workload does not control.

The crucial distinction is between attestation and assertion. An assertion is a claim a party makes about itself: 'I am workload X.' Anyone can assert anything, so an assertion alone carries no trust. Attestation is a claim corroborated by evidence the claimant cannot freely forge, because the verifier obtains or checks it independently. When a workload asserts 'I am the payments agent' and the verifier confirms, through the platform, that the process making the request is the one the orchestrator launched with the payments label, the assertion has been attested. The SPIFFE specification (the Secure Production Identity Framework For Everyone) formalizes exactly this: a workload does not name itself; an issuing infrastructure determines the workload's identity by attesting its properties and only then binds a name to it.

Attestation strength is therefore a function of how hard the evidence is to forge, not of how confidently it is asserted. Evidence rooted in something the workload cannot fabricate — a platform's own identity API, a hardware root of trust, an orchestrator's authenticated record — yields strong attestation. Evidence the workload can shape, such as a self-reported hostname or an environment variable it sets, yields weak attestation that a malicious workload can spoof. This gives a concrete design rule: every selector in an attestation policy should be evaluated by asking who controls it.

Two-Layer Attestation: Node then Workload

Robust workload attestation is naturally two-layered, and the SPIFFE/SPIRE architecture makes the layering explicit. The first layer is node attestation: establishing the identity of the machine, virtual machine, or cluster node on which workloads run. A node proves itself using a platform-provided credential the node operator does not mint by hand — a cloud instance-identity document signed by the platform, a hardware-rooted key, or a Kubernetes-issued token — so the authority learns which node it is talking to on strong evidence. Node attestation happens once per node and anchors everything above it.

The second layer is workload attestation: on an already-attested node, determining which specific workload is making a request. Here the attester runs as a trusted local component with the privilege to inspect the caller — reading the calling process's attributes from the operating system, or querying the orchestrator for the labels of the container the caller belongs to. Because this inspection is performed by a trusted agent on an attested node, and reads facts the workload cannot rewrite about itself, the resulting evidence is strong. The workload never gets to simply declare its own identity; it is observed.

The layering matters because it composes trust. A workload identity is only as trustworthy as the node attestation beneath it: if the node's platform credential can be forged, every workload identity on it is suspect. Treating the two layers as a pipeline — node evidence gates workload evidence gates credential issuance — makes the dependency visible and auditable, and localizes any weakness to a specific layer rather than diffusing it across the system.

The Attestation Handshake

Seen over time, provisioning is a short exchange with a strict order. A newly started workload contacts a local attesting agent — the only component it can reach without already holding a credential — and requests an identity. The agent gathers evidence about the caller: it inspects the calling process or container to collect selectors, and it presents the node's own already-established attestation to the central authority. The authority evaluates the combined evidence against its registration policy, decides which identity (if any) the workload is entitled to, mints a short-lived credential for that identity, and returns it down the chain to the workload.

Two properties of this handshake are worth making explicit. First, the workload proves nothing by assertion; it is the local agent, trusted by virtue of running on an attested node, that furnishes the evidence. The workload's only 'proof' is that it is reachable at the local endpoint and exhibits the selectors the agent observes. Second, the credential the authority returns is bound to a key — typically the workload generates a fresh key pair and the authority issues a credential over the public key — so that the returned artifact is useless to anyone who intercepts it without also holding the private key. This is proof-of-possession, and it is what stops a credential from being a bearer secret.

The ordering is not incidental. Node attestation must precede workload attestation, which must precede issuance; reversing any step reintroduces the bootstrapping regress or lets an unattested caller receive an identity. A correct implementation enforces the sequence and refuses to issue if any prior step is missing or stale.

Selectors and the Attestation Policy

The heart of workload attestation is the selector: an attribute of a workload that the attesting agent can observe and the authority can require. Selectors range from operating-system facts about a process to orchestrator-assigned labels on a container to properties of the node. An attestation policy is a registration rule that maps a set of required selectors to an identity: if a caller exhibits exactly these selectors, it is entitled to this identity, and otherwise it is not. Issuance is precisely the evaluation of this policy against observed evidence.

Writing selector policies is where security is won or lost, because selectors differ enormously in forgeability. A selector the workload controls — a self-declared label it can set at launch — is weak: a malicious workload can present it and impersonate a peer. A selector rooted in something external — a signed platform attribute, an image digest the registry vouches for, an orchestrator record the workload cannot alter — is strong. The design rule from the definition of attestation applies directly: for each selector in a policy, ask who controls its value, and require enough independently-controlled selectors that no single forgeable attribute is sufficient to obtain an identity.

The decision the authority makes is genuinely binary at the point of issuance — the evidence either satisfies the policy for some identity or it does not — but the policy behind it should be conjunctive and defense-in-depth: multiple corroborating selectors, each hard to forge, combined so that impersonation requires forging all of them at once.

Binding: From Evidence to Credential

Attestation decides that a workload is entitled to an identity; binding ties the issued credential to that specific workload so the credential cannot be lifted and replayed by another. The mechanism is proof-of-possession. Rather than issuing a bearer token — a secret that authenticates anyone who holds it — the authority issues a credential over a key the workload possesses and does not share. In the SPIFFE model the issued document, an SVID, binds the workload's name to its key; presenting the SVID is only convincing when accompanied by proof the presenter controls the corresponding private key.

This is why binding is the property that makes the earlier machine-identity requirements real. A credential bound to a workload-held key is not a copyable secret: intercepting it in transit yields nothing without the private key, and the private key never leaves the workload. The signed structure carrying the identity and its claims can be a JSON Web Token (RFC 7519), whose subject, audience, and expiry fields state who the credential is for, who may accept it, and when it stops being valid — or an X.509 certificate binding the name to the key. Either way, the binding is cryptographic, not a matter of trusting the network path.

Binding also enables safe delegation later. Because the OAuth 2.0 Token Exchange mechanism (RFC 8693) lets a bound credential be exchanged for a new one that names a different subject and records an actor, an attested, key-bound identity can be the root of a delegation chain in which every hop remains attributable. The strength of that whole chain is inherited from the attestation and binding established at provisioning time, which is why this first step deserves the rigor.

The Chain of Trust

Every attested identity rests on a chain that terminates in a root the system chooses to trust without further proof. At the base is a platform or hardware root — a cloud provider's signing key, a hardware security module, a trusted platform module — whose authority is axiomatic within the deployment. Node attestation extends trust from that root to a specific node. Workload attestation extends it from the node to a specific workload. The issued credential is the visible tip of this chain, and its trustworthiness is exactly the trustworthiness of the weakest link beneath it.

Thinking in layers clarifies where assurance comes from and where it can fail. If the platform root is compromised, everything above is void. If node attestation accepts forgeable node evidence, workload identities on that node are unfounded. If workload selectors are weak, the node is trustworthy but the specific workload identity is not. Because the layers stack, assurance is the minimum across them, not the sum — a single weak layer caps the trust of the whole chain regardless of how strong the others are.

This layered view is the operational form of the zero-trust principle in NIST SP 800-207: trust is never inherited from position but must be established, per layer, on verifiable evidence. Provisioning is where that evidence is first gathered, so the discipline applied here sets the ceiling on how much any downstream control can trust the identity it is handed.

Failure Modes and Threats to Validity

The account here is an architectural synthesis of established workload-identity practice, not an empirical evaluation, and its guarantees are conditional. The strongest condition is selector quality: attestation reduces exactly to the forgeability of the selectors a policy requires, and a policy that leans on a workload-controlled attribute inherits that attribute's weakness no matter how sophisticated the surrounding machinery. A second condition is the local attesting agent's own integrity — it is a trusted component that observes callers, so its compromise forges evidence at will; it must itself be strongly attested and tightly scoped.

There are also failure modes the mechanism does not close. Attestation establishes what a workload is at issuance; a time-of-check-to-time-of-use gap remains if a workload's relevant properties can change after it is attested but before or while it uses the credential, which is one reason credentials are kept short-lived and re-attested rather than issued once. And attestation says nothing about whether a correctly-identified agent will behave well: a genuinely-attested payments agent that has been hijacked still holds a valid, bound identity. Provisioning gives the system a trustworthy answer to 'which workload is this'; it deliberately leaves 'is this workload behaving as intended' to the behavioral and lifecycle controls that operate on top of the identity it establishes.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

registration:
  identity: spiffe://trust-domain/payments-agent
  require_node_attested: true          # gate on node layer first
  selectors:                            # ALL must match (conjunctive)
    - image_digest: sha256:...          # controller: registry (strong)
    - k8s:sa: payments                  # controller: cluster API (strong)
    - k8s:ns: prod-payments             # controller: cluster API (strong)
  reject_if:
    - only_selectors_of_kind: [self_label]   # workload-controlled alone (weak)
  credential:
    proof_of_possession: true           # bind to workload-held key
    ttl: 300s                           # short-lived; re-attest to renew

Glossary

Bootstrapping (secret-zero) problem

The paradox that a workload seems to need a credential in order to securely obtain its first credential.

Attestation

The production of hard-to-forge evidence about a workload's properties together with its verification by a party that decides whether to act on it.

Assertion

A self-made claim about identity, carrying no trust on its own because anyone can assert anything.

Node attestation

Establishing the identity of the machine or node a workload runs on, using a platform-provided credential the operator does not hand-mint.

Workload attestation

Determining which specific workload on an attested node is making a request, by observing selectors the workload cannot rewrite about itself.

Selector

An observable attribute of a workload that an attestation policy can require, ranging from strong (externally controlled) to weak (workload controlled).

Binding / proof-of-possession

Tying a credential to a key the workload holds, so presenting the credential requires proving control of that key rather than mere possession.

Chain of trust

The stack from a platform or hardware root through node to workload whose overall assurance equals its weakest link.

References

1. SPIFFE — Secure Production Identity Framework For Everyone, specification (CNCF)
2. SPIFFE ID and SVID specification (CNCF)
3. NIST SP 800-207, Zero Trust Architecture (2020)
4. NIST SP 800-63-3, Digital Identity Guidelines (2017)
5. IETF RFC 7519, JSON Web Token (JWT)
6. IETF RFC 8693, OAuth 2.0 Token Exchange
7. OWASP Agentic Security Initiative, Agentic AI Threats and Mitigations (2025)
8. NIST AI 100-1, AI Risk Management Framework (AI RMF 1.0)