AI Agent 安全已经从小众工程问题变成了主流风险话题。现在大家搜索的热词，不只是学术概念，而是产品团队、安全团队和创业者在 Agent 接入生产数据、客户流程、支付系统、开发机器或内部工具前必须处理的真实风险。
结合当前安全讨论、研究论文、公开事件报道和 OWASP 风格的安全方向，2026 年最值得关注的 AI Agent 安全关键词包括：prompt injection、indirect prompt injection、MCP tool poisoning、tool permissions、agentic ransomware、AI coding agent security、data exfiltration、LLMjacking、human approval gates、agent observability、audit logs、sandboxing 和 trust boundaries。
1. Prompt injection
Prompt injection 仍然是最核心的搜索词，因为它最容易让非安全背景的人理解问题：攻击者试图让模型服从错误指令。在普通聊天机器人里，这可能只是生成错误答案；但在 Agent 里，后果可能严重得多，因为模型可能拥有工具、记忆、文件、浏览器权限或 API 凭证。
实际经验很简单：不要把 prompt 当成安全边界。System prompt 可以帮助塑造行为，但它不等于授权、输入校验、网络隔离或审批控制。如果 Agent 能发邮件、修改数据库、打开 pull request、运行终端命令或调用支付 API，真正的安全控制必须在 prompt 之外。
2. Indirect prompt injection
Indirect prompt injection 正变得比直接 prompt injection 更重要，因为 Agent 会读取外部内容。恶意指令可以藏在网页、客服工单、GitHub issue、PDF、Slack 消息、日历邀请、表格或文档里。用户自己并没有输入恶意内容，Agent 只是为了完成任务读取了不可信内容。
所以 RAG 和浏览型 Agent 必须区分信息来源。Agent 需要知道哪些是用户指令，哪些是检索证据，哪些是工具输出，哪些是不可信文本。团队应该测试恶意检索文本是否能改变 Agent 目标、泄露敏感信息或触发工具调用。
3. MCP tool poisoning
Model Context Protocol 是 Agent 工具体系里最热的方向之一，因为它让 Agent 发现和调用工具的方式更标准化。标准化有价值，但也带来新的攻击面。Tool poisoning 指的是恶意指令隐藏在工具描述、元数据、schema 或工具上下文中。工具表面看起来无害，却可能引导 Agent 做出不安全行为。
安全团队应该把工具定义当成代码和基础设施配置来管理。工具描述需要评审、版本管理、负责人、完整性检查，以及对异常变更的监控。一个工具不能因为出现在注册表里，或者名字看起来熟悉，就自动被信任。
4. Tool permissions
Tool permissions 是产品团队最应该落地的 AI Agent 安全主题。关键问题不是模型是否聪明，而是当模型犯错、被操纵、上下文不足或过度自信时，它到底被允许做什么。
每个工具都应该有权限等级。只读搜索的风险低于写入 CRM；起草邮件的风险低于直接发送邮件；列出文件的风险低于上传文件；在受限沙箱里运行命令的风险低于在开发者本机运行命令。高影响动作应该要求明确审批、策略检查，或使用权限很窄的独立服务账号。
5. Agentic ransomware
Agentic ransomware 是最近更受关注的新热词，因为公开报道已经开始描述 AI Agent 参与编排勒索攻击流程的案例。重点不在于每个单独战术都是新的。侦察、凭证滥用、数据发现、加密和勒索早就存在。变化在于 Agent 可以把这些步骤串起来，在失败时自动调整，并降低攻击所需技能门槛。
对防守方来说，这意味着速度和隔离更重要。如果攻击者能自动化发现和调整，团队就需要更快的凭证轮换、最小权限、异常检测、备份验证和事故演练。AI Agent 安全不仅是保护自己的 Agent，也包括防御攻击者使用 Agent。
6. AI coding agent security
AI 编程 Agent 很强，因为它能读取代码库、编辑文件、运行测试、安装依赖和执行 shell 命令。但当它处理不可信代码或文档时，这也很危险。恶意仓库可以把攻击指令伪装成普通安装说明，引导编码 Agent 执行不安全命令。
更安全的做法是默认陌生仓库、issue、markdown 文件、package script 和生成式说明都不可信。Coding Agent 应该在隔离环境中运行，对网络访问和 shell 执行要求审批，避免接触密钥，并记录操作，方便开发者事后审查。
7. Data exfiltration
Data exfiltration 会把模型错误变成真实业务事故。Agent 可能能访问客服工单、客户记录、源代码、分析数据、内部文档或凭证。如果 prompt injection 或 tool poisoning 能诱导 Agent 汇总、上传、邮件发送、粘贴或编码这些数据到外部位置，风险就非常具体。
有用的控制包括数据分级、输出过滤、目标地址白名单、检索范围限制、脱敏、密钥扫描和工具调用审计日志。Agent 不能因为生成了一个看似合理的理由，就把敏感数据移动到任意目的地。
8. LLMjacking
LLMjacking 指滥用他人的 LLM 凭证、额度或基础设施。对 AI Agent 来说，这个问题更重要，因为被盗 API key 可以被用来大规模运行自动化流程、侦察、钓鱼内容生成或恶意任务辅助。
这里仍然需要基础云安全能力：轮换 key、隔离环境、监控异常 token 消耗、设置每个 key 的限制、按工作负载限制模型访问，并在使用模式异常时报警。成本监控现在不仅是财务看板，也是安全信号。
9. Human approval gates
Human approval gates 是 Agent 自主性的制衡机制。它不应该用于每个小动作，否则 Agent 会变得没用。它应该用于不可逆、高成本、对外可见、法律敏感或安全敏感的动作。
好的审批界面应该说明 Agent 想做什么、为什么做、会使用哪些数据、会调用哪个工具、会改变什么，以及这个动作是否可回滚。用户审批的应该是具体操作，而不是一句模糊的“继续”。
10. Agent observability 和 audit logs
Agent observability 成为热词，是因为团队意识到普通应用日志不够用。Agent 需要记录 prompt、工具调用、检索来源、决策、审批、拒绝、错误、重试、成本、延迟和最终结果。没有这些 trace，故障分析就会变成争论。
审计日志应该回答四个问题：Agent 看到了什么、决定了什么、做了什么、谁批准了它。这对事故响应、客户支持、合规证据和回归测试都很关键。
11. Sandbox 和 trust boundary
Sandboxing 是降低影响范围的实用方法。如果 Agent 能运行代码、浏览网页、查看文件或调用工具，它就应该运行在受控环境中。沙箱应该定义文件访问、网络访问、环境变量、凭证、运行时限制和清理机制。
Trust boundary 也很重要，因为 AI Agent 会模糊传统边界。网页可能变成指令源，工具描述可能影响执行，检索文档可能影响业务动作，开发助手可能变成命令执行器。团队需要明确画出哪些输入可信、哪些不可信、哪些动作可回滚，以及策略在哪里强制执行。
如何使用这些热词
不要只把这些词当 SEO 关键词。应该把它们当上线检查清单。如果你的 AI Agent 处理真实工作流，就要问自己是否测试过 prompt injection、indirect prompt injection、tool poisoning、过高工具权限、数据外泄、Agent 日志、审批闸门、沙箱、凭证滥用和事故响应。如果答案是否定的，这个 Agent 还没有生产就绪。
参考资料
- OWASP Top 10 for Large Language Model Applications
- MITRE ATLAS
- The Attack and Defense Landscape of Agentic AI
- Are AI-assisted Development Tools Immune to Prompt Injection?
- 关于 agentic ransomware 的近期报道
如果要做更具体的检查，可以先使用 AI Agent 就绪度自评，或参考 AI Agent 工具风险登记表模板。