AI Agent Wallet Key Security: Authority, Recovery and Quantum Migration

“The key cannot leave the enclave” and “the agent cannot drain the treasury” are different statements. The first concerns extracting a secret. The second concerns what a valid signature is permitted to authorise. A signer can keep its key confidential and still approve a malicious, mistaken or excessively broad instruction.

That distinction becomes more consequential during a key rotation. Replacing a signer can leave approvals, recovery keys, owner permissions or alternative execution routes unchanged. A migration is complete only when the intended new authority works and the retired authority no longer works within the declared scope. Merely generating another secret proves neither.

Claim versus the implementation evidence

Separate four security questions

Secret custody: where can usable signing material exist? Include creation, backups, restoration and diagnostics. An environment variable can be exposed through a compromised process or host; its presence does not prove every breach causes immediate total loss. Conversely, moving signing into hardware does not establish that every other control is sound.

Transaction authority: which operations will the account accept? A destination allowlist alone may be inadequate if the approved destination can transfer arbitrary assets, upgrade itself or forward calls. Review the semantics of the permitted method and arguments, not only the destination address.

Administrative authority: who can replace the validator, expand a policy, install an executor or alter a delegation? ERC-7579 describes different module roles, including validators and executors. Its interfaces are not a universal implementation of a particular spending policy. The document reviewed here is marked Draft. [4]

Recovery authority: who can regain control when the normal signer is unavailable? An emergency path is part of the wallet’s security boundary. A system advertised as independently threshold-controlled may have a recovery process administered by one organisation. That is an evidence question, not an accusation about any provider.

What attestation does—and what the reviewer must still do

AWS describes attestation documents containing measurements and identity-related information, signed within the Nitro trust structure. Its guidance requires a relying service to validate the document and define the protocol that gives the intended guarantees. An arbitrary attestation blob is not enough. [5]

For an agent signer, identify the approved image, the verifier’s freshness mechanism, policy inputs and the authority that may replace the image. If a compromised host can supply an apparently permitted but economically harmful transaction, protected memory alone does not decide whether it should be signed. The verifier must bind the attested identity to the exact trust decision being made.

The previous article also grouped several hardware technologies under a blanket EAL5+ label. We withdraw that claim. An assurance claim must identify its certificate, evaluated target and configuration. The Common Criteria portal lists certifications against particular products and security targets; a generic architecture name does not supply that evidence. [6]

Threshold signing is a distribution of trust

NIST’s threshold programme defines distributed computation using secret-shared key material and calls for specifications, implementations and evaluation evidence. It does not award all products labelled MPC a common security level. [3]

A useful deployment review asks whether the participants have independent administration, credentials and failure domains. Three services controlled by one compromised administrative account are different from three independently governed signers. The numerical threshold tells you how many shares participate; it does not, by itself, tell you how many independent decisions are required.

Also distinguish resharing from changing the public-key algorithm. Redistributing shares of an elliptic-curve signing key does not make the resulting classical signature post-quantum. That would require a different supported signature design and compatible verification. The distinction between key lifecycle management and algorithm migration is central to NIST’s transition work. [7]

DN Wallet Authority and Migration Register

This register replaces the old vulnerability-score calculator. It produces a testable migration specification rather than a percentage. Complete one row for each independent authority path. Do not enter private keys, seed phrases, recovery codes or API secrets into a publishing workflow or public evidence record.

Illustrative register outcome: an operator replaces an agent’s session signer, but the old key is also the account owner. Session revocation alone does not retire its owner authority. The correct result is “migration incomplete: owner path remains,” not “security improved by 20 points.” This is an example of reasoning from authority relationships, not an observed incident or a penetration test.

For a multi-chain deployment, the record should not collapse different chains into one completion flag. A permission revoked on one chain may remain active elsewhere. The register therefore includes chain and account identifiers at each step. An operator can resolve the migration only when every in-scope path has a documented disposition.

Why post-quantum wallet upgrades are more than key rotation

There are at least three separate changes: producing new signing material, making the account accept its signatures, and removing the old vulnerable authorisation path. A smart account may make verification more flexible, but supported algorithms, contract costs, recovery and chain-specific rules remain implementation questions. The existence of an account-abstraction standard is not proof that any named wallet has deployed a post-quantum verifier.

EIP-7702 reinforces the importance of the delegation layer: changing delegation is security-critical, and the delegate implementation must be designed and reviewed for the account’s state and authority. Treat it as an explicit migration dependency. [8]

The DN post-quantum signature byte budget helps compare encoded sizes under explicit assumptions. It cannot establish production support or recovery safety. The Bitcoin quantum exposure ledger addresses output visibility and proposal maturity. Those are separate questions from how an agent’s operating key is isolated.

A practical review sequence

First inventory authority before changing it. Record the current configuration and identify who can approve a migration. Next rehearse the permitted and prohibited actions with representative assets and account state in a suitable test environment. Then define the required finality and monitoring evidence. Finally verify retirement, including permissions outside the replaced signer.

NIST SP 800-57 covers key inventory, lifecycle, compromise, backup and recovery. We use those categories as a review structure, not as a claim that a particular wallet is NIST-certified. [9] The most valuable deliverable is a record another engineer can reproduce without needing access to the secret itself.

Methodology and limits

This is a documentary architecture review and an original DN authority-register template. It contains no measured compromise probabilities or comparative product audit. A complete register demonstrates that questions have been answered with evidence; it does not prove the absence of every vulnerability. Unknown scope, untested recovery or unverified deployment state must remain explicit.

Frequently asked questions

Is a TEE better than MPC?

There is no defensible universal ranking from the architecture labels alone. Compare the threat being addressed, trust boundaries, implementation, administration and recovery. They can also be combined.

Does an ERC-4337 wallet automatically have session keys?

No. The account supplies validation logic. Session permissions depend on its implementation and installed modules. Inspect the actual policy and every path that can bypass or replace it.

Can a daily spending cap be treated as the maximum possible loss?

Only within a precisely established scope and threat model. Other assets, permissions, repeated periods, owner powers and external approvals can invalidate that inference. This page no longer calculates a universal maximum exposure from a storage label.

Does rotating an ECDSA key make a wallet quantum-resistant?

No. A fresh key under the same vulnerable algorithm does not provide a post-quantum signature scheme. Algorithm support and retirement of vulnerable paths need separate evidence.

Corrections and change log

12 November 2026: withdrew unsupported security scores and EAL generalisation; corrected smart-account key-storage and session-key claims; replaced the numerical audit with an authority/migration register; added key-rotation and algorithm-migration boundaries. Canonical URL and existing media are retained. Submit corrections with implementation version and evidence via the DN contact page.

Primary sources

1. ERC-4337 — Account validation and implementation-specific signature interpretation; not private-key custody or automatic session policy.
2. AWS Nitro Enclaves user guide — Isolation from parent instance and attestation support; no transaction-intent guarantee.
3. NIST IR 8214C — Threshold computation, secret-sharing and submission/evaluation requirements.
4. ERC-7579 — Draft modular account interfaces and validator/executor roles.
5. AWS attestation validation — Signed measurements and relying-party protocol/validation duties.
6. Common Criteria certified products — Product certificates/security targets do not certify a generic architecture category.
7. NIST IR 8547 final — Algorithm transition is distinct from replacing a key under the same algorithm.
8. EIP-7702 — Security-critical delegation changes and secure delegate implementation.
9. NIST SP 800-57 Part 1 Rev 5 — Key inventory/lifecycle, backup, recovery and compromise management.