CrowdStrike阐述AI流量网关的集中控制原则：能检查什么、不能阻止什么

当AI代理从回答问题转向执行操作时，安全团队面对的不只是可见性问题，而是控制问题。CrowdStrike在其Falcon AI Gateway正式可用的说明文章中提出了一个具体原则：把批准路径变成唯一路径。这意味着团队用已有的网络控制阻断应用和负载对模型提供商的直接连接，只允许经过网关的流量到达模型端。

这个架构的运作方式很直接：网关对每个请求进行身份验证，将其路由到正确的提供商和模型，施加用量限制，并在请求到达提供商之前和响应返回时分别执行Falcon Guardian策略。管理员可以在Anthropic、Amazon Bedrock、Microsoft Foundry和Google Vertex AI之间切换，而无需重新配置每个工作负载。应用只需更改基础URL指向网关并使用网关密钥，即可继续使用原有API格式。

文章中最有价值的部分是明确划出了网关的能力边界。Falcon AI Gateway和Falcon传感器共享同一套Guardian策略模型，但各自在不同层面执行：传感器作用于端点，包括代理运行的本地进程、文件和命令；网关作用于经过它的流量，无法阻止本地进程。这意味着如果AI代理在本地执行了危险操作，网关看不到；如果代理向模型发送了包含敏感数据的提示词，传感器可能看不到，但网关可以拦截。

正因为流量只经过一个点，Guardian中的AI Kill Switch可以切断代理对模型的访问。但这一能力仅限于经过网关路由的流量——如果代理绕过了网关直接调用模型，Kill Switch无效。CrowdStrike称这一架构源自其内部运行AI Hub网关的经验，该网关已为全球数万员工服务数年，团队在过程中学到的一个关键点是保持请求路径尽可能短，因为每一跳都增加故障点和延迟。

对正在评估AI代理安全架构的团队来说，这篇文章的实际贡献是提供了一个清晰的分层模型：流量层网关处理提示词检查、响应过滤、用量控制和Kill Switch；端点层传感器处理本地进程、文件操作和命令执行。两者覆盖不同的攻击面，缺一不可。但需要记住，这全部是厂商对自身产品设计的描述，其实际拦截效果和策略覆盖范围未经独立验证。