# 为什么端点检测会与失控的人工智能代理作斗争

> EDR 旨在发现不良二进制文件和不良行为。被注入指令劫持的人工智能代理不会使用任何一种方法：它通过您已经信任的工具进行操作。老实说，这对于国防意味着什么。

HisnLabs Security & Research Team · Published 2026-09-25
Canonical: https://hisnlabs.com/zh/blog/death-of-passive-defense-static-edr-agentic-attacks

端点检测和响应花了二十年的时间很好地回答了一个问题：这个过程是否做了恶意代码会做的事情？它检查签名、监视异常行为并标记未经授权的权限升级。具有工具访问权限的人工智能代理打破了这个问题的前提，不是因为它是恶意代码，而是因为它是一个受信任的程序，可以被说服滥用其自己的、完全合法的访问权限。

## 这个问题的前 AI 版本已经有了名字

使用合法的、经过签名的程序来执行恶意操作并不是什么新鲜事。 MITRE ATT&CK 将其分类为 [系统二进制代理执行 (T1218)](https://attack.mitre.org/techniques/T1218/)：“使用受信任的数字证书签名的二进制文件通常可以在受数字签名验证保护的 Windows 系统上执行”，这正是一旦受信任的二进制文件本身发挥作用，白名单和签名检查就会陷入困境的原因。人工智能代理将同样的弱点扩展到根本不需要预先加载恶意代码的程序：它可以在运行时通过它读取的文本进行重定向。

## 被劫持的特工是一个困惑的副手

这里适用的术语是[困惑的副手问题](https://en.wikipedia.org/wiki/Confused_deputy_problem)：“一个计算机程序被另一个程序（具有较少特权或较少权限）欺骗而滥用其权限。”为代理提供真正的工具，然后让它读取您未审查的内容，并且它可以接受该内容的指导。这正是 [OWASP 的提示注入条目](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) 所描述的模式，并且它已经被证明，而不仅仅是理论化：Invariant Labs 的 [2025 年 5 月 26 日报告](https://invariantlabs.ai/blog/mcp-github-vulnerability) 展示了一个编码代理，读取公共存储库中看似普通的 GitHub 问题，遵循其中的隐藏指令，使用合法授予的工具来公开私有存储库数据。研究人员自己的结论是：“这不是 GitHub MCP 服务器代码本身的缺陷，而是必须在代理系统级别解决的基本架构问题。”

*说明：EDR 日志条目看起来是什么样子*

```text
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling

# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.
```

这是真正的盲点：不是任何一种产品中的差距，而是“代理完成其正常工作”和“代理被劫持以滥用其正常工作”的日志条目在流程级别上可能是相同的事实。二进制文件没有任何变化。系统调用模式并不是什么新鲜事。仅请求背后的意图发生了变化，并且意图不是进程日志中的字段。

## 什么实际上减少了这种情况，什么没有减少这种情况

值得精确地了解命名此模式的人实际上推荐的内容。 Simon Willison 描述了在一个代理中将私有数据访问、不可信内容暴露和外部通信结合在一起的[“致命三连胜”](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)，他明确指出，避免这种组合才是真正的解决方案，而不是附加的护栏：“保持安全的唯一方法是完全避免这种致命的三重组合。”他对那些声称能够在事后可靠地捕获注入指令的产品公开表示怀疑，并指出“我们仍然不知道如何 100% 可靠地防止这种情况发生”，并且 95% 的捕获率对于安全控制来说“非常不及格”。

> **Warning:** 没有任何一种工具（包括防火墙）可以将被劫持的代理变成安全的代理。现实的目标是减少被劫持的代理可以执行的操作和达到的范围，而不是承诺它根本不会被劫持。

- 设计第一：为代理提供其任务所需的最窄的工具和数据访问权限，因此成功注入滥用的可能性较小（Willison 和 Invariant Labs 都指出的架构修复）。
- 原则上，每次都将代理读取的任何您未编写或审查的内容、问题、获取的页面、下载的文件视为不可信输入。
- 在设计和审查还不够的情况下，数据泄露尝试不能跳过的一步就是网络连接中断。对每个进程进行监视或限制并不能防止代理被愚弄，但它是一个真正的、独立的层，并不依赖于首先识别注入的指令。

## FireAI 和 HisnLabs 在其中扮演的角色

No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.

FireAI 是 HisnLabs 自己的产品：一款直接在 Mac 上运行的 AI 防火墙。它用通俗易懂的语言显示你的应用建立的每一个连接，并让你决定哪些数据可以离开你的 Mac——它的 AI 在本地运行，因此你的流量永远不会发送给我们或任何其他人。HisnLabs 的安全研究团队负责让这些判断保持准确：归类哪些域名只是普通的遥测、哪些属于真正的服务，追踪连接背后的国家和网络，并用真实的流量模式训练设备端模型（FireAI Pilot 功能）——这一切都不会离开你的 Mac。

你可以阅读它背后的技术决策，或试用 FireAI 17 天：[HisnLabs 出品的 FireAI](https://hisnlabs.com/fireai/zh/download)。

## Sources

- [MITRE ATT&CK T1218: System Binary Proxy Execution](https://attack.mitre.org/techniques/T1218/)
- [Simon Willison: The Lethal Trifecta for AI agents](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)
- [Invariant Labs: MCP Security Notification — GitHub MCP](https://invariantlabs.ai/blog/mcp-github-vulnerability)
- [Wikipedia: Confused deputy problem](https://en.wikipedia.org/wiki/Confused_deputy_problem)
- [OWASP Gen AI Security Project: LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)