AI Blockchain Key Manager
Autonomous key lifecycle management for wallets, smart contracts, and validators. Generate, rotate, retire, without losing access to chain state.
AKRUM’s AI Blockchain Key Manager is one of five prebuilt guardrails. Turn it on to enforce key lifecycle and rotation checks for wallets, validators, and contracts on every agent action, with no rules to write. AI may assist with interpretation and orchestration, but the deterministic policy engine owns every ALLOW, DENY, or CHALLENGE decision.
Overview
What this AI Agent does
Evaluates every signing key, hot wallets, cold wallets, multisig signers, and validators, against rotation-policy thresholds for age and signing volume, and returns an ALLOW, DENY, or CHALLENGE decision on its continued use. The deterministic engine owns the verdict, not an AI model.
Allow when a key is within policy; challenge when rotation is due (an age or signing-volume threshold is breached), with a proposed rotation plan; deny a key that’s been retired or has blown a hard limit, so it can’t keep signing. Every decision names the exact threshold that triggered it.
Enforced inline through the Guardrails SDK: allow proceeds, deny blocks the signing action, challenge surfaces the rotation plan, and every decision is signed with post-quantum ML-DSA and written to a tamper-evident log.
How it works
A four-step guardrail flow
Send the key event
Your agent or app sends the key's context (type, age, signing-op count, chain, action) to the guardrail.
Evaluate against policy
The deterministic engine checks age and signing volume against the rotation thresholds for that key type. The AI never makes the decision.
Return a decision
ALLOW (within policy), CHALLENGE (rotation due, with a proposed plan), or DENY (retired or hard-limit breach), with the exact threshold that triggered.
Enforce inline
Allow proceeds, deny blocks the signing action, challenge surfaces the rotation plan, and the signed decision is logged, tamper-evident.
Sandbox
Try it live
Simulate key evaluation, rotation planning, and retirement across chains.
{ "key_id": "akrum_key_bf816d39", "chain": "ethereum", "key_type": "hot_wallet", "rotation_recommended": true, "reason": "Rotation due: key age 180d exceeds the 90-day hot_wallet rotation threshold.", "proposed_plan": { "new_public_key": "0xf6b05593f5b05400f8b058b9f7b05726fab05bdff9b05a4cfcb05f05fbb05d72", "new_key_algorithm": "ECDSA-secp256k1", "hsm_backed": true, "transition_window_hours": 24, "policy_thresholds": { "max_age_days": 90, "max_signing_ops": 10000 }, "on_chain_steps": [ "Register the successor signer in the ethereum wallet registry", "Hold a 24h transition window with both keys valid", "Re-point signing traffic to the successor key and verify one signature end-to-end", "Revoke the predecessor key at the HSM and record the retirement in the audit trail" ], "urgency": "medium" }, "evaluated_at": "2026-01-15T10:00:00.000Z" }
Simulated response: no real inference is performed.
Data sources
Built on open chain specifications
- Ethereum Yellow Paper and EIP standards (EIP-712 typed data, EIP-1271 contract signatures, etc.)
- Bitcoin BIP specifications (BIP-32 HD wallets, BIP-39 mnemonics, BIP-340 Schnorr)
- Solana account model and Ed25519 specification
- Cosmos SDK key management documentation
- Polkadot SS58 address format spec
- NIST FIPS 140-3 (HSM standards, publicly published)
- CryptoCurrency Security Standard (CCSS), open standard
- Planned, not yet connected: live chain analytics for signing-volume baselines and automated on-chain execution of rotation plans
All chain specs are open standards and tracked as new EIP/BIP/SLIPs ship.
Supported chains
Chain coverage
Ethereum
Bitcoin
Solana
Polygon
Cosmos
Polkadot
Built for crypto & blockchain
Automated key lifecycle for wallets, contracts, and validators.
A key is only as strong as the entropy behind it, and unmanaged keys are how assets get lost. The Blockchain Key Manager evaluates signing keys against rotation-policy thresholds and proposes generation, rotation, and retirement, so nothing is left exposed or manually managed.
Data it protects
- Wallet backups
- Custody records
- Validator keys
- Seed-phrase archives
For sanctions and transaction screening, see the Crypto Compliance agent.
What parts of the key lifecycle does this agent automate?
+
Generation, rotation, custody, and recovery for on-chain keys. The agent issues fresh keys derived from AKRUM's Cellular Automata entropy engine (mixed with the OS CSPRNG through HKDF-SHA-256), schedules rotations, manages backup shards, and orchestrates recovery flows so operators do not have to script each step by hand.
Does it support wallets, smart contracts, and validators?
+
Yes. The agent covers hot and cold wallet keys, smart contract deployer and admin keys, and validator and signing keys for proof-of-stake networks. Each class gets policies appropriate to its blast radius and operational cadence.
How are keys generated and is the randomness verifiable?
+
Keys are generated from AKRUM's Cellular Automata entropy engine, the same source validated against NIST STS and Diehard. Every generation event is logged with a cryptographic receipt you can verify in audit, independent of AKRUM.
Where are keys stored and who can access them?
+
Keys are stored encrypted with custody policies you define: single operator, multi-party, or hardware-backed. Access is gated by role, and every read or sign operation is logged. AKRUM holds no usable copy outside the custody envelope you configure.
Is there a free sandbox to try it?
+
Yes. The sandbox lets you simulate generation, rotation, and recovery flows for wallet, contract, and validator keys and inspect the resulting JSON. You can validate the agent against your runbook before requesting a production API key.
Ready to integrate?
Get an API key and start calling AI Blockchain Key Manager in minutes.