The identity problem AI created
Enterprise access control was designed around people. A human authenticates in the morning, receives a session, and works inside a role that a manager approved. Machine accounts were the exception, and they were static enough to be governed by review cycles.
Autonomous AI changes the shape of the problem. Agents act continuously, spawn sub-tasks, call tools and APIs, and read data across systems at machine speed, without a human in the loop at the moment of action. Treating them as service accounts with broad standing credentials creates exactly the failure mode security teams fear: a powerful, long-lived identity whose behaviour nobody can attribute after the fact.
The requirement is therefore not stronger login for people, but identity and authorisation for every actor — human, service, device, and agent — evaluated at the moment of each action.
Cryptographic identity for every actor
In a Zero Trust AI cloud, identity is a cryptographic artefact rather than a directory entry. Each actor is issued a certificate bound to attributes that matter for authorisation: what it is, who operates it, what jurisdiction it belongs to, and what class of data it may touch.
Because these identities must remain valid across the lifetime of infrastructure that outlives current cryptographic assumptions, certificates use post-quantum signatures — Dilithium, the lattice-based scheme selected in the NIST post-quantum standardisation process — rather than relying solely on classical elliptic-curve or RSA signatures. Long-lived infrastructure identity, signed audit records, and firmware attestation are precisely the artefacts most exposed to retrospective forgery, which makes them the right place to adopt post-quantum signing first.
Devices and accelerators obtain their identities during provisioning, tied to platform attestation. Agents obtain theirs at instantiation, derived from the workload that created them, so an agent's authority is always traceable to a signed parent workload and an accountable operator.
Continuous verification, not one-time authentication
Authentication establishes who is asking. It does not establish whether this particular action should proceed. Continuous verification closes that gap by evaluating every request against current state: the actor's identity and attributes, the attested state of the platform it runs on, the classification of the data requested, and the action envelope the actor was granted.
An envelope is deliberately narrow and explicit. A fraud-model agent may read a feature store, train inside an enclave, and write a scored result; it may not open an outbound network connection, copy weights, or widen its own permissions. Requests outside the envelope are denied at the infrastructure layer, where the agent has no ability to appeal, and each decision is recorded with the claims that produced it.
Verification is also revocable in real time. Failed re-attestation, anomalous behaviour, a change of data classification, or an operator action withdraws authority immediately rather than at the next credential rotation.
Secure GPU enclaves
Identity controls who acts. Enclaves control what the platform can see while acting. Training and inference run inside secure GPU enclaves where memory, model weights, and data flows are isolated from other tenants and from the infrastructure operator's own administrative paths.
Data enters an enclave under policy, is processed against an attested workload, and leaves only through declared outputs. The practical consequence is that proprietary models — often the most valuable asset a regulated institution holds — are never exposed to shared multi-tenant surfaces, and the operator cannot become the weakest link in its customer's IP protection.
Enclave state is itself attested and recorded, so a customer can show an auditor not only that isolation was configured, but that it held for a given workload at a given time.
The result
The combination is a cloud in which every actor is identified, every action is authorised against a bounded envelope, every platform is attested, and every decision is evidenced. Autonomous AI becomes deployable in regulated environments because its authority is explicit and its behaviour is attributable.
For the security team, this replaces periodic access review with continuous, provable control. For the institution, it makes AI capability compatible with audit obligations — and keeps proprietary models inside the perimeter that gives them value.
