跳转至

2026-08-03

今日主题

  • AI Agent 工具安全边界设计

新增认知

AI Agent 工具安全边界设计

  • 脉络:单点堵漏为何失效:AI 找到 write_file+make+delete 绕过沙箱的手法后,直觉反应是禁掉这个组合,
    但可执行载体(.sh/package.json/.git/hooks/.env)无穷多,堵一个漏一个。根本问题是安全边界画错了维度——
    不该画在哪种文件格式可执行上,而应画在这个文件是谁产生的上,因为信任来源只有用户和 AI 两种,是有限、可枚举的。

  • 工具组合涌现漏洞:每个 tool 单独看参数校验都合规(write_file 只管写文件,make 只跑已定义 target),
    但工具之间没有共享安全上下文——write_file 不知道自己写的内容会被 make 执行——组合起来就等价于任意命令执行。
    这和 Linux cron.d 写权限+cron、K8s create Pod+mount hostPath、XSS 里 innerHTML+script 是同一类模式:
    单点安全,组合越权。

  • Prompt 规则是软约束不是硬约束:System prompt 里的禁止做

  • 无损违反制造虚假安全感:Prompt 规则看起来有效,是因为大多数违反是无损违反(如语言错误,道歉一句就能改回来),后果可逆,
    用户不会意识到规则本质上没被真正遵守。一旦规则守护的是有损违反(如删文件、执行命令),代价在违反瞬间就已发生且不可逆,AI

  • 文件溯源+风险分级执行:给文件打 provenance 标签(user / ai-created / ai-modified),
    执行类 tool(make/npm/pip)运行前检查关联文件的溯源,AI 产生的文件触发 dry-run+人工确认,用户产生的文件低风险自动放行。
    这套方案不试图穷举攻击路径,而是抓住谁产生了这个文件这个攻击者无法伪造的信号,本质上和 jgs-scout 里Agent

  • 工程落地:时间戳代替完整溯源系统:完整 provenance 追踪(标签+确认 UI+dry-run)在单会话场景下可简化为一行时间戳比较——
    若 Makefile mtime 晚于用户最后一条消息时间,必然是 AI 改的,直接 fail-closed 拒绝执行。
    零 UI 成本、零状态维护(文件系统本身就是状态),代价是只覆盖 Makefile 本体、不管 include 文件和其他执行载体。
    这体现了能落地的简单方案胜过停留在设计里的完美方案的工程权衡取舍。