Humanity lost $32M to a stolen private key. The fix is not another multisig.

On June 9, Humanity Protocol's H token dropped more than 80% after attackers drained over $32 million from at least 17 wallets tied to the project. Founder Terence Kwok confirmed the breach: someone got the private keys of a Humanity Foundation member and started dumping stolen tokens for ether. The thief also minted another 100 million H on BNB Chain, adding more sell pressure on top of the wallets already being emptied.

This was not a smart contract exploit. There was no reentrancy bug, no oracle manipulation, no bridge logic flaw. It was a key theft. And 2026 keeps repeating the same story. Drift lost roughly $285 million in April when attackers seized an administrative key. Kelp DAO lost about $292 million the same month through a single-validator bridge. The pattern is obvious: the biggest losses are coming from compromised keys, not broken code.

Reports on the Humanity incident point to a compromised laptop hosting a multisig wallet. That detail matters. Multisig does not help if one signer's machine is fully owned. The attacker does not need to break the contract. They just need the secret material that lets a legitimate signer produce a valid signature. Once that key is out, rotation is damage control, not prevention.

What actually went wrong

Private keys are just numbers. Whoever holds the number can sign. There is no undo button on chain. Humanity urged users to avoid its bridge and liquidity pools while containment work continued. That is the right crisis response. It does not fix the underlying mistake: high-value signing material lived somewhere an attacker could reach.

For teams running treasuries, foundations, or agent wallets, the failure mode is almost always the same:

• Keys stored on a laptop, in a password manager export, or in a cloud sync folder
• One compromised device becomes a signing endpoint for everything that device can touch
• No per-action policy layer between "the model decided to send" and "the chain accepted it"
• No audit trail that tells you which credential signed what, and when, before the damage is done

If your security model is "keep the key on a machine we trust," you are one phishing email, one malicious npm package, or one unattended laptop away from a headline. That is not FUD. It is what CoinDesk and every on-chain analyst watching this drain are documenting in real time.

A different model: keys that never leave the HSM

1Claw was built around a simple rule: the thing that signs should not be the thing that thinks. Agents and humans submit intents. Vault validates policy. The signing key stays inside hardware-backed encryption the whole time.

Vault is the secret store. Every secret gets its own data encryption key. That DEK is wrapped by a key encryption key in Google Cloud KMS (HSM on paid tiers). The KEK never leaves the HSM. When an agent needs to sign, Vault unwraps the DEK inside the service boundary, uses it, and zeroes the material. Business and Enterprise customers can split DEKs across multiple HSM providers with Shamir 2-of-3 so a single cloud compromise does not surface a usable key.

Access is not "here is the private key, good luck." You register an agent, attach a policy that says exactly which secret paths it can touch, set an expiry, and issue a short-lived JWT. The agent can call the API or MCP server to use secrets at runtime. It does not get a copy to stash in context, logs, or a laptop filesystem.

Getting started with Vault (about five minutes)

You do not need to redesign your whole stack on day one. The basic flow is: create a vault, store secrets at paths, register an agent, grant a policy, let the agent fetch at runtime.

# Store a partner API key (human token)
curl -X PUT https://api.1claw.xyz/v1/vaults/$VAULT_ID/secrets/api-keys/partner \
  -H "Authorization: Bearer $USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"value": "sk_live_...", "type": "api_key"}'

# Grant one agent read access to that path only
curl -X POST https://api.1claw.xyz/v1/vaults/$VAULT_ID/policies \
  -H "Authorization: Bearer $USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "principal_type": "agent",
    "principal_id": "'"$AGENT_ID"'",
    "secret_path_pattern": "api-keys/partner",
    "permissions": ["read"]
  }'

# Agent exchanges its API key for a scoped JWT, then reads at runtime
curl https://api.1claw.xyz/v1/vaults/$VAULT_ID/secrets/api-keys/partner \
  -H "Authorization: Bearer $AGENT_JWT"

With the TypeScript SDK it is shorter:

import { OneclawClient } from "@1claw/sdk";

const client = new OneclawClient({ apiKey: process.env.ONECLAW_AGENT_API_KEY });

await client.secrets.put(vaultId, "api-keys/partner", {
  value: partnerKey,
  type: "api_key",
});

const secret = await client.secrets.get(vaultId, "api-keys/partner");

The agent never sees your human API key. It sees only what your policy allows, for as long as the JWT is valid. Revoke the policy or rotate the secret and access stops immediately.

On-chain signing without handing agents a key

For treasury and trading workflows, the important shift is the same: the agent submits what it wants to do. Vault (or Shroud's TEE signer) decides whether that action is allowed, then signs on the agent's behalf. The private key never enters the agent process.

Turn on the Intents API for the agent, set guardrails once, and enforce them server-side before any signature is produced:

await client.agents.update(agentId, {
  intents_api_enabled: true,
  tx_to_allowlist: ["0xYourTreasury", "0xKnownRouter"],
  tx_max_value_eth: "0.5",
  tx_daily_limit_eth: "2.0",
  tx_allowed_chains: ["base", "ethereum"],
});

const tx = await client.agents.submitTransaction(agentId, {
  chain: "base",
  to: "0xYourTreasury",
  value: "0.1",
  simulate_first: true,
});

// Agent gets tx_hash. It never receives the private key.

If an attacker compromises the agent itself, they still cannot drain the wallet freely. They are bounded by your allowlist, per-transaction cap, daily spend limit, and chain restrictions. Those checks run in Vault before the HSM unwraps the signing key. The agent has no bypass.

For autonomous agents, we also recommend enabling intents_api_enabled with private key read blocking: when Intents is on, direct reads of private_key and ssh_key secrets return 403. The agent must use the signing proxy. That closes the obvious exfil path.

Where Shroud fits for AI agents

Vault solves custody. Shroud solves what happens when an agent talks to a frontier model.

Shroud is a TEE-backed LLM proxy. Your agent sends requests to shroud.1claw.xyz instead of OpenAI or Anthropic directly. Inside the enclave, Shroud inspects traffic in both directions before anything crosses the network boundary to a model provider.

• Secret redaction: vault-aware matching catches API keys and connection strings if an agent tries to paste them into a prompt
• Injection detection: prompt injection, encoded payloads, and social engineering patterns are scored and blocked per your policy
• Tool call inspection: arguments to function calls are scanned before the model can trigger a dangerous action
• TEE transaction signing: submit Intents API transactions through Shroud and the key stays inside the same enclave boundary

Enable Shroud on the agent in the dashboard or via API, point your LLM client at Shroud, and re-exchange the agent token so the JWT carries your shroud_config. From there, every model call runs through inspection policy you control: allowed providers, rate limits, daily budget caps, block vs redact vs warn on threats.

The Humanity hack was a signing key problem. But teams building AI agents face both risks at once: keys that should never leave an HSM, and model traffic that can leak whatever the agent has seen. Vault and Shroud are designed as one stack for that reality. Custody on one side, inspection on the other.

What to do Monday morning

You do not need a full migration to improve your posture this week.

1. Inventory where signing keys and partner API keys actually live. Laptops, .env files, shared drives, and chat logs count.
2. Move high-value secrets into Vault with per-agent policies. Start with one agent and one path.
3. For any autonomous on-chain agent, enable Intents API with an address allowlist and a daily cap before you give it real funds.
4. Route LLM traffic through Shroud if the agent can read external data (APIs, social feeds, contract metadata). That is where indirect injection lives.

Humanity Protocol is a decentralized identity project using palm-scan biometrics. The technology story is interesting. The security lesson is blunt: if the keys that control your treasury sit on a device someone can compromise, the chain will not save you. HSM-backed custody, intent-based signing, and TEE inspection are not luxury features anymore. They are the baseline for teams that cannot afford an 80% drawdown because one laptop got owned.

Get started for free · Intents API guide · CoinDesk coverage