很多开发者在做 Agent 应用时，会把安全问题放到很后面：先把工具接起来，先让流程跑通，先做一个 demo。这个顺序可以理解，但不能长期这么做。只要 Agent 能读文件、调 API、改代码、访问网页，安全就不再是可选项。

GitHub 最近推出面向 agentic AI 漏洞的 Secure Code Game，并公开讨论 GitHub agentic workflows 的安全架构。这个信号值得注意：Agent 安全正在从研究话题进入开发者日常训练。

Agent 的风险来自“会做事”

传统聊天机器人说错话，主要风险是误导。Agent 说错话之后还可能继续执行：读取敏感文件、调用错误接口、提交错误代码、把用户输入当成指令执行。能力越强，风险面越大。

这也是为什么 prompt injection 在 Agent 场景里更麻烦。它不是让模型“回答得不好”，而是可能让模型在工具链中做错事。一个隐藏在网页、Issue、文档、邮件里的恶意指令，可能被 Agent 当成任务上下文吸收进去。

最基本的防线不是玄学

Agent 安全听起来很新，但很多基础原则并不神秘。高风险工具要最小权限，写操作要有确认，外部内容和系统指令要隔离，敏感数据不要默认进入上下文，工具调用要记录日志，关键动作要可回滚。

这些做法不会让系统绝对安全，但能显著降低“模型一糊涂就把事情做坏”的概率。对个人开发者来说，这比研究复杂论文更重要。先把权限边界、日志、确认和回滚做好，已经能避开很多低级事故。

开发者要改变默认心态

过去我们调用第三方 API，会默认它是确定性组件：输入什么，大致输出什么。Agent 不是这样。它是概率系统加工具执行环境，既会理解错，也会被上下文误导，还可能在多轮任务里逐渐偏离目标。

因此，开发者不能只问“这个 Agent 能不能完成任务”，还要问“它失败时会造成什么损失”。如果失败结果只是生成一段不合格文案，问题不大；如果失败结果是删除数据、泄露密钥、修改生产配置，就必须设计硬边界。

我的判断是：未来两年，Agent 安全会成为 AI 应用开发的基本功。不是每个开发者都要成为安全专家，但每个会给模型接工具的人，都应该理解 prompt injection、权限隔离、审计日志和人工确认。不会这些，就像会写后端但不懂鉴权，迟早要交学费。

参考：GitHub Blog《Hack the AI agent: Build agentic AI security skills with the GitHub Secure Code Game》、GitHub《Under the hood: Security architecture of GitHub Agentic Workflows》。