137AI > Controls > Identity & Cryptographic Attestation
AI Identity & Cryptographic Attestation
Identity and cryptographic attestation is the engineering practice of giving AI agents, sensors, and components cryptographic identities tied to hardware roots of trust, and using those identities to prove what something is, what state it is in, and that the data it produces is authentic. The discipline is foundational because every other control assumes you know what you are controlling.
Behavioral envelopes assume you can identify which agent the envelope applies to. Access control assumes you can authenticate the requester. Monitoring assumes you can attribute observations to specific agents. Telemetry capture integrity assumes you can verify the sensor source. Identity and attestation is the layer the other controls build on, and the maturity of identity practice in a deployment determines what the other controls can actually accomplish.
The Multiple Identity Layers
Identity in AI agent systems operates at multiple distinct layers, each with its own attestation requirements and each contributing to the overall trust chain. Effective identity practice addresses all layers; gaps at any layer affect what the upper layers can prove.
| Identity Layer | What It Identifies | What It Attests |
|---|---|---|
| Hardware root of trust | The physical hardware platform itself | That the hardware is authentic and has not been tampered with; provides the foundation for all higher layers |
| Device identity | The specific deployed device or system | That a given message, action, or data originated from a specific identifiable device |
| Firmware and software stack identity | The specific firmware version and software components running | That the device is running an authorized software state and has not had its code modified |
| Model identity | The specific AI model in operation, including foundation model, fine-tuning, and version | That the agent is operating with a known and authorized model rather than a substituted or modified one |
| Agent instance identity | The specific running instance of an agent, including its current context and session | That this specific agent instance is the one performing an action or producing output |
| Operator identity | The human or organizational party authorizing the agent's operation | That a specific operator has authorized a specific scope of agent activity |
| User identity | The end user on whose behalf the agent acts | That a specific user has requested a specific action; supports accountability and audit |
| Action authorization | A specific action or transaction the agent is taking | That this specific action has been authorized within the scope granted to the agent; supports irreversibility analysis |
The layers compose. A complete trust chain proves that authorized hardware is running authorized software with an authorized model, the agent instance is identified, the operator has authorized the activity scope, the user requested the specific action, and the action falls within the authorized envelope. Gaps at any layer break the chain, with downstream layers having to either accept the unverified state or fail open.
Cryptographic Primitives Used
The discipline draws from a stable set of cryptographic primitives that have been developed and refined through decades of practice in adjacent fields including secure boot, code signing, financial systems, and government identity systems. The primitives are well-established; the AI-specific application is more recent and still maturing.
| Primitive | What It Does | Typical Use |
|---|---|---|
| Public-key infrastructure (PKI) | Cryptographic key pairs with certificate hierarchy supporting identity, authentication, and signed data | Device identities, code signing, signed data exchange across distributed systems |
| Hardware Security Modules (HSMs) | Tamper-resistant hardware that stores keys and performs cryptographic operations | Operator credentials, fleet management infrastructure, signing key protection |
| Trusted Platform Modules (TPMs) | Hardware component providing platform-level identity and measurement capability | Device identity, secure boot measurement, hardware-anchored attestation |
| Secure enclaves | Isolated execution environments within processors that protect code and data from the host system | Key handling, sensitive AI inference, attestation processing |
| DICE (Device Identifier Composition Engine) | Specification for hardware-rooted device identity, designed for constrained devices including IoT and edge | Sensor identity, edge agent identity, fleet-scale device attestation |
| Signed model artifacts | Cryptographic signatures over AI model files supporting verification of provenance and integrity | Foundation model distribution, fine-tuned model deployment, model supply chain |
| Remote attestation protocols | Protocols that allow a remote verifier to confirm a device's hardware, software, and state | Cloud-to-edge attestation, fleet management verification, third-party attestation |
| Hardware-attested signing of data | Cryptographic signatures over data produced by sensors or agents, with keys tied to hardware identity | Telemetry attestation, action authorization, audit log integrity |
Application Across Agent Categories
The identity and attestation discipline takes specific forms across the agent categories that recur on this site. Each category has its own deployment patterns, maturity level, and operational priorities.
In autonomous vehicles, identity and attestation is partly addressed through UN-R 155 cybersecurity requirements and the broader vehicle security stack. Each vehicle has device identity. Each software component is signed. OTA updates require cryptographic verification. Sensor identity is less consistently implemented; cross-validation across sensor modalities partially substitutes for cryptographic sensor attestation. Fleet management orchestration layers carry their own identity infrastructure with operator credentials protected through HSMs at the more mature operators.
In humanoid robots, identity and attestation practice is at earlier maturity. Most current humanoid platforms are operator-supervised in industrial pilots where the operator's local controls substitute for distributed attestation. As humanoid deployment scales and reaches less-supervised contexts, the attestation requirements approach those of autonomous vehicles, with device identity, signed software, and authorized action scope all becoming foundational.
In drones and UAS, identity and attestation operates partly through Remote ID requirements that establish drone identity to ground observers and air traffic infrastructure. Drone identity for command-and-control authorization is operator-specific and varies in maturity. Defense and high-end commercial drone operations have substantial attestation discipline; consumer drone operations have less.
In ambient sensors and IoT devices, the DICE specification provides the standard approach to hardware-rooted device identity for constrained devices. Implementation across consumer ambient devices is uneven; some smart home device manufacturers implement DICE or equivalent practice, others operate without hardware-rooted identity.
In software AI agents, identity and attestation operates primarily through credential management, OAuth and similar frameworks for delegated authority, and operator-side controls. Model identity through signed model artifacts is becoming more common for foundation model distribution. Agent instance identity is less developed; most current agent frameworks do not provide strong instance attestation.
In medical devices, identity and attestation practice is more developed because of established FDA SaMD framework expectations and medical device security regulations. Device identity, signed software updates, and attestation of clinical data integrity are operational requirements for many deployed AI medical devices.
The Supply Chain Dimension
Identity and attestation extends backward into the supply chain. The agent operating today reflects choices made by hardware manufacturers, firmware vendors, foundation model providers, training data sources, fine-tuning data sources, and AI vendor libraries. Compromise at any link in this chain affects the deployed agent, and attestation that does not reach into the supply chain provides only partial assurance.
Hardware provenance attestation supports verification that the hardware is what the vendor says it is. Counterfeit chips, modified hardware, and supply chain interception all affect deployed systems. Hardware vendor attestation infrastructure has been developing through industry initiatives including the Trusted Computing Group work and equivalent practice in vendor ecosystems.
Software supply chain attestation supports verification of the software stack including firmware, operating system, and application components. Software bill of materials (SBOM) practices and signed software delivery are increasingly required by procurement frameworks including the US Executive Order 14028 and equivalent practice in other jurisdictions.
AI bill of materials practices extend SBOM principles to AI components. The AI BOM identifies the foundation models, fine-tuning data, training data sources, AI vendor libraries, and model artifacts that contribute to the deployed agent. Standards work on AI BOM is ongoing through several industry consortia and the practice is at early adoption.
Foundation model attestation is a specific concern given the supply chain dimension of foundation models. A foundation model that has been poisoned upstream produces downstream effects across every operator that uses the model. Cryptographic signing of foundation models, third-party audit of foundation model providers, and attestation that downstream operators can verify are emerging practices. The broader treatment of training data poisoning supply chain risk appears in Training Data Poisoning.
Training data provenance is a parallel concern. Training data acquired from sources with weak provenance practice produces models whose integrity depends on the unverified data. Cryptographic provenance for training data including signed data delivery, verified contributor identity, and curation discipline are practices that mature operators are adopting.
The Protocol and Standards Landscape
Several specific protocols and standards define identity and attestation practice for AI agents and related systems. The landscape is fragmented across hardware, software, AI-specific, and regulatory dimensions.
Trusted Computing Group standards including TPM 2.0, DICE, and the broader Trusted Computing Architecture provide foundational hardware-anchored identity. Implementation varies across vendors and product categories.
UN-R 155 and the WP.29 framework establish cybersecurity and software update management requirements for connected vehicles, with identity and attestation as foundational elements. The framework applies in markets that follow UN regulations.
The EU AI Act addresses some attestation-relevant requirements through Article 11 technical documentation, Article 13 transparency obligations, and Article 15 cybersecurity requirements. The specific cryptographic implementation is left to industry practice and harmonized standards.
NIST has produced extensive cybersecurity guidance including SP 800-63 on digital identity, SP 800-155 on hardware-rooted security, and the broader Cybersecurity Framework, with AI-specific extensions emerging through NIST AI Risk Management Framework work.
ISO/IEC standards including ISO/IEC 11889 on TPM specifications, ISO/IEC 19790 on cryptographic module security, and AI-specific work through SC 42 contribute to the international standards landscape.
FIDO Alliance work on passwordless authentication and device identity has produced widely-adopted protocols including WebAuthn and CTAP. The AI agent extension of FIDO practice is at early stage.
OpenID Connect, OAuth 2.0, and related identity federation standards provide the foundation for user and operator identity in many AI agent deployments. AI-specific extensions including agent identity tokens are emerging in industry practice.
Industry-specific standards including ISA/IEC 62443 for industrial automation, DO-326A for aviation, and IEC 62443 for ICS provide identity and attestation guidance within their domains.
What Identity and Attestation Does Not Solve
The discipline has real limits that practitioners should understand. Identity and attestation is foundational, but it is not a complete defense against the threat landscape.
Identity does not solve correctness. An authentic, authorized agent operating with attested software and verified model can still produce incorrect output, take wrong actions, or fail in ways that the attestation does not catch. Behavioral envelopes, monitoring, and the other controls layers address what identity does not.
Attestation does not solve compromise of the trust anchors. If the hardware root of trust is compromised at manufacture, if the signing keys are exfiltrated, or if the certificate authority is breached, the attestation infrastructure produces valid-looking attestations of compromised systems. The defensive posture against trust anchor compromise involves separate practice including HSM protection, key rotation, certificate transparency, and supply chain security.
Identity does not bound action authority. A correctly identified and attested agent with overly broad permissions can do more than the operator intended. Permission scoping and behavioral envelopes operate at a different layer to address this.
Attestation cost can be substantial. The cryptographic operations, key infrastructure, and verification overhead consume computational resources and operational complexity. Operators balance attestation depth against capability and cost, with the balance varying by deployment context. Highly constrained edge devices may implement reduced attestation; high-stakes deployments may implement more.
Identity does not solve the prompt injection problem. A software agent that is correctly identified and operating with authorized software can still be manipulated through prompt injection in its inputs. The defensive layer for prompt injection operates on the agent's instruction handling rather than its identity.
Attestation does not solve unknown vulnerabilities. Hardware vulnerabilities discovered after deployment, cryptographic algorithm weaknesses that emerge over time, and implementation bugs all affect attestation systems. The discipline includes ongoing maintenance and migration practices rather than one-time deployment.
Operational Considerations for Operators
Operators implementing identity and attestation as a control discipline face several recurring operational considerations.
Key management at scale is the foundational operational challenge. A fleet of thousands or millions of devices, each with its own identity keys, requires infrastructure for key generation, distribution, rotation, revocation, and recovery. HSM-protected operator credentials, automated key lifecycle management, and well-defined recovery procedures are essential for operational sustainability.
Attestation verification infrastructure operates at the cloud or edge side of the deployment. Verifiers need to maintain trust roots for the device population, process attestation reports at deployment scale, and handle anomalies and exceptions. The infrastructure is itself an operational system that requires monitoring and maintenance.
Identity lifecycle management addresses the full lifecycle from manufacturing to decommissioning. New devices need identity provisioning; deployed devices need ongoing key management; compromised or end-of-life devices need revocation. The lifecycle discipline matures over time as operators accumulate experience.
Cross-vendor interoperability affects multi-vendor deployments. Devices from different manufacturers with different identity infrastructures need to interoperate where the deployment combines them. Industry standards and shared trust roots support interoperability; vendor-specific implementations limit it.
Backwards compatibility for deployed device populations affects how attestation practices can evolve. Devices already in operation with older attestation implementations need to continue operating while new devices use more current practices. Migration strategies and bridging mechanisms address this.
Regulatory documentation and audit support is increasingly required. Identity and attestation infrastructure is subject to documentation requirements under the EU AI Act, conformity assessment procedures, and sector-specific regulations. Maintaining the documentation alongside the operational infrastructure is part of the discipline.
The Reframe
Identity and cryptographic attestation is the foundational control on which every other control depends. The discipline addresses the multiple layers of identity that AI agent systems involve from hardware roots of trust through action authorization, draws on a stable set of cryptographic primitives that decades of adjacent practice have developed, and extends into the supply chain through emerging AI bill of materials and foundation model attestation work. The maturity of identity practice across agent categories is uneven; medical devices and connected vehicles have more developed practice, software agents and consumer ambient devices have less. The protocol and standards landscape is fragmented but converging through industry and regulatory work. The discipline has real limits and is not a complete defense, but it is the layer that makes the rest of the Controls pillar possible. Operators investing in identity and attestation infrastructure are investing in the foundation that all subsequent controls work depends on.
Related Coverage
Controls | Telemetry Capture Integrity | The OTA Loop as Attack Surface | Training Data Poisoning