Ownership should sit with the identity and platform teams together. IAM or NHI governance should define the trust policy, while platform engineering should operate the collectors and integration points. That split keeps attestation tied to identity governance rather than treated as a purely infrastructure feature.
Why This Matters for Security Teams
workload attestation decides whether an automated workload is actually the system it claims to be, so ownership cannot be left ambiguous. In an identity programme, the risk is not just missing telemetry. It is allowing platform controls, IAM controls, and trust decisions to drift apart until no one can explain who approved a workload, who validated it, or who can revoke it. NHI Management Group has documented how ownership and visibility gaps complicate auditing of machine identities in the Critical Gaps in Machine Identity Management report.
That matters because attestation is the trust anchor for service accounts, agents, microservices, and other non-human workloads. If the identity team does not define what “trusted” means, platform teams often turn attestation into a logging or cluster feature instead of an identity control. Current guidance suggests aligning attestation with workload identity standards such as the SPIFFE workload identity specification, so the programme can make policy decisions from cryptographic proof rather than assumptions. In practice, many security teams discover attestation ownership only after a workload is already running with too much trust.
How It Works in Practice
The cleanest operating model is a split between policy ownership and control operation. IAM, NHI governance, or identity architecture should own the trust model: what a valid workload is, which signals count as proof, how long that proof remains valid, and which downstream services may consume it. Platform engineering should run the collectors, attestation agents, node integrations, and pipeline hooks that gather evidence from hosts, clusters, or runtimes.
That division is especially important when attestation feeds short-lived credentials or runtime access decisions. The identity function should decide whether the workload can receive a certificate, token, or other assertion, while the platform function should ensure the evidence is current and tamper-resistant. NHI guidance increasingly points to workload identity primitives such as SPIFFE and SPIRE, because they provide a consistent cryptographic identity layer that can be evaluated by policy engines and federation layers. The Ultimate Guide to NHIs is useful here because it ties attestation back to lifecycle governance, not just infrastructure automation.
- Identity teams define attestation requirements, trust boundaries, and revocation rules.
- Platform teams deploy node agents, runtime sensors, and integration points that collect evidence.
- Policy should evaluate attestation at request time, not only during provisioning.
- Audit teams need a clear owner for failures, exceptions, and stale attestations.
For implementation, this usually means one control plane for policy and one for collection, joined by a documented interface and a clear handoff for incident response. These controls tend to break down in fast-moving Kubernetes and multi-cloud environments because platform teams own the plumbing while identity teams lack the runtime context to verify what is actually executing.
Common Variations and Edge Cases
Tighter attestation ownership often increases operational overhead, requiring organisations to balance stronger trust guarantees against deployment speed and platform autonomy. That tradeoff becomes visible in edge cases where workloads are ephemeral, highly distributed, or frequently rebuilt.
There is no universal standard for this yet, so best practice is evolving. In some environments, platform security may operate the attestation machinery because it is embedded in the cluster or host layer. Even then, identity governance should still own the policy, exception handling, and revocation model. Otherwise, attestation becomes a technical signal with no accountable decision-maker. The most common failure mode is assuming that if a node or pod is healthy, the workload inside it is automatically trustworthy. That is not a valid identity assumption.
This split is also harder for multi-agent or tool-using systems, where the workload can change behaviour depending on prompts, tasks, or chained tool calls. In those cases, the trust question expands from “what is running?” to “what is this workload authorised to do right now?” That is why attestation should feed runtime authorisation, not substitute for it. The Top 10 NHI Issues and the Guide to SPIFFE and SPIRE both reinforce the same operational point: trust must remain observable, revocable, and tied to ownership across the full workload lifecycle.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Attestation depends on trustworthy NHI lifecycle ownership and identity proof. |
| CSA MAESTRO | A1 | MAESTRO addresses agent and workload trust decisions at runtime across teams. |
| NIST AI RMF | AIRMF governance supports accountability for identity decisions in AI-enabled workloads. |
Assign attestation ownership in NHI governance and require documented trust policy plus revocation paths.
