Key Compromise, Signer Duress and Emergency Downgrade Governance

2. Summary

Key Compromise, Signer Duress and Emergency Downgrade Governance requires that every AI agent controlling or interacting with cryptographic keys — private keys, multisig signers, HSM-managed keys, or MPC key shares — operates within a governance framework that detects key compromise, identifies signer duress conditions, and manages emergency security downgrades without creating exploitable windows. In blockchain environments, key compromise is the terminal failure mode: a compromised private key grants irrevocable, unlimited access to all assets controlled by that key. Unlike traditional systems where compromised credentials can be revoked by a centralised authority, blockchain key compromise often cannot be remediated — stolen funds are gone. This dimension requires containment controls that detect compromise indicators, constrain the blast radius of a compromised key, and ensure that emergency downgrade procedures (e.g., reducing multisig thresholds, rotating keys, migrating assets) do not themselves become attack vectors.

3. Example

Scenario A — Compromised Hot Wallet Key Drains Treasury: An AI treasury management agent uses a hot wallet with a single private key to execute daily operations: paying contributors, funding liquidity pools, and bridging assets. The key is stored in an environment variable on the agent's compute instance. An attacker compromises the instance through an unpatched dependency, extracts the private key, and drains the treasury of 4,200 ETH ($7.56M at $1,800/ETH) in a single transaction. The agent detects the balance anomaly 3 minutes later, but the transaction is already confirmed on-chain with 12 block confirmations.

What went wrong: A single key controlled the entire treasury with no value limits, no time-lock, and no anomaly detection at the transaction level. The key was stored in plaintext in an environment variable accessible to any process on the instance. No governance control existed to limit the blast radius of a single key compromise. Consequence: $7.56M in irrecoverable asset loss, protocol insolvency, governance crisis, team dissolution.

Scenario B — Signer Duress Compromises Multisig: A 3-of-5 multisig governs a DeFi protocol's upgrade mechanism. An attacker physically locates and coerces one signer, then uses social engineering to convince a second signer that an emergency upgrade is needed ("the protocol is under active exploit — we need to deploy a patch immediately"). The coerced signer provides their signature under duress. The socially engineered signer provides their signature believing the request is legitimate. The attacker supplies the third signature from their own compromised key. The malicious upgrade is executed, inserting a backdoor into the protocol's smart contracts. The attacker drains $23M from the protocol over the following 72 hours through the backdoor.

What went wrong: No duress signal mechanism existed for signers to indicate they were signing under coercion. No time-lock on upgrade transactions allowed other signers to review and potentially veto. No anomaly detection flagged that three signatures were collected within 4 minutes when the historical median was 6 hours. The multisig treated all valid signatures as freely given. Consequence: $23M in stolen assets, protocol trust collapse, legal liability for signers, regulatory investigation.

Scenario C — Emergency Downgrade Creates Exploitation Window: A protocol detects a potential key compromise and initiates an emergency key rotation. The rotation procedure requires temporarily reducing the multisig threshold from 3-of-5 to 2-of-5 to account for the compromised key being excluded. During the 45-minute window where the threshold is lowered, the attacker — who had compromised two keys, not just one — executes a malicious transaction with the reduced 2-of-5 threshold. The emergency procedure designed to contain the compromise was itself the exploitation vector.

What went wrong: The emergency downgrade procedure reduced security thresholds without assessing whether the reduced threshold was still safe given the scope of the compromise. No governance control enforced that emergency downgrades could not reduce the quorum below a minimum safety threshold. The incident response assumed a single-key compromise when the actual compromise was broader. Consequence: Assets drained during the emergency response window, compounding the initial compromise into total loss.

4. Requirement Statement

Scope: This dimension applies to all AI agents that hold, manage, sign with, or interact with cryptographic keys controlling blockchain assets, smart contract permissions, or protocol governance authority. This includes agents operating hot wallets, agents participating in multisig signing, agents managing HSM-connected signing infrastructure, agents holding MPC key shares, and agents that submit transactions requiring key-based authorisation. The scope extends to agents that manage key rotation, key generation, or key backup processes. Agents that interact with blockchain data in a read-only capacity without holding or using keys are excluded.

4.1. A conforming system MUST implement key tiering such that no single key controls assets exceeding a defined value threshold. Hot wallet keys MUST be limited to operational float requirements (e.g., 24-hour anticipated transaction volume), with remaining assets in cold storage or time-locked contracts requiring multi-party authorisation.

4.2. A conforming system MUST enforce per-key and per-transaction value limits at the infrastructure layer, independent of the agent's instructions. A hot wallet key with a $50,000 daily limit MUST NOT be capable of signing a transaction exceeding that limit, regardless of agent behaviour.

4.3. A conforming system MUST implement a duress signal mechanism that allows any multisig signer to indicate they are signing under coercion. The duress signal MUST appear as a valid signature to the coercer but MUST trigger an automatic security escalation — halting the transaction, alerting other signers, and initiating the incident response protocol.

4.4. A conforming system MUST enforce minimum time-locks on security-critical operations (key rotation, threshold changes, large transfers) of at least 24 hours for operations affecting > $100,000 in assets and at least 72 hours for operations affecting > $1M. Time-locks MUST NOT be bypassable by any single party.

4.5. A conforming system MUST detect anomalous signing patterns including: (a) signature velocity exceeding historical baselines, (b) signatures at unusual times (e.g., 3 AM local time for a signer whose historical pattern is business hours), (c) signatures from unusual IP addresses or geographic locations, and (d) multiple signatures collected within a timeframe significantly shorter than the historical median.

4.6. A conforming system MUST ensure that emergency security downgrades (e.g., reducing multisig thresholds) cannot reduce the quorum below a pre-defined minimum safety threshold. The minimum safety threshold MUST be set during normal operations and MUST NOT be modifiable during an active incident.

4.7. A conforming system MUST implement automated asset migration to a pre-configured safe harbour address or contract when a confirmed key compromise is detected. The safe harbour MUST require higher-security authorisation (e.g., cold storage multisig) than the compromised key.

4.8. A conforming system SHOULD implement key compromise canaries — low-value transactions or state changes that, if observed, indicate key access by an unauthorised party. Canaries should be monitored continuously with automated alerting.

4.9. A conforming system SHOULD implement dead-man-switch mechanisms that automatically escalate security posture (e.g., increase multisig threshold, pause agent operations) when expected periodic signer check-ins are missed.

4.10. A conforming system MAY implement social recovery mechanisms that allow a qualified majority of trusted parties to authorise key rotation without the compromised key's participation, subject to time-lock and notification requirements.

5. Rationale

In blockchain systems, cryptographic keys are the ultimate authority. There is no password reset, no account recovery through customer support, and no court order that can reverse a transaction signed with a valid key. This finality makes key compromise the most consequential failure mode in crypto/Web3 environments. The cumulative losses from key compromise in DeFi exceeded $1.7 billion between 2020 and 2024, making it the single largest category of protocol exploit by dollar value.

The containment control type reflects the reality that key compromise often cannot be prevented entirely — it can only be detected quickly and its blast radius constrained. A well-governed system assumes that any individual key may be compromised at any time and designs its security architecture accordingly. This is the principle of defence in depth applied to key management: no single key compromise should be capable of causing catastrophic loss.

Signer duress is an underappreciated attack vector specific to blockchain's high-value, pseudonymous environment. Unlike traditional financial systems where coercion of an employee triggers institutional safeguards (dual controls, manager approval, regulatory reporting), blockchain multisig systems typically treat all valid signatures as equivalent. A signature obtained through physical coercion is cryptographically indistinguishable from a freely given signature. The governance requirement for duress signals addresses this gap by providing a mechanism for coerced signers to trigger security escalation without alerting the coercer.

Emergency downgrade procedures represent a paradox: the response to a security incident often requires temporarily reducing security controls, which creates exactly the window that attackers exploit. The requirement for minimum safety thresholds and time-locks on downgrades addresses this paradox by ensuring that emergency procedures cannot reduce security below a pre-defined floor, even when responding to an active compromise.

AI agents amplify key management risk because they may hold keys in runtime memory, store them in configuration files, or access them through APIs with inadequate access controls. An agent that holds a key with unlimited signing authority represents a single point of failure that can be exploited through any vulnerability in the agent's software stack, infrastructure, or supply chain.

6. Implementation Guidance

Key governance in blockchain environments requires a layered architecture that separates key storage, signing authorisation, and transaction execution into distinct security domains with independent access controls.

Recommended Patterns:

• Key tiering with value-bounded hot wallets. Implement a three-tier key architecture: (1) hot wallets for operational float, holding no more than 24-hour anticipated volume, with per-transaction limits enforced at the signing infrastructure layer; (2) warm wallets requiring 2-of-3 multisig for medium-value operations, with 4-hour time-locks; (3) cold storage requiring 3-of-5 multisig with 72-hour time-locks and geographic distribution of key shares. The agent interacts only with the hot wallet tier. Replenishment from warm to hot is a separate, human-approved process.
• Duress-aware signing protocol. Implement a signing protocol where each signer has two keys: a primary signing key and a duress key. The duress key produces a signature that is cryptographically valid but includes a steganographic marker detectable by the verification infrastructure. When a duress signature is detected, the system accepts the signature (to avoid alerting the coercer) but triggers a silent escalation: the transaction is delayed, other signers are alerted through a separate channel, and the incident response protocol activates. The duress key is known only to the signer and the verification infrastructure.
• Time-locked governance with veto windows. Implement all security-critical operations (key rotation, threshold changes, contract upgrades) as time-locked proposals with a veto window. During the time-lock period, any authorised party can veto the proposal. This converts a race condition (attacker vs. defender) into an asymmetric defence: the attacker must prevent detection during the entire time-lock period, while the defender needs to detect the attack at any point during that period.
• Automated safe harbour migration. Pre-configure a safe harbour contract or address that requires higher-security authorisation than the agent's operational keys. When a compromise is detected — through anomalous signing patterns, canary triggers, or explicit reporting — automated systems initiate migration of assets from the compromised key's control to the safe harbour. The migration transaction is pre-signed during normal operations and stored in a secure, separate system.
• Compromise canary network. Deploy small-value assets (e.g., $10 each) to addresses derived from each operational key. Monitor these canary addresses continuously. If a canary balance changes without authorised activity, the key is presumed compromised and containment procedures activate immediately. Canary monitoring should operate on independent infrastructure from the agent's operational systems.

Anti-Patterns to Avoid:

• Storing private keys in environment variables, configuration files, or source code. This is the most common and most exploitable key management failure. Any process with access to the environment or filesystem can extract the key. Keys should be stored in HSMs, secure enclaves, or at minimum encrypted at rest with the decryption key in a separate security domain.
• Implementing multisig without time-locks on critical operations. A multisig without time-locks provides quorum protection but no veto capability. If an attacker obtains the required number of signatures — through compromise, duress, or social engineering — the malicious transaction executes immediately. Time-locks convert instantaneous exploit into a race that defenders can win.
• Reducing multisig thresholds during emergencies without minimum floor enforcement. Emergency procedures that reduce the multisig threshold can be exploited by attackers who engineer the emergency specifically to trigger the threshold reduction. The minimum safety threshold must be immutable during incidents.
• Treating key rotation as a complete remedy for compromise. Key rotation addresses future access but does not address assets that were compromised before the rotation. A compromised key may have signed pre-dated transactions that are submitted after rotation. Time-locks and nonce management are necessary complements to rotation.
• Using the same key for multiple purposes (e.g., operational transactions and governance votes). A key that serves multiple purposes has a blast radius equal to the union of all its authorities. Key separation ensures that compromise of an operational key does not grant governance authority.

Industry Considerations

DeFi Protocol Treasuries. Protocol treasuries often hold $50M-$500M in assets governed by a small multisig (typically 3-of-5 or 4-of-7). Key governance for treasuries should include geographic distribution of signers, regular proof-of-life checks, duress protocols, and time-locked withdrawals above threshold amounts.

Centralised Exchange Custody. Exchanges holding user deposits face regulatory requirements for key management (e.g., proof of reserves, segregation of client assets). Key governance must integrate with regulatory reporting and demonstrate that no single key compromise can cause systemic user fund loss.

Bridge Operators. Bridge keys control the minting and burning of wrapped assets. A compromised bridge key can mint unbacked wrapped tokens, causing insolvency across all protocols that accept those tokens as collateral. Bridge key governance requires the highest tier of protection: distributed MPC, hardware attestation, and multi-chain monitoring.

Maturity Model

Basic Implementation — The organisation uses multisig for high-value operations. Hot wallet keys have per-transaction limits enforced at the signing layer. Keys are stored in encrypted form (not plaintext). Basic monitoring detects large balance changes. Key rotation is performed on a scheduled basis (e.g., quarterly). This level provides baseline protection but lacks duress detection, anomalous signing pattern analysis, and emergency downgrade safeguards.

Intermediate Implementation — Key tiering with value-bounded hot wallets is implemented. Anomalous signing pattern detection operates continuously. Time-locks are enforced on all security-critical operations. Minimum safety thresholds prevent emergency downgrades below a floor. Compromise canaries are deployed and monitored. Duress signal mechanisms are available to all multisig signers. Incident response procedures are documented and rehearsed quarterly.

Advanced Implementation — All intermediate capabilities plus: MPC key management with hardware attestation. Automated safe harbour migration activates on confirmed compromise. Social recovery mechanisms are available for key rotation without the compromised key. Dead-man-switch mechanisms escalate security when signer check-ins are missed. Independent adversarial testing has verified that emergency downgrade procedures cannot be exploited. Geographic distribution of key shares across jurisdictions with independent legal regimes.

7. Evidence Requirements

Required artefacts:

• Key architecture documentation. Diagram and specification of key tiers, value limits per tier, signing authority per key, and separation between agent operational keys and governance keys. Format: structured document with architecture diagrams.
• Duress protocol specification. Documentation of the duress signal mechanism including how duress keys are generated, distributed, and verified, and what actions the system takes on duress detection.
• Key compromise incident response plan. Step-by-step procedure for responding to confirmed and suspected key compromise, including safe harbour migration, key rotation, threshold management, and communication protocols.
• Signing anomaly detection log. Continuous log of signing events with anomaly analysis results, including flagged events, investigation outcomes, and false positive rates. Minimum 12 months retention.
• Emergency downgrade audit trail. Records of all threshold changes, key rotations, and security downgrades with justification, authorising parties, and duration. Minimum 12 months retention.
• Key compromise drill results. Results from periodic (at least quarterly) key compromise simulation exercises, including time-to-detection, time-to-containment, and asset-at-risk during the containment window.

Retention requirements:

• Key architecture documentation and incident response plans: maintained current and version-controlled. Historical versions retained minimum 7 years for regulated financial services; minimum 3 years otherwise.
• Signing logs and drill results: minimum 7 years for regulated financial services; minimum 3 years otherwise.

Access requirements:

• Producible to regulators, protocol governance bodies, or auditors within 48 hours of request.

8. Test Specification

Test 8.1: Key Tiering Value Limit Enforcement

• Stimulus: Attempt to sign a transaction exceeding the hot wallet's per-transaction limit (e.g., $60,000 against a $50,000 limit).
• Expected behaviour: The signing infrastructure rejects the transaction. The agent cannot bypass the limit.
• Pass criteria: No transaction exceeding the per-key value limit is signed, regardless of agent instructions.
• Fail criteria: The signing infrastructure permits a transaction exceeding the configured limit.

Test 8.2: Duress Signal Detection and Escalation

• Stimulus: A signer uses their duress key to sign a multisig transaction.
• Expected behaviour: The signature appears valid. The transaction is silently delayed. Other signers are alerted through a secure channel. The incident response protocol activates.
• Pass criteria: Duress is detected without alerting the coercer. Escalation activates within 60 seconds.
• Fail criteria: The duress signal is not detected, or the transaction executes without escalation.

Test 8.3: Time-Lock Enforcement on Critical Operations

• Stimulus: Submit a key rotation proposal for a key controlling $500,000 in assets.
• Expected behaviour: The rotation enters a time-lock period of at least 24 hours. The rotation cannot execute before the time-lock expires. Any authorised party can veto during the window.
• Pass criteria: The time-lock is enforced. No bypass mechanism allows early execution.
• Fail criteria: The rotation executes immediately or the time-lock can be bypassed.

Test 8.4: Anomalous Signing Pattern Detection

• Stimulus: Submit 50 signing requests in 5 minutes from a key whose historical baseline is 3 signatures per hour.
• Expected behaviour: The anomaly is detected after the first few signatures exceed the baseline. Subsequent signatures are blocked or escalated for review.
• Pass criteria: Anomalous velocity is detected and contained within 5 signatures of the baseline breach.
• Fail criteria: All 50 signatures execute without detection or escalation.

Test 8.5: Minimum Safety Threshold During Emergency Downgrade

• Stimulus: Initiate an emergency multisig threshold reduction from 3-of-5 to 1-of-5, where the minimum safety threshold is configured at 2-of-5.
• Expected behaviour: The reduction is permitted only to 2-of-5. The request to reduce to 1-of-5 is rejected.
• Pass criteria: The minimum safety threshold cannot be breached during emergency operations.
• Fail criteria: The threshold is reduced below the safety floor.

Test 8.6: Safe Harbour Migration on Compromise Detection

• Stimulus: Trigger a compromise canary (move funds from a canary address without authorisation).
• Expected behaviour: The canary trigger is detected within 60 seconds. Automated safe harbour migration initiates for assets controlled by the associated key. Migration requires only the pre-configured safe harbour authorisation.
• Pass criteria: Asset migration to the safe harbour completes before an attacker can execute further transactions with the compromised key.
• Fail criteria: The canary trigger is not detected, or safe harbour migration fails to activate.

Test 8.7: Emergency Downgrade Cannot Be Weaponised

• Stimulus: Simulate an attacker who has compromised 2 of 5 keys and engineers a false alarm to trigger an emergency threshold reduction.
• Expected behaviour: The minimum safety threshold prevents reduction below 2-of-5, ensuring the attacker's 2 compromised keys cannot achieve quorum even during the emergency.
• Pass criteria: The emergency procedure does not create an exploitation window for the attacker.
• Fail criteria: The emergency procedure reduces the threshold to a level that the attacker can exploit.

Conformance Scoring

• Score 0: No key governance exists — single keys control high-value assets with no value limits, no multisig, and no compromise detection.
• Score 1: Multisig is used for high-value operations. Basic value limits exist. Keys are encrypted at rest. Monitoring detects large balance changes.
• Score 2: Key tiering with infrastructure-enforced value limits. Anomalous signing detection operates continuously. Time-locks on critical operations. Minimum safety thresholds prevent dangerous downgrades. Duress signals are available.
• Score 3: Verified by independent adversarial testing. Automated safe harbour migration. MPC with hardware attestation. Dead-man-switch and social recovery mechanisms. Quarterly compromise drills demonstrate containment within target timeframes.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 15 (Accuracy, Robustness, Cybersecurity)	Supports compliance
MiCA	Article 67 (Prudential Requirements)	Direct requirement
MiCA	Article 70 (Safeguarding of Clients' Crypto-Assets)	Direct requirement
DORA	Article 9 (ICT Risk Management Framework)	Direct requirement
DORA	Article 11 (ICT Response and Recovery)	Direct requirement
NIST Cybersecurity Framework	PR.AC (Access Control), DE.AE (Anomalies and Events)	Supports compliance
ISO 27001	A.10 (Cryptographic Controls)	Direct requirement
FCA SYSC	6.1.1R (Systems and Controls)	Supports compliance

MiCA — Article 70 (Safeguarding of Clients' Crypto-Assets)

MiCA Article 70 requires crypto-asset service providers to make adequate arrangements to safeguard clients' crypto-assets. This includes requirements for segregation, independent custody, and protection against loss. Key governance is the primary technical control for safeguarding crypto-assets — without proper key management, no amount of policy or procedure can prevent asset loss. AG-200's requirements for key tiering, value limits, duress protection, and compromise containment directly implement the technical controls necessary for Article 70 compliance.

DORA — Article 11 (ICT Response and Recovery)

DORA Article 11 requires financial entities to establish ICT response and recovery policies. Key compromise is a critical ICT incident requiring rapid response. AG-200's requirements for automated safe harbour migration, compromise canaries, and time-limited emergency procedures directly support DORA Article 11 compliance by ensuring that key compromise incidents are detected, contained, and recovered from within defined timeframes.

ISO 27001 — A.10 (Cryptographic Controls)

ISO 27001 Annex A.10 requires policies on the use of cryptographic controls and key management. AG-200 extends these requirements to the specific challenges of blockchain key management — where key compromise is irrecoverable and where the value controlled by keys is directly quantifiable. The tiering, duress protection, and emergency downgrade governance requirements go beyond ISO 27001's general cryptographic control requirements to address blockchain-specific risks.

NIST Cybersecurity Framework — PR.AC, DE.AE

The NIST CSF's Protect/Access Control and Detect/Anomalies and Events functions map directly to AG-200's key tiering (access control for cryptographic authority) and anomalous signing detection (anomaly detection for key usage patterns). AG-200 provides blockchain-specific implementation of these framework functions.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Protocol-wide — potentially ecosystem-wide for bridge operators or major protocol treasuries

Consequence chain: Key compromise in blockchain systems is the terminal failure mode. A compromised private key grants irrevocable access to all assets controlled by that key. The immediate technical failure — unauthorised signing authority — enables immediate, irreversible asset theft at blockchain speed. Unlike traditional financial systems where fraudulent transactions can be reversed through bank processes, court orders, or regulatory intervention, blockchain transactions are final. The financial impact is bounded only by the total value controlled by the compromised key or keys. Historical precedent demonstrates the scale: Ronin Bridge ($624M, March 2022), Harmony Bridge ($100M, June 2022), and Atomic Wallet ($100M, June 2023) all resulted from key compromise. The blast radius extends beyond direct asset loss: a compromised bridge key undermines the security of all wrapped assets on the destination chain, a compromised governance key enables malicious protocol upgrades, and a compromised treasury key causes protocol insolvency. The reputational and legal consequences include: user fund loss liability, regulatory enforcement action, criminal investigation for inadequate safeguarding, and potential personal liability for protocol operators under emerging regulatory frameworks.

Cross-references: AG-008 (Governance Continuity Under Failure) governs the fail-safe requirement when key infrastructure is compromised. AG-027 (Governance Override Resistance) ensures that key governance policies cannot be overridden by agent instructions. AG-014 (External Dependency Integrity) addresses the integrity of external signing services and HSM providers. AG-198 (Oracle Integrity) addresses oracle-specific key compromise risks where oracle operator keys are the target. AG-199 (MEV, Order-Flow Privacy and Adversarial Routing Governance) addresses order-flow risks that are amplified when private relay keys are compromised. AG-201 (Governance Token Capture and Proposal/Execution Mismatch Governance) addresses the governance-level consequences of key compromise enabling token capture.