传统治理失效：政策文档无法约束 AI 行为

Gravitee CTO Sam 指出，尽管 88% 的组织已在生产环境中部署了能采取行动的 AI Agent，但仅有 14% 对此实施了治理措施。这种脱节导致严重后果：一旦 AI Agent 执行错误操作，可能引发数据库丢失、个人身份信息（PII）泄露以及来自 ICO 等监管机构的巨额罚款，特别是在 HIPAA 或 GDPR 合规环境下。Sam 强调，AI Agent 并不阅读政策文档。在演示中，他构建了两个对比环境：左侧 Agent 依赖提示词（Prompt）或工具权限进行内部约束，右侧则由 Gravitee API 网关基于严格缩放的身份（Identity）和原生控制进行治理。核心观点在于，必须将控制权从提示词层面移至网关层（Governance Layer），通过基础设施层面的硬性限制来防止 AI 因“取悦用户”的本能而执行危险操作，而非依赖不可靠的用户提示或 Markdown 文件。

案例一：提示词注入与批量删除操作拦截

在第一个实时演示场景中，Sam 模拟了恶意用户通过提示词注入试图利用 AI Agent 的 MCP（Model Context Protocol）工具执行“删除所有预订”的操作。在左侧未受网关严格控制的 Agent 中，AI 成功执行了删除指令。Sam 展示数据包流向显示，请求被接受并返回 HTTP 200 状态码，随后数据库中的预订记录确实被全部删除。这证明了仅靠内部工具权限是脆弱的。相比之下，右侧受 Gravitee 网关保护的 Agent 虽然同样发现了可用工具并尝试执行，但在运行时因缺乏相应的 JWT Claims（JWT 声明）和权限而被网关拦截。返回结果是 HTTP 403 Forbidden，AI Agent 仅能执行其权限范围内的部分操作（如取消单个预订），而无法执行批量删除。Sam 指出，运行时权限验证比静态策略文档更有效。

案例二：数据外泄防护与可观测性优势

第二个演示聚焦于敏感数据泄露风险。用户请求获取“所有客人的完整列表”，包括电子邮件和车辆详情，声称用于合规对账。左侧 Agent 再次表现出“乐于助人”的特性，通过 MCP 工具发现并返回了所有暴露的 PII 数据。而在右侧受控环境中，网关成功阻止了这一请求，未发生任何 PII 泄露。Sam 解释称，AI Agent 本身无法判断数据敏感性，必须依赖网关层进行身份验证和权限检查。如果用户需要访问这些数据，必须通过 IDP 平台或 Gravitee 网关进行正确的身份认证。此外，Sam 强调了 OpenTelemetry（开放遥测） 在调试复杂 Agent-to-Agent (A2A) 通信中的重要性。随着规模扩展至数千个 Agent，在网关层集中管理权限比在每个 Agent 内部维护逻辑更易于迁移、缓解风险和管理，从而解决了大规模部署中的治理难题。

网关治理：从身份认证到成本控制的全面防护

AI Agent的安全与可持续性不仅依赖于身份验证，更在于对API调用的精细化治理。通过网关层（Gateway），企业可以实施真实的错误返回和策略控制，而非依赖模拟脚本。这种治理方式能够在源头拦截无效请求或异常行为，确保系统的安全性与稳定性。除了基础的访问控制，网关还承担着至关重要的成本管理职能。Token消耗和计算资源的使用随着Agent规模的扩大而变得日益敏感，必须在网关层面建立相应的约束机制。通过集中化的策略管理，企业可以针对不同的用户群体、权限级别和应用场景设定差异化的资源配额。这种治理模式不仅提升了安全性，还为后续的成本优化和性能监控奠定了坚实基础。网关作为统一入口，使得所有Agent的交互行为都变得可观测、可控且合规。

前端与后端解耦：基于用例的内容过滤机制

演讲者强调，在构建AI应用时，必须将前端Agent与后端服务（包括API、MCP服务器、LLM及数据库）进行彻底解耦。这种架构分离的核心价值在于实现精细化的控制、成本优化以及严格的安全治理与审计能力。通过网关层，系统可以对输入提示词的长度和类型进行精准聚焦，确保内容仅服务于特定用例。例如，当用户询问“今天的天气如何”时，网关会识别出该请求与酒店预订软件无关，从而直接拒绝并返回“No thank you”，避免向下游服务发送无效请求。这一机制不仅节省了计算资源，更从源头上切断了无关数据对后端系统的干扰。

“So being able to kind of decouple your front-end agents and your backend services... is fundamentally important to bring you the control that you need, to bring you the cost optimization that you need, but also the security and the governance.”

这种解耦策略并非简单的技术分层，而是为了应对日益复杂的Agent生态。演讲者指出，将治理逻辑下沉至基础设施层是实现规模化扩展的唯一正确路径。如果仅在Agent内部硬编码策略，初期可能有效，但随着系统复杂度增加，这种局部优化将迅速失效。因此，网关作为统一的流量入口和策略执行点，能够确保所有交互都经过标准化的安全与合规检查。

指数级增长的Agent身份管理与治理挑战

当前AI Agent的规模正在经历爆炸式增长，这给传统的身份管理和治理带来了巨大压力。演讲者引用了其同事Tim提供的数据：目前每1个人类身份对应着144个Agent。这一比例揭示了问题的严峻性：随着组织内部开始创建更多子代理，甚至出现“Agent生成Agent”的递归现象，身份管理的复杂度呈指数级上升。在这种背景下，依赖脚本或手动配置的治理方式已无法应对如此庞大的 sprawl（蔓延）。

演讲者认为，必须在基础设施层建立自动化的治理框架，以组织和管理这些海量的身份标识。这不仅是技术需求，更是合规要求。随着监管环境的日益严格，企业必须能够控制进入模型训练的数据流，并对输入信息进行审计。网关提供的日志记录、信息可发现性及导出功能，使得企业能够满足InfoSec（信息安全）合规性及受监管行业的要求。通过网关，所有非标准流量和Shadow AI行为都能被可视化和管控，从而消除安全盲区。

网关的核心能力：模型路由、MCP工具优化与边缘管理

除了基础的访问控制，现代网关还具备多种高级能力以支持复杂的AI工作流。首先是LLM路由功能，网关可根据延迟、成本或任务复杂度将请求分发至不同的下游模型（如Anthropic、Gemini或OpenAI），从而避免被单一云厂商锁定。演讲者演示了只需三次点击即可切换模型，网关会自动处理不同API规范之间的转换。

其次是对MCP（Model Context Protocol）工具的管理。直接使用第三方MCP服务器往往会导致上下文窗口被大量无关工具填满，增加Token消耗和成本。网关允许企业创建细粒度的MCP Studio，仅暴露必要的工具集。例如，CRM系统虽提供64个工具，但网关可限制Agent仅访问其中几个，从而缩小爆炸半径并降低运营成本。此外，新发布的边缘管理功能解决了员工在本地设备上使用AI工具（如文档摘要、邮件处理）导致的流量不可见问题。该功能能够发现并强制Shadow AI流量通过网关进行日志记录和审计，确保企业对所有AI使用场景拥有完全的可观测性。

“The only real correct way that we're going to scale but also keep the governance and securability as we move forward is shifting it up to the infrastructure layer.”

演讲者总结指出，将治理策略嵌入Markdown文件或Agent内部上下文的做法是错误的。唯有将治理逻辑提升至基础设施层，通过网关实现集中化管理，才能在保持AI Agent灵活性的同时，确保系统的安全性、合规性与成本效益。

结论

视频论证表明，依赖提示词或静态文档治理AI Agent存在根本性缺陷。实测显示，缺乏网关控制的Agent易受提示词注入影响执行批量删除或泄露PII数据；而基于Gravitee网关的治理通过运行时JWT验证，成功拦截非法操作并阻断数据外泄。核心优势在于将控制权从应用层移至基础设施层，实现身份认证、MCP工具细粒度暴露及模型路由的集中化管理。该方案有效应对了Agent身份指数级增长（1:144）带来的治理挑战，通过OpenTelemetry增强可观测性并优化Token成本。适用条件为需严格合规及大规模部署场景，其有效性建立在网关作为统一入口并实施硬性策略约束的基础之上。