arXiv:2605.18414：提示词无法保护——带ABAC的MCP代理实现0%未授权工具调用

arXiv上发表的研究（2605.18414）为所有构建自主AI智能体的人带来了一个令人担忧的发现：当涉及工具访问控制时，提示词中的指令保护是不够的。只有架构层解决方案——在智能体和工具之间的中间层——才能保证可靠的保护。

为何提示词无法保护LLM智能体免受工具滥用？

即使在上下文中明确禁止，能看到工具列表的模型仍可能选择并非为当前用户设计的工具。作者Rohith Uppala在150个对抗性任务上进行了测试，任务分为四类攻击类别，使用三个语言模型——Qwen 2.5 7B、Llama 3.1 8B和Claude Haiku 3.5。结果明确：基于提示词的限制仅将UIR（未授权调用率——未授权工具调用的比率）降低了11至18个百分点，在每个场景中仍留有相当大的残余风险。

UIR衡量智能体成功调用未获授权工具的频率。即使有严格、精确措辞的指令，模型有时也会「忘记」限制，或被对抗性输入诱导绕过它们。

带ABAC的MCP代理如何在架构层解决问题

提出的解决方案在MCP（Model Context Protocol）层运作——该开放标准定义AI智能体如何发现和调用外部工具与服务。智能体不再直接与工具通信，而是引入一个管理MCP代理，执行ABAC（基于属性的访问控制）——基于用户、工具和上下文属性的访问控制模型。

代理在两个节点发挥作用：

1. 工具发现 — 未授权工具在列表阶段就从上下文中移除，模型在物理上无法选择它看不到的内容。
2. 工具调用 — 即使调用请求到达，代理也会在执行前将其拦截。

结果：UIR降至0%，中位延迟低于50ms——对大多数生产系统而言可忽略不计。

这对实践中的AI智能体开发意味着什么？

该研究计划在EMNLP 2026工业赛道发表，向构建智能体系统的工程师传达了明确信息：安全逻辑不能只存在于提示词中。正如Web应用不用代码注释保护API端点，而是使用中间件层和令牌，AI智能体同样需要架构边界——而不仅仅是言语约束。

对于使用MCP生态系统的项目（2025/2026年日益普及的做法），实施带ABAC策略的管理代理层已成为推荐的安全卫生措施，尤其在不同用户对工具集拥有不同权限的多租户和企业环境中。