链上自主 Agent 的密钥管理：威胁模型与防护策略

Every agent you deploy has a secret. The question isn't whether it will be attacked — it's what happens when it is.

当前 agent 部署中，每个 agent 都持有一个密钥。问题不在于它是否会被攻击——而在于被攻击后会发生什么。

The uncomfortable reality of the current agent stack: we build sophisticated decision loops, give them access to a wallet, and call it production. But a private key in an agent runtime is not the same as a private key in a cold wallet. It's a credential sitting inside a process that reads untrusted data, calls untrusted APIs, and makes autonomous decisions. That's a fundamentally different security posture, and most teams haven't redesigned for it.

当前 agent 技术栈一个令人不安的现实：我们构建了复杂的决策循环，赋予它们钱包访问权限，然后称之为生产环境。但 agent 运行时中的私钥与冷钱包中的私钥并不相同。它是一个凭证，位于一个读取不受信任数据、调用不受信任 API、做出自主决策的进程内部。这是一种根本不同的安全态势，而大多数团队还没有为此重新设计。

Here's how to think about key management when the entity holding the key is a machine that can be prompted, poisoned, and manipulated.

以下是如何在密钥持有者是一台可以被提示注入、被污染、被操控的机器的情况下思考密钥管理。

The Threat Model Is Different From Yours

威胁模型与你的不同

A human operator protects a key with discipline: never paste it, never screenshot it, verify the destination. An agent protects a key with... whatever its runtime does with it. The realistic threat model for an agent wallet includes:

人类操作员用纪律保护密钥：从不粘贴、从不做截图、验证目标地址。Agent 保护密钥靠的是……运行时对密钥的任何处理。Agent 钱包面临的现实威胁模型包括：

Prompt injection — the agent reads on-chain data, market news, or API responses that contain instructions it wasn't supposed to follow. A token name, a tweet, a governance proposal can become an attack payload.

提示注入——agent 读取链上数据、市场新闻或 API 响应，其中可能包含它不应遵循的指令。代币名称、推文、治理提案都可能成为攻击载荷。

Exfiltration — if the key material is readable by the agent process, anything that compromises that process (a plugin, a dependency, a malicious RPC response) can read it too.

泄露——如果密钥材料可以被 agent 进程读取，那么任何能攻破该进程的东西（插件、依赖项、恶意的 RPC 响应）同样可以读取它。

Drift — the agent isn't malicious, it's just wrong. A model hallucinates a destination address, a fee calculation overflows, a strategy misreads a pool. No attacker required; the key signs what the loop decides.

漂移——agent 不是恶意的，只是错了。模型可能会幻觉出一个目标地址、费用计算溢出、策略错误解读了池子。不需要攻击者；密钥签下了循环决定的内容。

Amplification — a single key that controls a large balance turns one mistake into a catastrophic one. The blast radius scales with key scope, not with the size of the error.

放大——控制大额余额的单一密钥把一个错误变成灾难。爆炸半径随密钥权限范围而非错误大小而扩大。

The insight: the key is not the security boundary anymore. The policy is. What the key is allowed to sign, when, and for how much — that's the real attack surface.

核心洞察：密钥不再是安全边界。策略才是。密钥被允许签什么、在什么时间签、签多少——这才是真正的攻击面。

Pattern 1: Separate the Key From the Intent

模式一：密钥与意图分离

The first rule is architectural: the model should never touch key material. The decision loop produces an intent — a structured, typed description of what it wants to do ("transfer 0.5 ETH to 0xabc...", "approve 100 USDC to Uniswap Router"). A separate signing service receives the intent, validates it against policy, and produces the signed transaction.

第一条规则是架构层面的：模型永远不应接触密钥材料。决策循环产生一个意图——即对它想做什么的结构化、类型化描述（"转账 0.5 ETH 到 0xabc..."、"批准 100 USDC 给 Uniswap Router"）。一个独立的签名服务接收意图、根据策略验证意图，然后生成已签名的交易。

This split means the LLM can be fully compromised without the attacker gaining signing power. The most an injected prompt can do is produce an intent — which still has to pass policy. That one separation eliminates the highest-probability attack path in the entire stack.

这种分离意味着 LLM 可以被完全攻破而攻击者无法获得签名权。注入的提示最多只能产生一个意图——而这个意图仍需通过策略审查。这一个分离操作消除了整个技术栈中概率最高的攻击路径。

Pattern 2: Policy-Based Signing

模式二：基于策略的签名

Once intents are structured, you can enforce rules that would be impossible to encode in a prompt. A signing policy is a set of constraints evaluated before every signature:

一旦意图被结构化，你就可以执行那些不可能编码到提示中的规则。签名策略是一组在每次签名前评估的约束：

Allowlists — only sign transfers to addresses the operator has approved. Everything else gets rejected, no exceptions.

白名单——只签署向操作员已批准地址的转账。其他一切都会被拒绝，无例外。

Amount caps — per-transaction limits, per-hour budgets, daily ceilings. An agent can't move more than its strategy is authorized to move.

金额上限——单笔交易限额、每小时预算、每日上限。Agent 不能移动超过其策略授权移动的金额。

Contract allowlists — only call specific contracts (the DEX the strategy was designed for, the staking contract, the bridge). Arbitrary contract calls are the classic injection escape hatch; closing them closes most of the game.

合约白名单——只调用特定合约（策略所设计的 DEX、质押合约、桥接合约）。任意合约调用是经典的注入逃逸出口；封堵它们就封堵了大部分攻击途径。

Rate limits — max transactions per block, max gas price, max priority fee. This contains fee-spike accidents and griefing vectors.

速率限制——每区块最大交易数、最大 gas 价格、最大优先费。这能抑制费用飙升事故和恶意干扰向量。

Time locks — high-value operations require a delay, giving humans a window to cancel.

时间锁——高价值操作需要延迟，给人类一个取消的窗口。

Policies aren't a replacement for good agent design. They're the backstop that makes good design survivable. Think of them as the firewall rules for a process that is, by definition, going to be tricked sometimes.

策略不是良好 agent 设计的替代品。它们是使良好设计能够存活的后盾。把它们想象成那些本质上会被欺骗的进程的防火墙规则。

Pattern 3: Session Keys and Scoped Authority

模式三：会话密钥与受限授权

Giving the agent the master key is like giving an intern the CEO's credit card. The better pattern is delegation: the agent gets a session key with a narrow scope and a short lifetime, derived from — but not equal to — the main identity.

把主密钥交给 agent 就像把 CEO 的信用卡交给实习生。更好的模式是委托：agent 获得一个会话密钥，具有狭窄的范围和短暂的寿命，派生自——但不等于——主身份。

On EVM chains, smart accounts (ERC-4337 style) enable exactly this: the owner delegates signing authority to a session key with explicit restrictions, and revokes it at will. On Solana, program-derived addresses and delegated authority on token accounts give you the same primitive: the agent signs with a key that can only touch specific accounts, and the main key stays cold.

在 EVM 链上，智能账户（ERC-4337 风格）正好实现了这一点：所有者将签名权委托给一个具有明确限制的会话密钥，并可随时撤销。在 Solana 上，程序派生地址和代币账户上的委托授权提供相同的原语：agent 用一个只能操作特定账户的密钥签名，而主密钥保持冷存储。

The practical rule: an agent's key should expire on the same timescale as its mission. A rebalancing agent that runs for a week gets a week-long session key. When the mission ends, the key dies without anyone having to remember to rotate it.

实践规则：agent 的密钥应在与其任务相同的时间尺度上过期。运行一周的再平衡 agent 获得一周有效的会话密钥。当任务结束时，密钥消亡，无需任何人记得轮换它。

Pattern 4: Human-in-the-Loop Tiers

模式四：人类介入层级

Not every signature should be autonomous. The mistake is treating autonomy as binary. A healthy agent system has tiers:

并非每个签名都应该是自主的。把自主性当作二元的是个错误。健康的 agent 系统有层级：

Fully autonomous — small, reversible, high-confidence operations (claiming rewards, dust conversions, fee payments).

完全自主——小型、可逆、高置信度的操作（领取奖励、dust 转换、费用支付）。

Approval-gated — large transfers, first-time counterparties, anything that changes strategy parameters.

审批门控——大额转账、首次交易对手、任何改变策略参数的操作。

Multi-sig — anything that touches the treasury, changes withdrawal addresses, or upgrades the agent itself.

多签——任何涉及金库、改变提现地址或升级 agent 本身的操作。

The pattern to avoid is the "emergency pause" that only exists in theory. If the kill switch requires a ceremony, it won't be used. Design the pause to be as boring as possible: a single operator key, a dashboard button, a CLI command. Speed of revocation matters more than elegance.

要避免的模式是只在理论上存在的"紧急暂停"。如果终止开关需要一个仪式，它就不会被使用。把暂停设计得越无聊越好：单个操作员密钥、一个仪表盘按钮、一个 CLI 命令。撤销的速度比优雅更重要。

Pattern 5: One Wallet Per Mission

模式五：一个任务一个钱包

Blast radius containment is the cheapest security you'll ever buy. Instead of one hot wallet doing everything, provision a fresh wallet per strategy, per chain, per campaign:

爆炸半径控制是你能买到的最便宜的安全措施。不要用一个热钱包做所有事，而是为每个策略、每条链、每个活动配置一个新鲜的钱包：

A wallet that only holds the USDC a strategy is allowed to spend.

一个只持有策略允许消费的 USDC 的钱包。

A wallet that only has approval to the one DEX the strategy uses.

一个只批准了策略所使用的那个 DEX 的钱包。

A wallet that gets topped up to its budget and never above.

一个被充值到预算金额但从不超出预算的钱包。

If a wallet is compromised, you lose that mission's budget — not the whole operation. This also makes accounting trivial: each wallet's P&L is its own ledger. For multi-chain deployments, per-chain wallets with per-chain budgets turn "one hack across 14 chains" into "one hack, one chain, one bounded amount."

如果一个钱包被攻破，你损失的只是该任务的预算——不是整个操作。这也使会计变得简单：每个钱包的 P&L 就是自己的账本。对于多链部署，每链钱包配合每链预算，把"14 条链上的单次黑客攻击"变成"一次攻击、一条链、一个有限金额"。

Pattern 6: Simulate Before Signing

模式六：签名前模拟

The final check happens milliseconds before the signature: a local simulation of the exact transaction against current chain state. If the simulated outcome doesn't match the intent (wrong recipient, unexpected slippage, a token transfer you didn't ask for), the signature is rejected.

最后的检查发生在签名前的毫秒级：对当前链状态运行精确交易的本地模拟。如果模拟结果与意图不符（错误的接收方、意外的滑点、一个你没有要求的代币转账），签名就会被拒绝。

Simulation catches the failures that policies can't: not "is this address allowed" but "will this transaction do what we think it does." It's the last line of defense between a poisoned decision and a signed transaction — and it costs nothing to run at decision time.

模拟捕获了策略无法捕获的失败：不是"这个地址是否被允许"而是"这笔交易会做我们认为它会做的事"。这是在被污染的决策和已签名交易之间的最后一道防线——而且在决策时运行它几乎不花任何成本。

What This Looks Like in Practice

实践中看起来是这样的

A production-grade agent key system, in rough order of importance:

一个生产级 agent 密钥系统，按重要性大致排序：

Structured intents — the model never emits raw transactions.

结构化意图——模型从不发出原始交易。

A policy engine — allowlists, caps, budgets, rate limits, enforced per signature.

策略引擎——白名单、上限、预算、速率限制，每次签名时强制执行。

Session keys with expiry — scoped, short-lived, revocable delegation.

带有效期的会话密钥——受限的、短暂的、可撤销的委托。

Tiered approval — autonomous for small ops, human for big ones, multi-sig for critical ones.

分层审批——小操作自主、大操作人工、关键操作多签。

Per-mission wallets — bounded budgets, isolated blast radius.

每个任务一个钱包——有限的预算、隔离的爆炸半径。

Simulation-before-signing — the last gate before anything hits the mempool.

签名前模拟——任何东西进入内存池前的最后一道关卡。

Log everything — every intent, every policy decision, every rejection, queryable. You will need it when something goes wrong.

记录一切——每个意图、每个策略决策、每个拒绝，都是可查询的。当出问题时你会需要它。

The shift is subtle but important: stop treating the private key as the asset to protect and start treating the signing policy as the asset to engineer. The key becomes just a piece of plumbing — powerful, but inert without policy. The agent gets to be autonomous, and you get to sleep at night.

转变是微妙的但重要的：不要再把私钥当作要保护的资产，开始把签名策略当作要设计的资产。密钥变成只是一段管道——强大，但没有策略就是惰性的。Agent 得以自主运行，而你可以高枕无忧。

This is the direction the serious agent platforms are already moving. BBIO, for example, runs autonomous agents across 14 chains from a single platform — and its managed wallet and signing layer is built exactly around these patterns: scoped session authority, per-chain wallets, policy-enforced intents, and simulation before broadcast. If you're building agents that touch real capital, study how their runtime handles keys before you write your own loop. It'll save you the most expensive lesson in crypto: the one you learn after the signature.

这正是那些认真的 agent 平台已经在前进的方向。例如，BBIO 从单一平台跨 14 条链运行自主 agent——其托管钱包和签名层正是围绕这些模式构建的：受限的会话授权、每链钱包、策略强制的意图、以及广播前的模拟。如果你在构建涉及真实资本的 agent，在写自己的循环之前先研究他们的运行时如何处理密钥。这会节省你 crypto 中最昂贵的一课：那个你在签名之后才学到的教训。