AI Agent绕过网关后，运行时安全还能兜底吗？

一个被忽视的架构裂缝：当子代理握有API密钥

Reddit上一位开发者提出了一个颇具穿透力的问题：如果AI Agent能绕过网关（Gateway），运行时安全（Runtime Security）还有意义吗？

他的设想场景并不复杂。一个网关负责检查每一次工具调用，对照任务级权限、读取预算和审批策略。这套机制在正常路径下运转良好。问题出现在某个子代理（Sub-agent）直接拿到了API密钥，绕过网关去调用底层服务。此时策略本身没有错，错的是执行边界已经消失。

这个漏洞的核心不在于“策略写得对不对”，而在于“策略在哪里被执行”。如果执行点可以被跳过，再细粒度的权限控制都只是装饰。

网关不是安全边界，只是编排层的一部分

很多Agent框架把网关当作安全中枢来设计。所有工具调用经过网关，网关负责鉴权、审计、限流。这种集中式思路在单体Agent场景下表现不错。

但一旦系统演化出子代理、多框架混用、自托管运行时，网关的覆盖范围就变得脆弱。子代理可以自行建立HTTP连接，可以用环境变量里的密钥直接调用外部API，可以启动一个不被编排器感知的本地进程。这些路径都不会经过网关。

原帖作者追问了几个关键点：代理是否应该拥有直接的提供商凭证？在自托管环境中，如果无法完全控制Agent运行时，如何强制所有工具访问都经过网关？按框架分别实施管控，是合理的退路，还是会制造虚假的安全感？

这些问题指向同一个结论：网关是编排层的一部分，但它不是安全边界本身。 把网关当作唯一防线，等于把安全押注在“所有调用都乖乖走这条路”的假设上。

凭证管理才是真正的边界

如果让我回答原帖的第一个问题：代理不应该直接持有提供商凭证。这是目前最可控的边界设计。

具体做法可以分几层。短期凭证通过STS或类似机制动态签发，绑定到具体任务和会话，过期即失效。凭证代理（Credential Broker）在网关侧持有长期密钥，代理请求时换取短期令牌，子代理永远看不到长期密钥。网络层约束通过出站策略限制，只允许运行时访问网关地址，阻断直连外部API的能力。

这些手段的核心逻辑是一致的：把凭证从Agent进程里拿走，放到Agent无法直接读取的地方。只要凭证不在Agent手里，绕过网关就无从谈起。

作者在构建AegoTrax这个开源运行时安全项目时，显然也在思考同类问题。他提到想了解不依赖集中式网关的架构方案，这说明他也意识到单点网关的局限性。

STS（Security Token Service，安全令牌服务） 是一种按需签发临时、有限权限凭证的服务，典型代表是 AWS STS。它的核心价值在于：调用方用长期身份（如IAM角色）向STS换取一组有效期通常为15分钟到数小时的临时凭证，凭证自带过期时间和权限范围。对Agent场景而言，这意味着即使临时凭证被窃取，攻击窗口也被压缩到分钟级，且权限被限定在特定任务范围内。

Credential Broker（凭证代理） 是这一思路在架构上的延伸：它作为可信中间人持有长期密钥，Agent永远接触不到原始凭证，只能拿到代理按任务换发的短期令牌，且所有换发行为都记入审计日志。这实际上把"谁能用密钥"变成了"谁能通过代理获得令牌"，边界从进程内存转移到了受控服务上。

自托管环境的困境与务实取舍

自托管环境是这个问题最棘手的场景。你无法完全控制Agent运行时，用户可能用任意框架、任意语言、任意部署方式。这时候网关的强制力取决于用户的配合程度。

按框架分别实施管控是常见的退路。在LangChain、CrewAI、AutoGen等框架层面拦截工具调用，做权限检查。但这个方案有个明显问题：它制造的是框架级安全感，不是系统级安全感。用户换一个框架、写一个自定义工具、直接调requests库，管控就失效了。

更务实的路线可能是：在操作系统或容器层面做网络隔离，配合凭证代理和短期令牌。这样即使框架层被绕过，网络层仍然拦得住。代价是部署复杂度上升，对自托管用户的运维能力有要求。

原帖作者问“按框架执行是否合理”，我的判断是：可以作为辅助层，但不能作为主防线。它适合做开发期的提示和审计，不适合做生产环境的强制边界。

操作系统或容器层面的网络隔离通常借助Linux的eBPF或iptables/nftables实现：前者可以在内核态挂载程序，对进程级出站连接做细粒度过滤，甚至识别DNS查询；后者通过规则表只放行指向网关地址的流量，其余全部丢弃。两者都能在框架被绕过时提供兜底，但都需要root权限或专用容器运行时（如gVisor、Firecracker）支持。

对于自托管用户而言，这意味着安全责任从"框架配置"上移到了"基础设施配置"。若用户使用Docker，可通过网络策略和自定义bridge限制出站；若在Kubernetes中，则可用NetworkPolicy。选择哪种取决于用户愿意承担多少运维复杂度——这也是自托管安全始终难以"开箱即用"的根本原因。

架构选择：集中式与去中心化的权衡

原帖提到想了解不依赖集中式网关的架构。这个方向值得展开。

去中心化方案通常采用sidecar模式：每个Agent进程旁边跑一个安全代理，所有出站流量经过sidecar。sidecar负责凭证注入、策略检查、审计日志。这样不需要一个中心网关，但每个Agent实例都需要配套sidecar，运维成本转移到部署层。

另一种思路是能力令牌（Capability Token）模型。Agent不持有API密钥，而是持有一个签名的能力令牌，声明“此令牌允许调用服务X的接口Y，有效期N分钟”。服务端验证令牌签名和范围。令牌由可信的签发服务生成，Agent无法伪造。这种模型下，网关可以不存在，边界由令牌本身承载。

两种方案各有代价。sidecar增加部署复杂度，能力令牌需要服务端配合改造。选择哪种，取决于你对现有基础设施的控制程度。

Sidecar模式源自服务网格（Service Mesh）的经典设计，Istio、Linkerd等项目中每个业务Pod旁都挂一个代理容器，业务流量被透明劫持到sidecar再出站。迁移到Agent场景时，sidecar承担的不再只是mTLS和负载均衡，而是凭证注入、工具调用策略校验和审计。好处是Agent进程完全无感，无需修改业务代码；代价是每个Agent实例都要配套一个sidecar，在Kubernetes里尚可接受，在裸机或本地开发环境中运维负担明显。

Capability Token（能力令牌） 的思想可追溯到不可伪造的、自包含的授权凭证，如Macaroon和JWT。令牌本身编码了"能做什么"（服务X的接口Y）、"有效期多久"、"由谁签发"，服务端只需验证签名和范围即可放行，无需回查中心网关。这使得授权决策随令牌一起流动，天然契合去中心化。

没有银弹，但有优先级

回到最初的问题：运行时安全能否保护能绕过网关的Agent？

答案取决于你如何定义“运行时安全”。如果它只是网关里的一段策略代码，那保护不了。如果它是一套覆盖凭证管理、网络隔离、令牌签发的纵深体系，那它可以兜底。

优先级大致如下：凭证不落地到Agent进程，这是第一道也是最重要的一道；网络层限制出站，这是第二道；框架层拦截和审计，这是第三道，用于发现异常而非阻止异常。

原帖作者的AegoTrax项目试图在这个方向做探索，开源社区对运行时安全的讨论还处于早期。如果你在设计Agent系统，建议先回答一个问题：你的凭证在谁手里？ 这个问题的答案，比网关策略写得多精细更能决定系统的真实安全边界。