Device Identity Binding Governance requires that sensitive agent governance actions — mandate approvals, configuration changes, emergency overrides, and high-value transaction authorisations — are bound to approved devices or trusted execution contexts. Identity proofing (AG-279) verifies who the person is. Authentication (AG-161) verifies they are the same person who enrolled. Device identity binding adds a third dimension: verifying that the action originates from a trusted device whose integrity can be attested. Without device binding, a perfectly proofed and authenticated human can exercise governance rights from a compromised device — a malware-infected personal laptop, a jailbroken mobile phone, or a virtual machine running on an attacker's infrastructure — undermining the entire governance control chain.
Scenario A — Credential Theft Exploited from Unbound Device: A senior compliance officer's credentials for the agent governance platform are phished through a targeted spear-phishing email. The attacker uses the stolen credentials to log in from their own device — a virtual machine in a cloud data centre. Because the governance platform does not bind sessions to approved devices, the login succeeds. The attacker modifies the mandate for a customer-facing agent, removing the £50,000 per-transaction limit. Over the next 4 hours, the agent processes 17 fraudulent refunds totalling £423,000 before anomaly detection triggers an alert.
What went wrong: The governance platform authenticated the credentials but did not verify the device. The attacker's VM was not an approved device, had no MDM agent, no TPM, and no device certificate. Device binding would have rejected the login because the device was unknown. Consequence: £423,000 in fraudulent refunds, 4-hour detection gap, regulatory investigation, mandatory incident report to the ICO for potential data protection implications.
Scenario B — Compromised Device Exfiltrates Governance Secrets: An agent administrator logs into the governance platform from their personal laptop, which is not managed by the organisation's MDM system. The laptop has a browser extension that the administrator installed for personal use, which contains a keylogger. The extension captures the administrator's session token and the governance configuration they access. The captured session token is replayed from another device to download the complete mandate configuration for all deployed agents, including counterparty allowlists and financial limits.
What went wrong: The governance platform allowed access from an unmanaged device. No device health attestation was required. The compromised browser extension could observe and exfiltrate governance data because the device was outside the organisation's security perimeter. Consequence: Full exposure of agent governance configuration, requiring emergency rotation of all mandates and credentials, 2-week remediation project, board-level incident report.
Scenario C — Rooted Mobile Device Bypasses Approval Controls: An approval workflow requires a mobile push notification that the approver must accept to authorise a high-value agent action. A threat actor roots an approver's Android phone and installs a malicious app that automatically accepts all push notifications. The attacker then triggers 12 approval requests for mandate changes, all of which are auto-approved by the rooted device. The mandate changes collectively raise the agent's daily aggregate limit from £200,000 to £5,000,000.
What went wrong: The approval workflow trusted the device without verifying its integrity. A rooted device can intercept and auto-respond to push notifications, defeating the approval control. Device integrity attestation (SafetyNet/Play Integrity for Android, DeviceCheck/App Attest for iOS) would have detected the rooted status and blocked the approval. Consequence: £4,800,000 increase in daily risk exposure, 12 unauthorised mandate changes, approval workflow demonstrated to be ineffective.
Scope: This dimension applies to every device — physical or virtual — used to perform agent governance actions. This includes: workstations, laptops, mobile phones, tablets, hardware security modules, and virtual machines used by humans to access agent governance platforms; and server hardware, containers, and trusted execution environments hosting agent runtime or governance enforcement infrastructure. The scope is determined by the sensitivity of the action: read-only access to non-sensitive agent metrics may not require device binding, but any action that can modify agent behaviour, approve mandates, override controls, or access sensitive governance configuration is within scope.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
4.1. A conforming system MUST bind high-risk governance actions — including mandate approval, configuration change, emergency override, and high-value transaction authorisation — to devices that have been registered, approved, and attested in a device identity registry.
4.2. A conforming system MUST verify the integrity of the device at the time of each high-risk governance action, using hardware-rooted attestation (TPM, Secure Enclave, or equivalent) where available, or software-based device health checks as a minimum.
4.3. A conforming system MUST reject governance actions from devices that fail integrity attestation, are not registered, or have been revoked from the device registry.
4.4. A conforming system MUST maintain a device identity registry linking each approved device to its hardware identity (e.g., TPM endorsement key, device certificate), the human identity (proofed per AG-279) authorised to use it, and the governance actions it is approved for.
4.5. A conforming system MUST revoke device approval when the device is reported lost, stolen, decommissioned, or compromised, with revocation taking effect within 15 minutes.
4.6. A conforming system SHOULD implement device health attestation that checks for: operating system integrity (no rooting/jailbreaking), current security patches, active endpoint protection, and MDM compliance.
4.7. A conforming system SHOULD bind the authentication session to the specific device using device-bound credentials (e.g., FIDO2 passkeys with device-bound private keys, client certificates in the device's TPM).
4.8. A conforming system SHOULD implement risk-based device trust scoring that considers device posture, location, network context, and historical behaviour when determining whether to permit a governance action.
4.9. A conforming system MAY implement confidential computing or trusted execution environments (TEEs) for agent governance enforcement to ensure that even a compromised host cannot observe or tamper with governance operations.
Identity proofing and authentication establish who is acting. Device identity binding establishes where and how they are acting. This matters because the security posture of the device directly affects the integrity of the governance action. A perfectly authenticated human on a compromised device is a threat actor with valid credentials.
The threat model for AI agent governance includes: credential theft (phishing, malware, insider threat), session hijacking (token theft from compromised browsers or devices), device compromise (malware, rooting, physical tampering), and environment spoofing (virtual machines mimicking trusted devices). Without device binding, the governance platform must trust that any device presenting valid credentials is legitimate — a trust assumption that modern threat landscapes routinely violate.
The rise of FIDO2/WebAuthn and passkey technology has made device binding practical at scale. A FIDO2 passkey generates a cryptographic key pair bound to the device's secure hardware (TPM on Windows/Linux, Secure Enclave on Apple, Titan chip on Google). The private key never leaves the device. Authentication requires both the user's biometric/PIN and the device's hardware — an attacker who steals the password cannot authenticate from their own device, and an attacker who steals the device cannot authenticate without the biometric/PIN.
For AI agent governance, where a single mandate approval can expose the organisation to millions in financial risk, device binding is not an optional security enhancement — it is a structural requirement that closes the gap between "we know who approved it" and "we know the approval was genuine and not coerced or automated by malware."
Device identity binding should integrate with the organisation's existing endpoint management, identity provider, and conditional access infrastructure. The goal is to create a chain of trust from the physical device hardware through the operating system and application layer to the governance action.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. FCA-regulated firms should treat device binding for agent governance with the same rigour as device binding for trading systems. Hardware-attested approvals for mandates exceeding defined thresholds (e.g., £100,000 per-transaction limit changes) provide the evidence trail that regulators expect. MiFID II requirements for recording of communications and orders extend to the device context of governance approvals.
Healthcare. HIPAA requires access controls for systems containing PHI. Where AI agents process PHI under human governance, the devices used for governance actions must meet HIPAA security requirements including encryption, access controls, and audit logging. Device integrity attestation supports the "technical safeguards" requirement.
Critical Infrastructure. IEC 62443 Security Level 3 and above requires authentication of the device as well as the user. Agent governance devices in OT environments should be dedicated, hardened devices that are not used for general-purpose computing.
Basic Implementation — The organisation maintains a registry of approved devices for agent governance access. Governance platform access requires a registered device with a valid client certificate. Device registration requires manual approval by a security team member. Lost or stolen devices are revoked manually upon report. Device health checks occur at login (MDM compliance, OS version). This meets minimum mandatory requirements but relies on manual processes and checks only at session start.
Intermediate Implementation — FIDO2 passkeys are required for governance platform authentication, binding sessions to specific hardware. Conditional access policies enforce device compliance at login and at the point of high-risk governance actions (step-up device attestation). Device health includes real-time posture assessment: OS patch currency, endpoint protection status, jailbreak detection, and encryption status. Device revocation is automated and takes effect within 15 minutes. The audit log records the device identity for every governance action.
Advanced Implementation — All intermediate capabilities plus: hardware-attested governance approvals using TPM-signed approval tokens for actions above defined risk thresholds. TEE-based governance enforcement protects against host-level compromise. Device trust scoring incorporates behavioural analytics (unusual access times, locations, or patterns trigger step-up verification or blocking). Independent adversarial testing confirms that device spoofing, stolen-credential attacks, and compromised-device attacks are detected and blocked. Zero Trust network access ensures no device is trusted by default, regardless of network location.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Unregistered Device Rejection
Test 8.2: Compromised Device Detection
Test 8.3: Device Revocation Timeliness
Test 8.4: Credential Replay from Different Device
Test 8.5: Step-Up Device Attestation for High-Risk Actions
Test 8.6: Hardware Attestation Integrity
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| PSD2 | Article 97 (Strong Customer Authentication) | Supports compliance |
| NIST SP 800-63B | Authenticator Assurance Levels | Supports compliance |
| ISO 27001 | A.8.1 (User Endpoint Devices) | Direct requirement |
| DORA | Article 9 (ICT Risk Management Framework) | Supports compliance |
| IEC 62443 | SR 1.2 (Software Process and Device Identification and Authentication) | Direct requirement |
PSD2 requires Strong Customer Authentication (SCA) for electronic payment transactions, incorporating at least two of: knowledge, possession, and inherence. Device binding provides the "possession" factor through hardware-bound credentials. For AI agents that initiate or approve payment transactions, the human approver's device binding satisfies the possession element of SCA. The dynamic linking requirement (tying the authentication to the specific transaction) maps to AG-281's requirement for hardware-attested approvals bound to specific governance actions.
ISO 27001 Annex A control A.8.1 requires that information stored on, processed by, or accessible via user endpoint devices is protected. Device identity binding ensures that governance actions affecting AI agents are performed only from managed, attested devices, directly implementing this control for the agent governance context.
IEC 62443 requires identification and authentication of all devices that access industrial control systems. For AI agents operating in OT environments, the devices used for governance are part of the control system perimeter and must be identified and authenticated per the required Security Level.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Organisation-wide — a compromised device with valid governance credentials can modify any agent mandate the user has access to |
Consequence chain: Without device binding, credential theft or device compromise gives an attacker full governance access using the victim's valid identity. The attacker can modify agent mandates, approve configuration changes, or authorise overrides from any device — a personal laptop, a cloud VM, or a rogue mobile device. The governance platform sees a valid, authenticated user. The audit log attributes the action to the legitimate human. The organisation cannot distinguish the legitimate user from the attacker. The consequences scale with the governance rights of the compromised identity: an administrator's stolen credentials, used from an unbound device, can reconfigure every agent in the organisation. Device binding reduces this risk by requiring the attacker to compromise both the credentials and the specific physical device, substantially raising the attack cost.
Cross-references: AG-279 (Human Identity Proofing Governance) verifies who the person is; AG-281 verifies the device they are using. AG-280 (Service Identity Proofing Governance) addresses the parallel challenge for automated services, where workload attestation plays the role that device binding plays for human-operated devices. AG-282 (Biometric Spoof Resistance Governance) addresses threats to the biometric factor in device-bound authentication. AG-285 (Session Binding Governance) extends device binding to the session layer. AG-286 (Attested Login Context Governance) records the device and environmental context of each governance session. AG-115 (Strong Authentication for Agent-Initiated Value Transfer) requires device-bound approval for high-value transfers.