Google ADK 零信任 AI 代理安全指南：从提示词走向可验证控制

快速摘要

Google 最新的 Agent Development Kit 零信任实践提醒我们：AI 代理不应被当成更聪明的聊天框，而应被当成生产软件来设计。Google Developers 文章用客服与退款代理示例说明，敏感写入需要签名，不可信代码应在沙箱中运行，输入和输出护栏要像普通业务逻辑一样被测试。团队在选择 AI 开发工具时，应该关注可验证身份、受限执行、可审计流程，以及能抵抗提示注入的控制措施。

为什么现在必须关注零信任代理

AI 代理正在进入工单、内部后台、IDE、客服和运营流程。风险模型因此改变。一个只起草回复的聊天机器人可以由人工复核；但一个能批准退款、创建拉取请求、更新记录或调用私有 API 的代理，就需要和生产系统一样的安全设计。Google Developers 的文章 https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit/ 重要之处在于，它把“安全代理”落到架构层面，而不是停留在口号。

零信任的核心是：不要把提示词当边界。攻击者可以把指令藏在工单、文档、网页、文件名或工具输出里。系统提示可以要求模型忽略恶意内容，但当涉及金钱、数据、身份或代码变更时，运行时必须有确定性的限制。模型负责推理，平台负责强制执行。

值得复制的架构思路

第一是把意图和权限分开。代理可以判断“应当退款”，但真正的写入请求仍应由加密身份签名，并由接收服务验证。这样管理员能够追踪哪个代理、哪个流程、哪次请求执行了操作，也能发现传输过程中是否被篡改。

第二是沙箱执行。代理常常需要运行代码片段、转换文件、读取数据或调用工具，但这不意味着任意代码都可以在主机上拥有广泛权限。类似 gVisor 的隔离方式可以降低生成代码或外部工具行为异常时的损害。开发者已经会隔离容器和 CI 任务，代理工作负载也应如此。

第三是语义防火墙。传统规则能检查 URL 和文件类型，但代理还需要理解操作含义：退款是否超过阈值，回答是否泄露私密数据，命令是否具有破坏性，工具调用是否超出用户请求。此类规则应足够确定，能放进 CI 测试，而不是只依赖提示词祈祷。

对软件选型的影响

在 https://www.bttc.site/software 比较 AI 编程助手、自动化工具或生产力软件时，应把安全证据加入清单。询问工具是否支持独立服务身份、签名操作、范围化凭据、审批门槛、沙箱工具、审计日志和策略测试。漂亮的代理演示不如清晰的权限边界可靠。

小团队同样适用。第一天也许不需要完整企业平台，但仍需要边界。先限制代理能访问的代码库、云账号、文档和支付系统。高风险写入保留人工确认。记录决策和工具调用日志。准备一组恶意工单和混淆指令，用来测试升级后的代理是否仍会安全失败。

团队落地清单

先列出动作清单：代理可以读文档、搜索代码、创建工单、修改文件、运行命令、退款、发消息或调用 API。按可逆性和影响范围排序。读取公开 FAQ 风险较低，修改账单、生产配置、认证逻辑或客户数据则属于高风险。

接着分配身份。每个代理或流程都应使用范围很窄的服务身份，而不是借用开发者个人凭据。尽量使用短期令牌，记录每次特权调用，并让接收服务验证签名或声明。

然后定义执行边界。生成代码、第三方工具响应和用户附件应在受限环境运行。除非必要，不开放网络访问。只挂载最少文件。为工具使用设置时间、内存和命令限制。

最后把策略当代码测试。准备提示注入、超额退款、敏感数据请求和破坏性命令样例，在 CI 或发布检查中运行。目标不是让模型完美，而是让不安全行为默认失败。

常见问题

强系统提示足够安全吗？

不够。系统提示是有用指令，但不是安全边界。敏感操作需要范围化凭据、签名写入、沙箱、允许列表、审批和审计策略。

Google ADK 在这里指什么？

它是用于构建代理应用的开发框架。零信任指导展示了如何把代理工作流与身份、签名、沙箱和确定性护栏结合。

BTTC 读者如何用于选工具？

把代理安全当作软件选择标准。比较工具时查看审计日志、权限边界、安全执行、策略导出和文档证据，并可继续阅读 https://www.bttc.site/blog 的相关文章。

结论

零信任 AI 代理不是为了拖慢自动化，而是为了让自动化足够安全，可以承担真实工作。Google ADK 文章的价值在于把代理安全变成工程清单：签名写入、沙箱执行、检查输入输出、测试护栏，并选择能证明控制能力的工具。