OWASP Agent 安全框架：从 LLM 风险到自主 AI 系统

OWASP LLM 应用 Top 10 是为这样一个世界编写的：用户发送 prompt，然后阅读响应。当模型开始采取行动——读取文件系统、编写 Python、在没有人工介入的情况下调用外部 API——这些风险并不会消失，反而会叠加。每一次自主行动都会带来新的攻击面，而 Agent 生成的代码则是持久存在的产物，其生命周期远超单次会话。

目前，OWASP 尚未发布独立的“Agentic AI Top 10”。现有的做法，是将标准的 LLM Top 10 严格应用于 Agentic 系统。对于使用 Claude Code、Cursor 或自主编码流水线进行开发的 Python 开发者来说，他们需要知道：当 AI 不只是回答问题，而是直接编写代码时，这十大风险中的哪些会造成最严重的影响。

Agentic 风险为标准 LLM Top 10 带来了什么

OWASP LLM Top 10 涵盖了调用 AI 模型的应用所面临的风险。但在 Agentic 系统中，AI 会自主采取行动，例如运行代码、调用工具和修改文件，因此还会引入第二类风险：Agent 本身可能被武器化，或者超出预期的权限范围。BrassCoders 关注这些风险在代码层面的具体表现，包括不安全的 subprocess 调用、SQL 注入，以及 Agent 生成的 Python 文件中的凭据泄露。

OWASP LLM 应用 Top 10 将“Excessive Agency（过度代理权限）”列为 LLM08——其风险在于，AI 模型拥有超出任务所需的权限，并采取了操作者未曾预料的行动。在 Agentic 编码场景中，它通常表现为：生成的代码默认拥有高级权限、向系统目录写入文件，或使用 shell=True 创建子进程。Bandit 会将这些 subprocess 模式标记为 B602 和 B603。这种风险并不罕见，而是任务定义不明确时，Agent 倾向于选择权限最宽松工具的直接后果。

第二个被放大的因素是影响范围。聊天机器人的失败模式是给出错误答案；自主 Agent 的失败模式，则可能是提交一个包含后门的 diff、让硬编码 API key 通过 CI，或引入一个在任何真实 package 中都不存在的虚假 import。这些失败会持久保存在版本控制系统中。

与 Python 开发者最相关的五类 Agentic 风险

BrassCoders 处理 Agentic 风险在代码层面的具体表现：不安全的工具调用，例如 Agent 触发的 shell=True subprocess 调用；Agent 生成代码中的凭据暴露；以及自主 Agent 生成的 Python 文件中残留的 prompt injection 产物。

第一类是源代码中的 prompt injection。Agent 读取到某条 comment、docstring 或用户提供的字符串，而其中的内容会改变 Agent 的下一步行动。构建流水线或聊天机器人的 Python 开发者尤其容易受到影响，因为用户文本会直接流入函数调用，而 Agent 随后会执行相应结果。

第二类出现在生成的 subprocess 调用中。Claude Code 和 Cursor 都会编写 subprocess.run()。当任务描述含糊不清时，Agent 往往会使用 shell=True。Bandit 会将其标记为 B602 和 B603；BrassCoders 则会把这两类问题都呈现在 YAML 输出中，供你的 AI assistant 在下一轮代码审查时读取。

第三类是凭据暴露。Agent 会生成配置文件和初始化代码。它们可能会幻觉出并不存在的环境变量名，然后使用字符串字面量作为 fallback。最终结果就是：一个真实有效的 secret 以默认值的形式被提交到代码库。BrassCoders 使用 Yelp 的 detect-secrets 作为上游库，并在 scanner 层加入自定义规则，可扫描 20 多种 secret 格式，包括 AWS access key、GitHub PAT、OpenAI key 和 Stripe live key。

第四类是虚假 import 与供应链风险。AI 模型会非常自信地 import 并不存在的 library，或者 import 与已知 package 同名、但 namespace 不同的 library。虚假 import 可能成为 dependency confusion 攻击的入口。BrassCoders 的 AI-pattern scanner 专门检测生成式 Python 代码中的虚假 API 使用。

第五类是生成式 query 中的 SQL 注入。Agent 会根据上下文进行模式匹配，编写数据库交互代码，并直接在 query 位置使用 f-string。BrassCoders 运行的 Pysa——由 Meta 构建的 taint analysis engine——会追踪数据从用户输入流向 query 调用的过程。

构建一份 Python 团队真正能执行的检查清单

一份适合 Python 团队实际执行的 Agentic 安全检查清单应当分为三个层级：扫描 Agent 生成的代码（BrassCoders 覆盖这一层）；审计 Agent 可以访问的工具（最小权限原则）；记录 Agent 在 CI 中执行的每一次自主操作。

第一层只需在 CI 中增加一个步骤：将 brasscoders scan . 添加到 workflow。它会运行全部 12 个 scanner——Bandit、Pylint、Pyre/Pysa、Semgrep、ast-grep、detect-secrets，以及六个自定义 detector——并以 YAML 格式输出发现的问题。无须额外配置，五分钟即可接入。

第二层是访问控制。NIST AI Risk Management Framework 将其称为“govern”，也就是明确 AI 系统可以接触哪些数据、执行哪些操作。对于 Python Agent 来说，这意味着：工具定义必须具有明确的作用域；不允许在项目目录之外写入文件系统；在测试环境中，禁止 Agent 生成的代码发起出站 HTTP 请求。

第三层是日志记录。当 Agent 在 CI 中自主运行，而不是在编辑器里以交互方式运行时，每一次工具调用都应该写入结构化日志。这并不是什么高深的安全工程，而是任何具有外部副作用的自动化流程都应该具备的审计轨迹。

这三个层级无法相互替代。代码层面的安全检查无法发现配置错误的工具权限；最小权限访问控制无法发现已提交的 secret；日志记录无法发现 SQL 注入。三者必须并行实施。

BrassCoders 覆盖 Agentic 风险面的哪些部分

BrassCoders 在 Agent 生成代码之后运行，负责发现 AI 编码 Agent 遗留的安全问题，包括硬编码凭据、生成式 query 中的 SQL 注入、不安全的 subprocess 调用，以及 Agent 生成的 Python 代码中的虚假 import。

benchmark 直接说明了效果。在一项已公开的测试中，研究人员使用具有代表性的 Python 代码测试了 12 个由 AI 生成的安全 bug。仅使用 Bandit 时，发现了 12 个问题中的 6 个；BrassCoders 则发现了 12 个问题中的 11 个。差距来自自定义 scanner——AI-pattern detector、privacy/PII scanner，以及 Pyre/Pysa 提供的 taint analysis——这些都是 Bandit 不具备的检测层。对于 Agentic 代码而言，AI-pattern scanner 和 secret-pattern scanner 尤其重要，因为 Agent 产生虚假 API 调用和 fallback 凭据的概率高于人类开发者。

OSS core 免费提供，采用 Apache 2.0 许可证，无须注册账户，也不会发起任何出站网络请求。使用 pip install brasscoders 安装，然后针对任意 Python 项目运行 brasscoders scan . 即可。BrassCoders Paid 会通过托管 gateway 增加基于 embedding 的增强处理，对原始发现结果进行排序和去重。Paid 方案的价格为每位开发者每月 12 美元；gateway 只会发送已经脱敏的发现结果，以及最多 7,500 个字符的项目签名——绝不会发送原始源代码。

Agentic AI 并没有改变好代码应有的样子。它改变的，是坏代码积累的速度。

如需采取进一步行动，你可以考虑屏蔽此人和/或举报滥用行为。