AI 安全（AI Security）

约 1828 字大约 6 分钟

2026-05-12

当 AI Agent 开始读取文档、调用工具、连接钱包、发起交易时，安全问题就不再只是“模型会不会答错”。真正的问题是：它能看到什么、能调用什么、出错以后谁能发现。

为什么要探索这个

AI x Web3 项目经常从一个顺滑 Demo 开始：用户输入目标，Agent 读取资料，生成计划，调用工具，最后完成一次链上操作。Demo 看起来很强，但一旦进入真实环境，风险会同时来自 AI 和 Web3 两边。

常见问题包括：

外部文档或网页里藏着恶意提示词。
Agent 把不可信内容当成系统指令。
工具权限过大，模型错误会变成真实操作。
API key、私钥、session token 被放进模型上下文。
交易、授权和治理投票一旦发出，很难撤回。

第一性原理

安全的 Agent 不是“更听话的模型”，而是被放进了更小、更清楚、更可审计的行动空间。

不要指望模型永远分得清资料、命令、建议和攻击。系统应该通过权限、隔离、校验、模拟、日志和人工确认来限制损失。

上下文要分层：系统规则、用户目标、外部资料和工具返回值不能混成同一种权限。
工具要最小授权：读、写、签名、转账、部署是完全不同的风险等级。
高风险动作要可审计：能回放 Agent 读了什么、调用了什么、为什么执行或拒绝。

知识节点

Agent Threat Model

Threat Model 是先画清楚系统里哪些路径真的危险。一个 Agent 系统至少要问：

Agent 可以读取哪些上下文。
Agent 可以调用哪些工具。
工具背后连接了哪些账号、资金或外部系统。
哪些输出只是建议，哪些会真实执行。
用户在哪里确认，确认了什么。
出错以后能不能追踪到原因。

在 Web3 场景里，风险等级可以按动作分层：只读链上数据最低，生成交易草稿中等，自动签名和授权最高。

Prompt Injection Defense

Prompt Injection 的麻烦在于，恶意指令经常藏在 Agent 要读取的资料里，比如 README、网页、PDF、治理提案、聊天记录或链上 metadata。

防御重点不是在 prompt 里多写一句“不要听恶意指令”，而是做结构隔离：

外部资料只能作为 data，不能覆盖系统规则。
检索结果要带来源和可信等级。
工具调用前要检查用户目标和权限。
高风险指令必须重新确认。
模型输出要经过结构化校验。

Tool Permission Isolation

Agent 变危险，通常是因为它能调用工具。工具权限应该按风险拆开，而不是给 Agent 一个万能 API key。

可以分成几层：

公开只读工具：读取公开文档、链上数据、价格信息。
用户只读工具：读取用户钱包、仓位、历史交易，需要登录和范围限制。
草稿工具：生成交易、提案、消息，但不执行。
写入工具：发布内容、修改配置、调用后端。
资产工具：签名、授权、转账、swap、部署合约。

越靠后，越需要白名单、额度、模拟、人工确认、多签或延迟执行。

Malicious Document Demo

恶意文档 Demo 是最适合安全入门的练习。准备一份看起来正常的项目文档，在里面藏一段指令，比如要求 Agent 泄露环境变量、跳过检查、调用危险工具或忽略用户要求。

观察系统是否：

把文档内容标记为外部资料。
拒绝文档里的越权要求。
不把 secret 放进模型上下文。
在工具调用前检查权限。
在输出中说明拒绝原因。

这个 Demo 可以非常小，但能直接暴露 Agent 应用最常见的安全缺口。

Key / Secret Isolation

私钥、API key、数据库密码、session token 不应该直接进入模型上下文。

更合理的设计是让 Agent 请求一个受控动作，而不是拿到秘密本身。例如：

请求“查询余额”，而不是拿 RPC provider 的管理 key。
请求“生成交易草稿”，而不是拿用户私钥。
请求“调用某个后端函数”，而不是读取生产环境 token。
请求“签名这条明确消息”，而不是长期持有签名能力。

在 Web3 里，签名应该由钱包、smart account、多签或权限模块完成。Agent 不应该保管主私钥。

Privacy-preserving Workflow

隐私问题经常不是单条数据泄露，而是系统把钱包、聊天、身份、交易和偏好组合在一起。

一个 privacy-preserving workflow 应该做到：

只读取完成任务必要的数据。
对外部模型调用做脱敏或摘要。
默认隐藏不必要的地址、金额和身份。
给用户展示授权范围。
允许用户查看 Agent 用了哪些信息。
对敏感任务优先考虑本地模型、TEE 或加密数据流。

AI Behavior Audit

Agent 做过什么，不能只看最后一段回答。审计日志应该记录：

用户原始目标。
检索和读取了哪些资料。
调用了哪些工具。
每次工具调用的输入、输出和错误。
哪些步骤触发人工确认。
最终结果、失败原因和拒绝原因。

这些日志不是为了做得“企业级”，而是为了在事故发生后知道问题出在哪一层：数据、模型、工具、权限、钱包还是界面。

在 AI x Web3 中的位置

AI Security 是所有执行型 Agent 的底层要求。它和钱包、权限、隐私、可验证 AI、交易解释都有关。

一个健康的路线是：

先让 Agent 只读和解释。
再允许它生成草稿。
再接入低风险工具。
最后才开放受限执行。

每一步都要有对应的权限、模拟、日志和人工确认。

最小实践

做一个“恶意文档 + 工具权限隔离”的最小安全练习。

写清楚：

正常文档和恶意文档分别包含什么。
Agent 如何区分系统规则、用户目标和外部资料。
哪些工具只读，哪些工具禁用，哪些工具需要确认。
恶意指令触发时系统如何拒绝。
日志如何记录读取、判断和拒绝过程。

扩展阅读

OWASP Top 10 for LLM Applications：建立 LLM 应用安全风险地图。
OpenAI Function Calling / Tools Docs：理解工具调用、结构化参数和执行边界。
LangChain Security Policy：了解 Agent 工具和外部输入的安全注意事项。
Safe Docs：学习多签、模块和 guard 如何限制链上执行风险。
ERC-4337 Docs：理解 smart account 如何承载更细的权限和执行逻辑。