Enterprises have spent a decade getting human identity right. Multi-factor authentication, single sign-on, conditional access, continuous verification — the zero-trust apparatus around people is genuinely mature. In the same decade, the number of non-human identities in the average enterprise quietly exploded past the number of human ones, and almost none of that rigor followed them. Service accounts, API keys, machine credentials — the identities that actually do most of the work in a modern system — were left on static secrets: long-lived, over-privileged, shared, rarely rotated, and largely unmonitored. The most sophisticated identity programs in the world have a soft underbelly, and it is made of machines.
AI is the sharpest edge of that problem. An AI workload is a non-human identity with unusual properties: it is powerful, because it touches sensitive data and makes consequential decisions; it is dynamic, because it is often ephemeral and distributed; and increasingly it is autonomous, because agentic systems act on their own, calling tools, reaching services, and taking steps without a human in the loop for each one. An over-privileged, weakly-identified AI workload is the highest-stakes non-human identity an enterprise can have. Getting its identity right is not a hygiene task. It is the foundation the rest of a sovereign AI system stands on.
This article is about extending zero trust to the thing doing the work, not just the person authorizing it — and about the mechanism that makes it possible: attestation. It is the keystone the other enforcement surfaces of AI Sovereignty Architecture depend on. Governing what an AI workload can reach, segmenting it from the data plane, gating its execution in the kernel — all of it presupposes that you can answer one question with cryptographic confidence: what is this workload, really?
The non-human identity problem
The reason machine identity lagged is structural. Human identity systems are built around things humans have — a password, a phone, a managed device, a face. Machines have none of those. So the industry reached for workarounds: the service account with a stored password, the API key baked into a config, the shared secret passed between systems. Each of these is a credential a workload asserts — “I am service X, here is the secret that proves it.” And each has the same fatal properties: the secret is static, so it does not expire on its own; it is often shared, so its use cannot be attributed to a specific instance; it is long-lived, so a theft goes undetected for months; and it carries no posture, so nothing checks whether the thing presenting it is actually what it claims to be or has been tampered with.
For ordinary service accounts this is bad enough. For AI workloads it is untenable, because the blast radius of a compromised or impersonated AI identity is the sensitive data and consequential decisions the AI was trusted with.
The three decisions, applied to a workload
Zero trust, correctly understood, is not a product; it is the discipline of keeping three decisions separate every time something requests access — validate that the request is authentic and unaltered, authenticate that the identity is known and current, and authorize the specific action against policy. (Zero trust is a decision, not a product makes that case in full.) The model was never specific to humans. It applies without modification to a workload asking to act — but it exposes a gap the human version never had to solve.
A human can prove identity by presenting something. A workload cannot present a password without immediately reintroducing the static-secret problem. So the authenticate step, for a workload, cannot rest on an asserted secret. It has to rest on something the workload cannot fake and cannot carry away: a verified claim about what the workload actually is. That is attestation, and it is the difference between a machine identity that is asserted and one that is proven.
Attestation: identity you verify, not identity you assert
Attestation inverts the credential model. Instead of a workload presenting a secret that asserts its identity, the identity system verifies what the workload is — based on measurable properties of the workload and the platform it runs on — and only then issues it a credential. The workload does not tell the system who it is and ask to be believed. The system determines what the workload is and issues an identity accordingly.
This mechanism is proven and standardized, which is the point worth emphasizing. The SPIFFE standard and its SPIRE runtime do exactly this at production scale: a workload is attested against selectors describing its process and platform, and on success it receives a short-lived verifiable identity document — an SVID — that it uses to authenticate. Crucially, that credential is short-lived by design, expiring in minutes. Short lifetime makes freshness automatic: a stolen credential dies on its own timer, and revocation is handled largely by expiry rather than by racing to invalidate a long-lived secret. The static-secret problem dissolves, because there is no static secret. There is a continuously re-verified identity that is only ever valid for the next few minutes.
For AI workloads, this is transformative. An attested workload identity means the system can state, with cryptographic confidence and continuous freshness, which AI workload is acting — not which service account’s shared key was presented, but which specific, verified instance. Attributable AI is impossible without it.
Identity is not integrity
There is a distinction here that a rigorous system must keep separate, because collapsing the two is a genuine vulnerability. Identity answers what is this workload. Integrity answers is this workload actually running what it should be, and behaving as it attested. They are different claims, and they require different mechanisms.
A workload can have a perfectly valid identity and still have been tampered with after it was attested. It can authenticate correctly and then begin behaving in ways its attested profile never described. So attestation is not a one-time gate at startup; it is paired with continuous integrity verification — measuring whether the running workload still matches what it attested to, and treating drift as a signal that the identity’s validity is now in question. Identity established at enrollment, integrity checked continuously at runtime. (Real-time workload enforcement with ISE and eBPF describes how that runtime integrity check is enforced at the kernel.) A system that verifies identity but assumes integrity is trusting that nothing changed after the door opened — which, for a workload that can be subverted in place, is exactly the wrong assumption.
The sovereign difference
Standard workload attestation roots its trust in a self-managed certificate authority. AI Sovereignty Architecture takes the same proven mechanism and roots it in an air-gapped anchor — so the chain that establishes every workload’s identity terminates in a root no third party controls. This is the difference between an attested identity you manage and an attested identity that is sovereign: its validity does not depend on trusting a cloud provider’s key, a vendor’s CA, or any authority outside your own air-gapped root.
That rooting is what makes the workload identity suitable as the foundation for provable AI. When an AI workload’s identity — and by extension its outputs and decisions — traces to a signing root you hold offline in tamper-resistant hardware, the resulting provenance is independently verifiable by anyone with the public key, with no intermediary to trust. (The design of that air-gapped root inside an AI pipeline is a subject we treat separately.) The proven attestation mechanism supplies the identity; the sovereign root makes the identity yours.
The keystone the rest depends on
Attestation is foundational rather than optional because every other enforcement surface in the architecture consumes it. When a cloud-delivered access layer decides whether an AI workload may reach a data resource, it evaluates the workload’s attested identity — that is the identity SASE needs to govern a workload as a client. When segmentation policy determines an AI workload’s isolation envelope, it follows the attested identity rather than the network address, which is what lets the isolation travel with the workload across environments. When the kernel gate decides whether to permit a workload’s system call, it checks the workload’s attested state. One attested identity, established once and continuously re-verified, is what every surface reads to make its decision.
This is why the identity dimension is the keystone. Reach control, execution control, and isolation are all downstream of it. If the identity is asserted rather than proven, every enforcement decision built on it is only as strong as a shared secret — which is to say, not strong at all. If the identity is attested and sovereign, every decision built on it inherits that strength.
Why this matters
Three payoffs, each of which the static-secret model cannot deliver. Attribution: an attested workload identity lets an organization state which specific AI workload took a given action, which is the precondition for “prove what the AI did” — the question regulators and risk committees increasingly ask, and one that shared service-account keys make unanswerable. Least privilege for autonomous systems: as AI grows more agentic, the authority granted to an AI identity must be scoped tightly and verified continuously; attestation is what makes tight, revocable, per-instance authorization possible for software that acts on its own. A contained attack surface: replacing long-lived shared secrets with short-lived attested identities removes the single most exploited category of non-human-identity weakness, and does so precisely for the workloads that can least afford it.
Zero trust was never only about people. The industry started there because people were the identities it knew how to reason about. But the identities that do the work — and increasingly, the identities that make the decisions — are non-human, and the most consequential of them are AI workloads. Extending zero trust to them is not an add-on to the discipline. It is the discipline, finally reaching the thing that matters most: not the person who authorized the AI, but the AI itself, proven rather than assumed.
Ready to apply this?
Talk to Acclivity about your security posture.
Four security practices delivered today. One category being defined. We run the AI Sovereignty Architecture reference implementation on our own infrastructure, hardening it for enterprise scale with partners.