企业官网建设流程全解析

1. 从一次内部审计说起：AI Agent 的治理缺口到底长什么样

去年下半年，我参与了一家做跨境电商 SaaS 的公司的内部安全审计。他们的技术团队很年轻，动作也快，半年前就开始把 AI Agent 接进客服工单系统、库存预警系统和一部分财务对账流程里。表面上看，效率提升非常明显：客服响应时间从平均 4 分钟压到 40 秒，库存异常发现从“天级”变成“分钟级”。但审计做到第三天，我们发现了一个让人后背发凉的问题。

有一个负责“自动整理供应商邮件并生成采购建议”的 Agent，它的运行身份是一个长期有效的服务账号，权限范围覆盖了采购数据库的读写、对象存储的读取，以及内部 IM 的消息发送。更关键的是，这个账号的凭证被硬编码在 Agent 的配置文件里，而这份配置文件又被同步到了一个内部 Wiki 的附件中。也就是说，任何能访问那个 Wiki 页面的人，理论上都能拿到这个 Agent 的身份，然后以它的名义去读采购数据、发消息、甚至修改库存记录。

这不是什么高深的零日漏洞，也不是什么复杂的供应链攻击。它就是一个典型的治理缺口：我们给 AI Agent 赋予了“非人类身份”，却没有像对待人类员工那样去管理它的权限、生命周期和行为边界。标题里说的“AI Agent 的治理缺口，正在成为企业下一个主要泄露来源”，我在那次审计之后，是真真切切地信了。

这篇文章，我想从一线实操的角度，把这件事拆开来讲。AI Agent不是简单的“自动化脚本”，它是一个有推理能力、能调用工具、能自主决策的运行时实体。治理缺口指的是企业在身份管理、权限控制、运行时监控、审计追溯这几个环节上，对 Agent 的覆盖远远落后于对人类用户的覆盖。企业数据泄露则是这个缺口被利用后的直接后果。而运行时控制和非人类身份，是堵住这个缺口的两把关键钥匙。

如果你正在搭建 AI Agent，或者你的团队已经把 Agent 接进了生产环境，那这篇内容就是写给你的。不管你是用 Coze 这类低代码平台拖拽出来的智能体，还是用 FastAPI + LangChain + LangGraph 手搓的复杂工作流，治理这件事，越早做越省心。

2. 为什么 AI Agent 的泄露风险比传统脚本高一个量级

2.1 从“固定逻辑”到“自主决策”带来的攻击面膨胀

传统的自动化脚本，比如一个定时跑的数据同步任务，它的行为是确定的：读 A 表，写 B 表，遇到异常发邮件。你能清楚地画出它的数据流图，也能很容易地限制它的权限——它只需要 A 表的读权限和 B 表的写权限，多一个都不给。

AI Agent 完全不是这个逻辑。一个基于 LangGraph 搭建的采购助手 Agent，它的工作流程可能是：先读邮件，然后根据邮件内容决定要不要查库存，查完库存可能去查供应商历史价格，接着生成建议，最后可能调用 IM 发消息给采购负责人。这个过程中，它调用的工具是动态的，访问的数据范围是动态的，甚至它生成的下一步动作也是动态的。

这就带来一个根本性的问题：你很难用传统的“最小权限原则”去静态地定义一个 Agent 的权限边界。因为你不知道它下一步会调用哪个工具、访问哪张表。很多团队为了“让它能跑起来”，干脆给了一个超级权限的账号，心想“反正它是内部用的”。这就是治理缺口的起点。

我见过一个更极端的例子：某公司的运维 Agent 被赋予了云平台的 AdministratorAccess 策略，理由是“方便它自动扩容和排查故障”。结果这个 Agent 的提示词里有一条“如果遇到无法解决的问题，可以尝试重启相关服务”。有一次它把一个核心数据库的只读副本给重启了，导致报表系统中断了 40 分钟。这还只是可用性问题，如果它的凭证被泄露，攻击者拿到的就是整个云平台的钥匙。

2.2 非人类身份：被遗忘的“影子员工”

在企业身份管理体系里，人类员工有入职、转岗、离职的完整生命周期。员工离职当天，HR 系统会触发账号禁用，IT 部门会回收权限。但 AI Agent 呢？很多团队搭完 Agent 之后，创建了一个服务账号，配置好权限，然后就再也没有人管过它。

这个账号变成了一个非人类身份，它没有“离职”的概念，也没有人定期 review 它的权限。更麻烦的是，Agent 的代码可能迭代了好几版，但它的运行身份还是最初那个“临时测试用”的账号。我见过一个 Agent 的账号权限里，还保留着对一个已经下线的测试数据库的访问权，而那个数据库的备份里，恰好有早期用户的手机号和地址。

这就是非人类身份管理的核心难点：数量多、创建随意、生命周期不清晰、权限蔓延严重。人类员工的账号有 HR 系统兜底，Agent 的账号往往只存在于某个配置文件或环境变量里，连资产清单都没有。你问一个 CTO“你们公司有多少个 AI Agent 在跑”，他可能要想半天，然后说“大概十几个吧”，实际上可能有三四十个，分布在不同的项目、不同的云账号、不同的代码仓库里。

2.3 运行时控制缺失：Agent 的“黑盒执行”

传统应用的运行时行为，你可以通过日志、APM、网络流量分析来监控。但 AI Agent 的运行时，尤其是基于大模型的 Agent，它的决策过程是一个黑盒。你看到的是输入和输出，中间它调用了哪些工具、访问了哪些数据、为什么做出这个决策，往往只有很粗粒度的日志。

这就导致一个严重的问题：当 Agent 被诱导或出现幻觉时，你很难在运行时拦截它。比如一个客服 Agent，正常情况下它只应该查询订单状态和物流信息。但如果用户输入了一段精心构造的提示词，诱导它去查询其他用户的订单，而它的工具权限又没有做行级隔离，那它可能真的会把别人的订单信息返回出来。这种攻击在传统应用里很难发生，因为传统应用的查询逻辑是写死的，而 Agent 的查询逻辑是“生成”的。

运行时控制要解决的，就是在这个黑盒执行的过程中，插入可观测、可拦截、可审计的检查点。比如：Agent 调用工具之前，先经过一个策略引擎，判断这次调用是否符合当前会话的上下文和用户权限；Agent 返回结果之前，先经过一个内容过滤器，判断输出是否包含敏感信息。这些机制在传统安全架构里都有成熟方案，但很多团队在搭 Agent 的时候，完全跳过了这一步。

3. 拆解治理缺口的四个核心维度

3.1 身份维度：Agent 到底该以谁的名义运行

这是最基础也最容易做错的一环。很多团队在创建 Agent 时，直接复用了开发者的个人账号，或者创建了一个“万能服务账号”。这两种做法都有问题。

复用个人账号的问题是：Agent 的行为会和个人行为混在一起，审计的时候根本分不清哪些操作是人做的，哪些是 Agent 做的。而且个人账号通常权限很大，一旦 Agent 被攻破，攻击者就拿到了这个人的所有权限。更麻烦的是，如果这个人离职了，账号被禁用，Agent 也跟着挂了。

万能服务账号的问题是：权限过大，且无法区分不同 Agent 的行为。你有一个客服 Agent 和一个财务 Agent，它们共用同一个账号，那财务 Agent 出了事，你连是哪个 Agent 干的都查不出来。

比较合理的做法是：为每个 Agent 创建一个独立的非人类身份，并且这个身份只拥有完成其职责所需的最小权限。在云平台上，这通常对应一个独立的 IAM Role 或 Service Account；在应用层，这对应一个独立的 API Key 或 Token。这个身份要有明确的命名规范，比如agent-customer-service-prod、agent-inventory-alert-staging，让人一眼就能看出它是哪个 Agent、在哪个环境、干什么用的。

注意：不要用“共享服务账号 + 日志里记 Agent 名字”这种方式来偷懒。日志是可以伪造的，但身份凭证的权限是硬约束。身份隔离是治理的第一道防线，也是最有效的一道。

3.2 权限维度：动态权限与静态权限的平衡

前面说了，Agent 的权限很难静态定义，因为它的行为是动态的。但这不意味着我们就只能给超级权限。这里有几个实操中比较有效的策略。

第一，按工具粒度授权，而不是按数据源粒度授权。不要给 Agent“数据库读写权限”，而是给它“调用 query_order_status 工具的权限”。这个工具内部再去用受限的数据库账号执行查询。这样 Agent 能做的事情就被限制在工具定义的范围内，而不是整个数据库。

第二，引入运行时权限申请机制。对于确实需要动态权限的场景，可以让 Agent 在调用某个敏感工具时，先向一个策略服务申请临时凭证。策略服务根据当前会话的用户身份、Agent 的历史行为、请求的上下文，决定是否发放以及发放多久。这有点像人类员工需要临时提权时走审批流程，只不过自动化了。

第三，设置权限的“过期时间”。很多团队给 Agent 配的凭证是永久有效的，这是大忌。应该像人类员工的密码一样，定期轮换。对于临时任务型的 Agent，任务结束后凭证就应该失效。对于长期运行的 Agent，至少每 90 天轮换一次，并且轮换过程要自动化，避免因为忘记轮换导致服务中断。

3.3 运行时维度：在 Agent 的“思考”和“行动”之间插入检查点

运行时控制的核心思路是：不要相信 Agent 的每一次决策，而是在它执行之前做一次独立判断。这个判断不依赖于大模型，而是依赖于确定性的策略规则。

具体来说，可以在 Agent 的架构里插入几个拦截层。第一个拦截层在“工具调用”之前：Agent 决定要调用某个工具时，先把调用请求发给策略引擎，策略引擎检查这个工具是否在当前会话的允许列表里、参数是否包含敏感字段、调用频率是否异常。第二个拦截层在“结果返回”之前：工具执行完返回结果后，先经过一个过滤器，检查结果里是否包含 PII（个人身份信息）、密钥、内部 IP 等敏感内容。第三个拦截层在“输出生成”之前：Agent 准备把最终回复发给用户时，再经过一次内容安全检查和合规检查。

这些拦截层不需要很复杂，初期可以用简单的规则引擎实现。比如用 Open Policy Agent 写几条策略：禁止 Agent 在非工作时间调用财务工具；禁止 Agent 查询超过 100 条用户记录；禁止 Agent 的输出中包含身份证号格式的字符串。这些规则跑在 Agent 的调用链路上，不依赖大模型的判断，所以是确定性的、可测试的、可审计的。

提示：运行时控制的策略要“默认拒绝，显式允许”。也就是说，如果一个工具调用没有匹配到任何允许规则，就应该被拦截，而不是放行。很多团队反过来做，默认放行，只拦截已知的坏行为，这在安全上是不可接受的。

3.4 审计维度：让 Agent 的每一步都可追溯

审计的目的不只是“事后追责”，更重要的是“事中发现”和“事后改进”。一个完善的 Agent 审计体系，应该能回答这几个问题：这个 Agent 在什么时间、以什么身份、调用了什么工具、传了什么参数、返回了什么结果、最终输出了什么内容、这个过程中有没有触发策略拦截。

要实现这个，需要在 Agent 的调用链路上做全链路追踪。如果用的是 LangChain 或 LangGraph，可以利用它们的 callback 机制，把每一步的输入输出都记录下来。如果用的是 Coze 这类平台，要确认平台是否提供了足够的审计日志，以及日志能否导出到企业自己的 SIEM 系统里。

审计日志的存储也有讲究。不要和 Agent 的业务日志混在一起，应该单独存到一个只追加、不可篡改的存储里。日志里要包含足够的上下文，比如会话 ID、用户 ID、Agent ID、工具名称、参数摘要、结果摘要、策略决策结果。对于敏感参数，比如密码或 Token，要做脱敏处理，但脱敏规则本身也要被审计。

我个人的经验是，审计日志的粒度要“足够细，但不至于爆炸”。如果每一步的完整输入输出都存，数据量会非常大，而且可能把敏感信息也存进去。比较好的做法是：存参数的结构化摘要（比如“查询了订单表，条件为用户 ID 前缀为 123”），而不是原始参数值；存结果的哈希和长度，而不是完整结果。这样既能追溯，又不会造成二次泄露。

4. 从零搭建一套 Agent 治理框架的实操路径

4.1 第一步：盘点资产，建立 Agent 清单

在谈任何治理措施之前，你得先知道自己在治理什么。我建议用一个简单的表格来盘点，字段包括：Agent 名称、负责人、运行环境、使用的身份凭证、拥有的权限范围、调用的工具列表、数据流向、是否处理敏感数据、最后更新时间。

这个盘点过程本身就会暴露很多问题。你会发现有些 Agent 没有负责人，有些 Agent 的权限比它实际需要的多得多，有些 Agent 还在用已经离职员工的账号。盘点完之后，给每个 Agent 打一个风险等级：高风险的（处理财务、用户 PII、核心业务数据的）优先治理，低风险的可以稍后。

4.2 第二步：身份隔离与凭证管理

给每个 Agent 创建独立的非人类身份。如果用的是云平台，优先使用云原生的 IAM 角色，而不是长期 Access Key。如果必须用 Access Key，那就把它存到密钥管理服务里，比如 AWS Secrets Manager、Azure Key Vault 或者开源的 Vault。Agent 在运行时动态获取凭证，而不是从配置文件里读。

凭证的轮换要自动化。可以写一个定时任务，每 90 天生成新的凭证，更新到密钥管理服务，然后通知 Agent 重新加载。对于 Kubernetes 环境，可以用 Service Account Token Volume Projection，让 Token 自动轮换，Agent 无感知。

注意：不要把凭证写在代码里、配置文件里、环境变量里（尤其是 CI/CD 的环境变量，容易被日志打印出来）。如果实在要用环境变量，至少确保它不会被 Agent 的输出带出来。

4.3 第三步：工具层的权限封装

不要让 Agent 直接访问数据库或 API，而是在中间加一层工具层。工具层负责鉴权、参数校验、结果过滤。比如，Agent 想查订单，它调用的是query_order(order_id, user_id)这个工具，工具内部会检查user_id是否和当前会话的用户匹配，只返回该用户有权查看的字段。

工具层的另一个好处是，你可以在这里做速率限制和配额管理。比如限制每个 Agent 每分钟最多调用 60 次外部 API，防止它因为幻觉陷入无限循环，把下游服务打挂。我见过一个 Agent 因为提示词里有一句“如果查询失败，重试直到成功”，结果下游服务返回 500 的时候，它疯狂重试，几分钟内打出了上万次请求。工具层的速率限制可以兜住这种问题。

4.4 第四步：运行时策略引擎的接入

策略引擎可以选 OPA（Open Policy Agent）或者 Cedar 这类成熟的策略语言。策略的编写要围绕几个核心问题：谁（哪个 Agent、哪个用户）在什么条件下（时间、地点、会话上下文）可以对什么资源（工具、数据）执行什么操作（读、写、调用）。

初期不要追求大而全，先覆盖最高风险的场景。比如：禁止 Agent 在非工作时间调用支付相关工具；禁止 Agent 查询超过 100 条用户记录；禁止 Agent 的输出中包含手机号、身份证号、银行卡号。这些策略写起来简单，但能挡住大部分低级泄露。

策略引擎的决策要记录到审计日志里，包括允许和拒绝的决策。这样你才能知道哪些策略经常被触发，哪些策略可能过于严格影响了正常业务，哪些策略从来没有触发过可能需要调整。

4.5 第五步：持续监控与迭代

治理不是一次性的项目，而是一个持续的过程。你需要定期 review Agent 的权限使用情况，看看有没有权限蔓延；定期 review 策略的触发情况，看看有没有新的风险模式；定期 review 审计日志，看看有没有异常行为。

可以设置一些告警规则：比如某个 Agent 突然开始调用它从未调用过的工具；某个 Agent 的调用频率突然飙升；某个 Agent 的输出中触发了敏感信息过滤器。这些告警不需要很复杂，初期用简单的阈值和规则就能覆盖大部分场景。

5. 常见问题与排查技巧实录

5.1 Agent 频繁触发权限拒绝，业务方抱怨怎么办

这是治理初期最常见的问题。业务方会觉得“以前能跑的，现在跑不了了”。我的经验是，先别急着放宽策略，而是先搞清楚为什么会被拒绝。通常有三种情况：一是策略确实写得太严，把正常行为也拦了；二是 Agent 的权限配置有问题，它需要的权限没有被正确授予；三是 Agent 的行为本身就有问题，它试图访问不该访问的数据。

对于第一种，调整策略的粒度，比如把“禁止查询用户表”改成“禁止查询用户表的敏感字段”。对于第二种，走正式的权限申请流程，让业务方确认这个权限是必要的，然后记录在案。对于第三种，这是一个治理的胜利，你应该把这个案例拿出来，告诉业务方“看，这就是我们拦住的风险”。

5.2 如何平衡安全与 Agent 的“智能”

很多人担心，加了太多限制，Agent 就不“智能”了。我的看法是，安全约束和智能程度并不矛盾，它们解决的是不同层面的问题。智能解决的是“能不能做对”，安全解决的是“做错了会不会出事”。一个 Agent 可以很智能地规划任务，但它的执行必须受到约束。

实际操作中，可以把约束放在“执行层”而不是“规划层”。让 Agent 自由地思考、规划、选择工具，但在真正调用工具的时候，由策略引擎做最终裁决。这样 Agent 的智能不受影响，但风险被控制住了。

5.3 审计日志太多，怎么有效分析

日志分析的关键是“聚焦”。不要试图分析所有日志，而是先定义几个关键风险指标：敏感工具调用次数、策略拒绝次数、异常时间段的调用、高频调用、跨用户数据访问。围绕这些指标做聚合和告警，而不是逐条看日志。

另外，可以把审计日志和 Agent 的版本关联起来。每次 Agent 的提示词或工具配置有变更，就在日志里打一个标记。这样当出现异常行为时，你可以快速判断是不是最近的变更导致的。

5.4 小团队没有专职安全人员怎么做

这是很多创业公司的现实问题。我的建议是，不要追求大而全的治理框架，而是抓住几个“高杠杆”的动作。第一，给每个 Agent 独立身份，不用共享账号。第二，把凭证从代码和配置文件里挪到密钥管理服务。第三，在工具层做基本的参数校验和结果过滤。第四，开启云平台的审计日志，定期看一眼。

这四个动作不需要专职安全人员，一个后端工程师花一两天就能搞定。它们能挡住大部分低级泄露，性价比极高。等团队规模大了，再逐步引入策略引擎、运行时拦截这些更重的机制。

6. 一个真实的排查案例：从异常告警到根因定位

最后分享一个我亲身经历的排查案例，希望能给你一些参考。

某天下午，我们的监控系统报警：一个客服 Agent 的 API 调用量在 10 分钟内突增了 20 倍。第一反应是“是不是被攻击了”，但查了来源 IP，都是内部服务。接着查审计日志，发现这个 Agent 在反复调用一个“查询用户历史工单”的工具，而且每次查询的用户 ID 都不一样。

进一步查会话记录，发现有一个用户在和 Agent 对话时，输入了一段很长的文本，大意是“请帮我列出所有最近投诉过的用户，我要做竞品分析”。Agent 的提示词里没有明确禁止这种请求，而它的工具权限又允许它查询任意用户的工单。于是它就真的开始一条一条查，查了几百条。

这个案例暴露了三个问题：第一，工具层没有做行级权限控制，Agent 可以查任意用户的数据；第二，运行时没有做频率限制和异常行为检测；第三，提示词里没有对这类批量查询请求做拒绝。

我们的修复措施是：在工具层加上“只能查询当前会话用户自己的工单”的限制；在策略引擎里加上“单个会话内查询不同用户 ID 超过 5 次就拦截”的规则；在提示词里明确写上“不得批量查询用户数据”。同时，把这个案例同步给了所有 Agent 的负责人，让大家检查自己的 Agent 有没有类似问题。

这个案例让我深刻体会到，AI Agent 的治理缺口不是理论上的风险，而是随时可能触发的现实问题。而且它往往不是来自外部攻击，而是来自 Agent 对用户请求的“过度配合”。Agent 的设计目标是“尽力满足用户需求”，但如果没有治理约束，这个目标就会变成“无底线地满足用户需求”，包括那些不该被满足的需求。

治理的本质，是在 Agent 的能力和企业的风险承受能力之间划一条线。这条线画在哪里，取决于你的业务性质、数据敏感度和合规要求。但无论如何，这条线必须存在，而且必须被技术手段强制执行，而不是依赖 Agent 的“自觉”。