如果智能体可以绕过 LLM 网关，它是否实际上充当了控制平面？

Reddit r/AI_Agents 新闻
llm-gateway agent-governance bypass-prevention ai-infrastructure security multi-agent-systems

摘要

本文探讨了当智能体能够绕过 LLM 网关时的局限性，并建议有效的治理需要结合出站执行和影子检测，以防止未经授权的访问。

许多团队现在在架构中集成了一个 LLM 网关。它路由模型调用、集中管理凭证、添加日志记录、应用速率限制，并可能处理开销跟踪。但存在一个相当基本的架构问题：当智能体根本不使用网关时会发生什么？例如： ┌──→ LLM 网关 ──→ 模型 智能体 ──────────┤ ├──→ 直接提供商 API ├──→ 直接 MCP/工具端点 └──→ 其他外部出口 此时，网关仍在执行其功能，只是不再治理智能体。这一区别很重要，因为流量控制和路径控制是不同的问题。我认为，网关应被视为智能体治理的一个组成部分，而非治理边界本身。像 LiteLLM、Portkey 和 OpenRouter 这样的工具在网关/代理层很有用。但代理无法执行从未到达代理的流量。更有趣的架构是： 智能体 ↓ 智能体网关 ↓ LLM 网关 / 治理工具 ↓ 模型 + API + 网络/出站执行 + 身份 + 影子发现 在 Lyzr Open Controller 中，我发现了一个有趣的领域：网关与出站执行和影子发现相结合，专门用于检测和关闭绕过路径，而不是假设通过网关路由流量就意味着智能体被治理。我认为，随着智能体实例在 Kubernetes、云智能体运行时、MCP 服务器和内部托管服务中变得更加分散，这将成为一个更大的问题。想知道人们在实际生产环境中是如何解决这个问题的：如果智能体拥有凭证和网络访问权限，可以直接调用模型或工具，那么什么实际上阻止了绕过？有兴趣听到实际有效的方法，而不是架构图上理论上应该有效的方法。
查看原文

相似文章

多智能体 LLM 谈判中的宪法规门控与确定性恢复：针对有状态对抗性 Gatekeeper 的消融实验

arXiv cs.CL

该论文研究多智能体 LLM 谈判系统中的三部分控制栈：5 条支柱运行时宪章、4 层 swarm 架构（Director、多数投票、Monitor、schema 硬门控）以及 Cognitive Annealing（确定性死锁检测与原子上下文清除恢复），并针对一个有状态对抗性 Gatekeeper 进行消融实验，发现确定性恢复机制在死锁场景中显著优于纯 LLM 引导。