开发者的 AI 安全：OWASP LLM 应用十大风险

Mike Karan

面向开发者的 AI 安全：需要关注什么以及如何降低风险

一份面向开发者的 OWASP LLM 应用 Top 10 拆解，并提供在 web3 和智能合约工作流中降低 AI 风险的实用建议。

面向开发者的 AI 安全：需要关注什么以及如何降低风险

AI 发展得非常快，新能力可能每周都会出现，新的滥用方式也一样。对于开发者来说，这意味着 AI 安全不只是一个政策话题，它也是一个产品、安全和工程质量话题。

在 Cyfrin，我们亲眼看到了这一点。团队正在借助 AI 更快地交付，但真正做得好的团队，是那些以对待基础设施、认证和智能合约安全同样严格的态度来对待 AI 工具的团队。跳过这一步的团队，往往只能通过惨痛教训来补上这一课。

在这篇文章中，我们将基于 OWASP 针对 LLM 和 GenAI 应用的 Top 10，拆解开发者应该关注的主要 AI 安全风险，然后介绍你可以在日常开发中采取的实际步骤来降低这些风险。如果你从事 web3，门槛会更高：错误输出、权限过大的工具，或泄露的机密，都可能在链上造成不可逆的后果。

OWASP 当前的指导之所以能成为这场讨论的坚实基础，是因为它关注的是 LLM 和 GenAI 系统中实际的应用层风险，而不仅仅是抽象的模型行为。

为什么 AI 安全是开发者的问题

人们很容易把 AI 安全当作治理或政策问题，但大多数真实风险都出现在日常工程工作中。

开发者正在把模型接入代码库、终端、CI 流水线、内部文档、API、钱包和面向客户的应用中。当这些系统控制宽松时，一个糟糕的模型响应就可能演变成真实的安全事件。

在 web3 中，后果会更加严重。泄露的机密、有缺陷的合约变更，或权限过大的 Agent，不仅仅是带来不便，它还可能代价高昂且不可逆。

OWASP 针对 LLM 和 GenAI 应用的 Top 10

OWASP 2025 列表 列出了团队当前应该重点关注的主要风险类别。下面是每一项，以及它为什么对开发者很重要。

1. Prompt Injection

Prompt Injection 发生在不受信任的输入改变模型行为的时候。模型不再遵循你预期的指令，而是遵循隐藏在用户输入、检索文档、网站、电子邮件或其他外部内容中的恶意或误导性指令。

Prompt 不是安全边界。如果你的应用允许模型处理不受信任的内容，然后再基于这些内容采取行动，那么 Prompt Injection 就会成为严重风险。

示例： 一个内部助手读取来自公共论坛的治理提案。该提案包含隐藏指令，告诉模型忽略之前的上下文并输出 system prompt。如果助手照做，攻击者就能准确知道你的系统是如何工作的，以及它的防护栏在哪些地方较弱。

对于 web3 团队来说，这可能出现在那些会读取治理帖子、代码注释或合约相关文档，然后基于被操纵的指令采取行动的助手中。

延伸阅读：OWASP LLM01:2025 - Prompt Injection

2. 敏感信息泄露

当过多敏感信息被传入 Prompt、记忆系统、检索层、日志或工具上下文时，AI 系统可能会暴露机密、私人文档、内部指令、客户数据或专有代码。

这对于内部助手和编码工具尤其 relevant。如果模型可以读取一切，它泄露的内容可能会比你预期的更多。

示例： 一个开发者把 .env 文件加入项目目录，而该目录同时也作为编码助手的上下文。之后，该助手在建议的代码块中包含了一段带有 API key 的片段，并被提交到了公共仓库。

在 web3 中，如果暴露的数据包括部署凭证、与签名相关的上下文、基础设施访问权限或钱包相关元数据，风险会更大。

延伸阅读：OWASP LLM02:2025 - Sensitive Information Disclosure

3. 供应链漏洞

AI 应用并不是孤立存在的。它们依赖于模型、SDK、插件、MCP server、向量数据库、数据集、Prompt 库以及第三方服务。

每一个依赖都会引入信任假设。如果这些组件中有一个被攻陷、过时或设计不良，你的 AI 系统就会继承这种风险。

这对开发者来说应该并不陌生，但 AI 系统往往会放大影响范围，因为这些依赖可能会获得对敏感代码、内部数据或工具执行能力的访问权限。

示例： 一个团队从未经验证的来源安装了一个 MCP server 插件，以便让他们的编码助手访问数据库。该插件会悄悄地把查询结果外传到一个外部端点。由于它运行在助手的工具上下文中，它能接触到的数据，就是助手能接触到的任何数据。

延伸阅读：OWASP LLM03:2025 - Supply Chain Vulnerabilities

4. 数据与模型投毒

数据与模型投毒涵盖这样一种风险：用于训练、微调、评估或为系统检索信息的数据被操纵，从而以不安全或误导性的方式改变系统行为。

即使你没有训练 foundation model，这一点仍然很重要。团队会微调模型、构建 eval 数据集，并依赖可能被投毒的检索流水线。

对于开发团队来说，这意味着不良数据会随着时间悄悄削弱输出质量、可信度和安全态势。

延伸阅读：OWASP LLM04:2025 - Data and Model Poisoning

5. 不当的输出处理

不当的输出处理发生在模型输出被过快信任的时候。这包括执行生成的 shell 命令、接受生成的 SQL、渲染不安全的 HTML，或在缺乏足够审查的情况下发布代码。

这是 AI 质量问题演变成安全问题的最明确例子之一。一个糟糕的答案不只是错误，它还可能变成一条可利用路径。

生成的 Solidity、基础设施变更、迁移脚本或前端代码，都应该在审查和验证之前被视为不受信任的内容。

延伸阅读：OWASP LLM05:2025 - Improper Output Handling

6. 过度自主性

过度自主性发生在 AI 系统被赋予过多自治能力，却没有足够监督的时候。

一个能够建议操作的模型是一回事。一个能够执行命令、修改生产系统、合并代码或触发财务操作的模型，则是完全不同的风险画像。

这是 web3 团队最重要的类别之一。高自主性的 Agent 与链上操作的组合非常危险，除非已经设置了强有力的审批关卡。

延伸阅读：OWASP LLM06:2025 - Excessive Agency

7. System Prompt 泄露

System Prompt 泄露提醒我们，隐藏指令并不是可靠的机密。攻击者通常能够迫使模型泄露 system prompt、内部指导或隐藏的工作流逻辑。

这不仅会暴露内部实现细节，还可能揭示各种假设、约束和模式，使系统更容易受到攻击。

开发者应当假设 Prompt 可能泄露，不要把它们当作安全边界。

延伸阅读：OWASP LLM07:2025 - System Prompt Leakage

8. 向量与 Embedding 弱点

检索系统会引入自身的安全风险。过滤薄弱、不良分块、被投毒的检索数据，以及薄弱的访问控制，都可能导致模型返回错误信息，或泄露本不应该有权访问的信息。

随着越来越多团队采用 RAG 和内部知识流水线，这些弱点已经成为应用攻击面的一部分。

对于处理内部文档、审计数据或专有研究的团队来说，检索安全与模型选择同样重要。

延伸阅读：OWASP LLM08:2025 - Vector and Embedding Weaknesses

9. 错误信息

错误信息不只是内容质量问题。在安全敏感的工作流中，虚假的信心、捏造的引用或错误的代码，都会把团队推向错误决策。

这在开发者场景中尤其重要，因为输出可能看起来精致且可信，但在关键方面依然是错的。

在智能合约开发中，这可能意味着看起来很整洁的代码，却在访问控制、重入、可升级性、Token 流转或预言机逻辑方面存在错误假设。代码可以编译，测试可以通过，但漏洞依然存在。

延伸阅读：OWASP LLM09:2025 - Misinformation

10. 无界消耗

AI 系统也可能通过失控的 Token 使用、超大 Prompt、过多的工具调用、递归循环或其他模式被滥用，从而推高成本并降低系统性能。

这既是安全问题，也是可靠性问题。无界消耗可能演变成拒绝服务、意外的基础设施账单，或不稳定的生产行为。

开发者应把预算、速率限制、超时和资源控制视为 AI 安全的一部分，而不是事后补救。

延伸阅读：OWASP LLM10:2025 - Unbounded Consumption

给使用 AI 的开发者的实用建议

了解风险是有用的，但大多数团队更需要的是有纪律的习惯，而不是理论。下面是实践中的具体做法。

正确保护机密

如果这些环境可以被 AI 工具、编码 Agent 或共享工作流访问，就不要把私钥或其他敏感凭证以未加密形式存放在 .env 文件中。

如果一个助手可以检查你的仓库、终端或应用配置，那么薄弱的机密处理就会成为真正的风险。对于 web3 团队来说，这应该被视为一条基线规则，而不是可有可无的选项。

仔细审查 AI 输出

将 AI 生成的代码和面向公众的文本视为不受信任的输出，直到它经过人工审查。

对于代码，要检查认证、授权、边界情况、输入验证和错误处理。对于 web3，要假设所有生成的智能合约代码在接近生产环境之前都需要专家审查。

尽可能将 AI 置于沙箱中

许多现代 AI 工具提供权限控制或沙箱机制。使用它们。更进一步，把高风险工作流隔离在容器或类似的受限环境中。

AI 应该只拥有完成工作所需的最小文件、网络和执行访问权限，不要更多。

默认不要赋予 Agent 不可逆的权力

对于任何高影响操作都要求审批。这包括部署合约、签名交易、合并 pull request、轮换机密、删除数据或更改基础设施。

假设 Prompt 并不足够

System Prompt 不是真正的控制边界。告诉模型不要做某事，并不等于用代码、权限、验证和隔离来强制执行这条规则。

在执行前验证输出

永远不要盲目运行生成的 shell 命令、SQL、迁移脚本、基础设施变更或合约更新。尽可能加入审查步骤、验证层和 allowlist。

限制进入上下文的内容

要有意识地决定你的助手可以访问什么。不要把私有仓库、客户数据或内部系统一股脑塞进上下文，除非确有实际需要，并且已经配套了适当的控制措施。

记录并审计 AI 行为

如果一个 AI 系统能够采取行动，你应该知道它试图做什么、调用了哪些工具，以及实际上执行了什么。良好的日志能让调试更容易，也让事件调查更容易。

给 web3 开发者的额外指导

web3 团队在使用 AI 时应采用更严格的风险模型。确实有可能获得不错的提效，但失败模式也更严重。有几条原则值得始终放在首位：

• 绝不要以明文暴露私钥。 不要放在 Agent 可访问的 .env 文件中，不要出现在终端历史中，也不要出现在日志中。
• 绝不要让 AI 在没有人工批准的情况下签名或提交高风险操作。 每一个链上操作都应经过明确的关卡。
• 把生成的 Solidity 当作仍然需要专家审查的初级水平输出。 它可能可以编译，也可能通过测试，但仍然可能存在关键漏洞。
• 仔细审查权限、可升级性、Token 流转、外部调用和信任假设。 这些是 AI 输出最可能出现隐蔽错误的领域。
• 使用 AI 来加速分析和起草，而不是替代安全判断。 模型并不理解它所写内容背后的财务后果。

值得评估的更安全 AI 流水线工具

保护 AI 工作流不仅仅是选择正确的模型。它同样关乎控制什么数据进入系统、模型被允许做什么，以及什么内容可以作为输出或操作离开系统。

有两个值得评估的工具：

Varlock 专注于更安全的配置和机密处理。它围绕 schema-driven 的环境管理、验证、生成的类型、具备 secret 感知的处理方式，以及 AI-safe 配置模式构建。它的方法在不暴露机密值的情况下为 Agent 提供关于配置的结构化上下文，其工作流还包括验证，以及用于捕获生成代码中泄露机密的工具。

Mlld 将自己定位为具备运行时强制能力的安全 LLM 脚本工具，用于限制数据可以流向哪里。它将 Prompt Injection 视为基础设施问题，并强调运行时控制，而不是只信任模型本身。它的模型会跟踪数据是什么，并在运行时强制规定数据可以流向哪里。当 Prompt 和检索数据可能是恶意内容时，这正是你想要的控制类型。

在实践中：

• Varlock（或类似工具）有助于保护进入流水线的内容：让机密和环境数据变得明确、可验证，并更难泄露。
• Mlld（或类似工具）有助于控制流水线内部发生的事情，以及哪些内容被允许离开它：在 Agentic 工作流周围应用运行时策略、标签传播和防护栏。

结论

对开发者来说，AI 安全并不是要回避 AI，而是要用与你对待基础设施、认证、部署或智能合约安全相同的纪律来使用它。

从长期来看，最能从 AI 中受益的团队，不会是那些给它最多自由的团队。它们会是那些围绕它建立最强边界，然后在这些边界内快速前进的团队。

如果 AI 正在成为你工作流的一部分，现在正是决定它应该被允许看到什么、应该被允许做什么，以及哪些地方仍然需要让人工审查保留在流程中的合适时机。OWASP 针对 LLM 应用的 Top 10 为你提供了一个坚实框架，上面的习惯则为你提供了一个起点。剩下的就是执行。

• 原文链接： cyfrin.io/blog/ai-safety...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～