当 Agent 开始访问核心业务，安全边界怎么守？Zentrix 把拦截放在调用之前

Zentrix AI 网关深度解读④：把身份、权限、内容、数据与行为控制带到 AI 调用真正发生的位置

一名工程师遇到了一段难以排查的程序错误。

他把代码复制到 ChatGPT，点击发送。几秒后，模型给出了答案。

问题可能解决了，但另一件更严重的事也已经发生：这段属于企业的内部源代码，被发送到了外部 AI 服务。

这并非假设。

案例：2023 年，三星电子半导体部门被曝发生三起类似事件。员工为了修改代码、优化测试程序和整理会议纪要，将内部源代码、设备测试信息及会议内容提交给了 ChatGPT。

这不仅让企业核心信息脱离了原有管控，也可能为攻击者分析系统架构、寻找安全薄弱点提供线索，进一步引发知识产权泄露、数据合规和法律责任等一系列风险。一次看似正常的 AI 使用，可能由此演变成一场严重的企业安全事件。

如今，AI 正加速进入企业业务，但相应的安全管控并未同步跟上。敏感信息外泄、越权访问、提示词攻击和工具误调用等风险，正成为企业必须面对的现实安全挑战。

当 Agent 能够读取企业知识库、访问业务系统、调用工具并执行操作，一次缺少控制的 AI 调用，带走的可能是敏感数据，越过的可能是用户权限，触发的也可能是真实的业务动作。

更棘手的是，这些请求在系统看来可能完全"正常"：身份认证通过、接口调用成功、模型顺利返回。等企业从日志中发现异常时，数据已经发出，操作也已经完成。

因此，加强 AI 安全治理必须提上日程，而安全管控必须发生在具体调用之前。

---

ZStack Zentrix 以 AI 网关为统一安全入口，将身份验证、权限控制、安全围栏、敏感内容识别、工具管控与审计追溯嵌入调用链路，在数据发出、工具执行和业务操作触发前识别并拦截风险，同时对正常调用全程留痕。

整条安全控制链回答四个问题：

谁在调用？
    ↓
什么数据可以流动？
    ↓
AI 可以执行什么？
    ↓
整个过程能否还原？

01 / IDENTITY & CREDENTIALS

统一身份与凭据：建立可验证的调用起点

收敛访问凭据，控制接入边界

模型和 Agent 只在少数项目中试用时，团队可能直接使用供应商 API Key 或共享服务账号完成接入。随着使用范围扩大，同一组凭据很容易出现在代码、脚本、个人环境和应用配置中。

这直接带来两个问题。

一方面，企业难以准确判断某次调用来自哪个组织、用户或应用；另一方面，人员离岗、项目结束或凭据泄露后，平台很难快速收回权限而不影响其他业务。

Zentrix 通过统一入口管理调用方访问凭证，并结合访问组、IP 白名单、有效期和即时吊销等机制控制接入范围。

在多租户环境中，可以按租户隔离用户、访问凭证和 AI 资源，一个租户的请求不能访问其他租户的模型、Agent、工具与配置。

模型和工具的真实密钥由 Zentrix 统一保管，应用和 Agent 无需直接持有，减少密钥散落和泄露风险。

组织 / 用户 / 应用
        ↓
企业可管理的访问凭证
        ↓
Zentrix 完成身份与访问范围判断
        ↓
按策略使用托管的模型或工具凭据

穿透真实身份，保持责任链完整

对于普通模型调用，统一凭证可以帮助企业识别请求来源。对于 Agent 和 MCP 工具调用，还需要保证真实用户身份不会在多级调用中丢失。

用户通过 Agent 发起任务，Agent 再调用 MCP Server，MCP Server 最后使用服务凭据访问数据库或业务接口。如果末端系统只能看到一个共享服务账号，多个用户的行为就会被折叠成同一个技术身份。

Zentrix 通过短期令牌和加密身份穿透，将真实调用人的身份沿 Agent、MCP 与工具调用链继续传递：

张三发起任务
    ↓
Zentrix 确认身份并形成短期身份凭据
    ↓
Agent 请求调用 MCP 工具
    ↓
工具调用与张三的真实身份关联

短期凭据可以减少长期凭据被复制和滥用的风险；身份穿透则让下游看到的不再只是"某个 Agent"或"某个应用"，而是能够关联到真实调用人。

统一接入和身份穿透并不等于所有调用自动安全，但它们提供了后续判断的起点：企业先知道请求从哪里来、属于哪个租户、代表哪个用户，才可能继续判断数据能否流动、操作能否执行。

AI 安全的第一步，是让每次调用都有可识别的来源，并让真实身份贯穿整条调用链。

02 / CONTENT & DATA SECURITY

内容与数据安全：控制敏感信息流动

确认调用身份之后，还要判断请求中的内容和数据能否继续传递。

员工可能在提示词中粘贴身份证号、银行卡号、病历信息或访问凭据；业务应用也可能把客户资料、内部文档和系统上下文直接拼接到模型请求中。模型输出则可能包含不符合业务要求的内容，或者复述上下文中的敏感字段。

Zentrix 提供输入、输出双向内容安全围栏，对进入模型的请求和模型返回的内容执行策略判断。遇到未知或无法确认的安全状态时，默认按更严格的方式处理，避免安全检测异常后静默放行。

针对个人敏感信息，Zentrix 通过内置规则与本地检测模型识别身份、金融、医疗、税务和凭据等类型的数据，并根据业务场景执行不同动作：

放行　确认符合当前使用条件，正常进入后续调用

审计　允许调用，同时记录命中情况

脱敏　替换敏感字段后再继续传递

阻断　终止本次调用，防止数据继续外发

这些检测能力可以直接在企业内网运行。敏感内容不需要为了识别而再次发送到外部审核服务，在私有化或气隙环境中也可以继续执行内容与 PII 检查。

模型调用安全不仅要回答"谁能使用模型"，还要回答"哪些数据能够沿这条调用链继续流动"。

03 / AGENT & TOOL SECURITY

Agent 与工具安全：把执行权限控制在行动之前

知道谁在调用、哪些数据可以流动，仍然不代表一次工具操作可以直接执行。

当 Agent 进一步访问 MCP 工具和企业系统时，Zentrix 还要回答三个问题：当前用户是否有权执行这项操作，工具是否仍然可信，请求是否会到达不该访问的位置。

单次权限裁决：决定当前操作是否放行

对于 Agent 和 MCP 工具，Zentrix 分别控制"向谁开放"和"本次是否放行"。

在管理端，管理员可以设置 Agent、MCP 工具等能力向哪些部门、职能组和用户开放。当用户实际发起工具调用时，Zentrix 会结合真实调用人、租户边界以及用户与目标资源的关系，对本次操作进行权限裁决。未获得授权的请求在网关层被拒绝，不再继续访问下游工具和业务系统。

管理端：这个工具向哪些部门、职能组和用户开放？
        ↓
运行时：当前用户是否有权对目标资源执行本次操作？
        ↓
允许调用，或在执行前拒绝

例如，一个数据库查询工具可以向研发部门开放，但研发人员真正调用时，仍需判断其是否有权访问目标数据库或相应数据范围。进入可用范围，不等于获得对所有资源的通行权。

Zentrix 不推翻企业已有 IAM 和业务系统权限，而是把真实用户身份与细粒度调用判断带到 Agent 和工具的执行入口，再与企业既有组织、身份和资源关系衔接。

工具漂移复核：持续确认工具可信状态

一次调用拥有正确的身份和权限，所使用的工具本身也可能已经发生变化。

MCP 工具的名称、描述、参数和能力定义可以持续更新，而这些信息还会影响 Agent 如何理解和选择工具。

假设一个已经通过评估的工具，最初只提供"查询订单"能力。更新后，它增加了"取消订单"或"删除记录"的参数，却仍然沿用原有名称和接入地址。如果平台只在首次接入时完成一次审批，后续继续沿用原有信任状态，工具的实际风险边界就可能已经改变。

Zentrix 通过工具漂移复核检查工具定义变化。当安全相关内容发生变化时，原有准入状态需要重新确认；未完成复核的工具不继续放行。

工具首次接入 → 安全评估 → 获得准入
                       ↓
                工具定义发生变化
                       ↓
              触发复核 → 重新放行或拒绝

对于接入外部 MCP Server、频繁更新内部工具，或允许 Agent 操作生产系统的企业，工具安全不能停留在一次性登记。工具持续变化，安全准入也需要持续进行。

入站与出站防护：约束请求的网络边界

一次 AI 调用除了携带身份、内容和数据，还会形成真实的网络请求。

进入网关或 Web 接口的请求可能包含常见攻击载荷；Agent、工具或服务端发起的出站请求，则可能被诱导访问非预期地址、探测内网服务，或者通过重定向到达企业不允许访问的端点。

Zentrix 的 Web 应用防护用于检查进入接口的请求，降低常见 Web 攻击载荷继续进入业务系统的风险；SSRF 出站防护则约束服务端和工具请求可以访问的目标与网络范围，防止其访问非预期内网资源或高风险地址。

外部或业务请求 → Web 安全检查 → Zentrix

Agent / Tool → 出站访问检查 → 外部接口或企业系统

身份正确、数据合规，只是一次安全调用的必要条件。操作是否有权、工具是否可信、目标地址是否安全，同样需要在执行前得到确认。

真正的 AI 执行安全，不只是事后知道 Agent 做了什么，而是在行动发生前判断它能不能做。

04 / FULL-CHAIN AUDIT

全链路审计：还原安全判断与执行结果

调用前控制解决"能不能执行"，审计还要回答"当时为什么这样判断"。

如果记录中只有请求时间和接口状态码，企业仍然难以还原一次模型或 Agent 行为。完整的安全证据需要关联调用链上的关键上下文：

01　请求来自哪个组织、用户或应用，由哪个 Agent 承接

02　调用了哪个模型、MCP Server、工具或企业资源

03　本次调用为什么获得授权，或者因为什么被拒绝

04　命中了哪些内容、PII、Web 或出站安全策略

05　最终是否执行成功，发生了脱敏、阻断或其他处置

06　相关能力和策略在调用前后发生过哪些配置变化

Zentrix 分别记录管理操作和运行时能力调用，再通过调用身份、请求和资源信息进行关联。平台团队可以从一次异常请求回溯真实发起人、权限判断、安全处置和执行结果，也可以从一次工具或策略变更查看相关调用记录。

可追责不是多保存一份日志，而是能够还原一次 AI 调用从身份、判断到执行结果的完整过程。

05 / COMPREHENSIVE COVERAGE

让安全控制覆盖每一次 AI 调用

Zentrix 面对的安全对象，不只是 Agent，也不只是大模型的输入和输出。

它围绕一次 AI 调用依次回答四个问题：谁在调用，什么数据可以流动，AI 可以执行什么，整个过程能否还原。

确认身份：识别调用来源、租户与真实用户
        ↓
检查数据：处理输入、输出与敏感信息
        ↓
控制执行：判断权限、工具状态与网络边界
        ↓
留下证据：记录判断依据、处置动作与执行结果

对于已经接入多个模型，或正在使用 Coding Agent、自研 Agent 和第三方 Agent 的企业，可以从四个问题检查现有安全链路：

01　每次调用能否识别组织、用户、应用和租户，真实调用人能否贯穿到工具侧

02　模型输入输出及敏感数据能否在本地完成检查、脱敏和阻断

03　工具调用能否在执行前完成权限判断、漂移复核和网络边界检查

04　安全事件发生后，能否还原身份、判断、处置与执行结果

如果其中任何一环仍依赖应用单独配置或事后人工追查，可能就需要考虑升级现有的 AI 安全治理方式了。

从接入、治理、成本到安全：Zentrix 的企业 AI 管控闭环

回看整个系列，四篇文章分别回答了企业 AI 规模化落地中的四个关键问题：

总篇　以统一入口收拢模型、Agent 与工具，重新拿回 AI 掌控权

治理篇　统一目录、分发、调度与观测，让 AI 能力成为可运营资源

成本篇　让用量有归属、预算在调用前生效

安全篇　让模型请求和工具执行可控制、可追溯

这四部分，共同形成 Zentrix AI 网关的完整产品逻辑：

从一个入口收拢模型、Agent 与工具调用，以持续运营建立使用秩序，以计量和配额守住成本边界，再以身份、权限、内容、数据和行为控制守住每一次 AI 调用。

当模型请求、Agent 访问和工具执行都能够被识别、判断、控制和追溯，企业才真正把持续增长的 AI 流量纳入可管理、可控制、可审计的生产体系。

如果您的企业正在面对多模型接入、Agent 工具治理、成本失控或安全边界不清等问题，欢迎联系 ZStack，预约 Zentrix 产品交流与演示。我们将结合企业现有 AI 架构，为您提供覆盖接入、治理、成本与安全的一体化 AI 管控解决方案。