系统开始给智能体上锁、安全国标立项：上线前必过的权限清单

一个团队把智能体接进了内部知识库，跑了三个月，一切正常。直到某天早上，有人发现自己去年写在私人目录里的绩效自评，出现在了智能体给另一个同事生成的"团队情况汇总"里。没有人授权它读那个目录，它读得到，是因为运行它的账号有权限。

这类事故的特点是没有攻击、没有漏洞、没有坏人，只有默认信任。而我们正在进入一个默认信任被系统性收回的阶段：系统侧开始给 AI 智能体的全盘访问上锁，治理侧的强制性标准也正式立项。

对个人开发者和小团队来说，这两件事不该当成新闻看，该当成时间表看——你现在部署的智能体，大概率要在半年内面对权限、审计、责任这三道关。与其到时候被动改造，不如现在就按清单过一遍。这篇给的就是这份清单。

收紧的不是功能，是默认信任

先说清楚这次变的到底是什么。

过去智能体拿到权限的方式很简单：它跑在你的用户账号下，于是你账号能读的东西它都能读。文档、桌面、下载目录、聊天记录、浏览器数据，只要那个进程想读，系统默认不拦。这套逻辑在"程序是你自己写的"时代没问题，在"程序会自己决定读什么"的时代就出问题了。

问题在于智能体的行为不是你逐条写死的。你说"帮我整理一下这个项目的资料"，它会自己判断哪些文件相关，然后去读。它判断的边界，和你想的边界，往往不是一回事。而且它读完之后可能把内容放进上下文，上下文会进日志，日志会被同步，链条一拉长就没人说得清数据去哪了。

所以系统侧在做的事是把这个默认开关关掉：应用要访问受保护的位置，必须显式申请、显式授权，并且这个授权可被用户随时收回。治理侧在做的事是把"应该授予什么"从各家自觉变成统一要求。

对个人来说，直接影响有三条。

• 依赖全盘访问的自动化流程会需要重新授权，有些可能直接跑不通。
• 之前"能用就行"的权限配置，现在需要能说清楚为什么需要。
• 如果你的智能体服务是卖给别人的，权限说明会成为交付物的一部分。

为什么治理会在这个时间点落地

很多人会觉得标准这种东西离自己很远。但这一轮治理有个明显特征：它针对的是"智能体"这个形态，而不是"模型"这个形态。

模型输出一段文字，责任相对清楚——内容合规、版权、真实性。智能体不一样，它会动手：调接口、写文件、发消息、下单、改数据。一旦它会动手，责任链条上就多了几个新问题。

谁授权的：这个动作是用户明确要求的，还是智能体自己推断的？

边界在哪：它能动哪些系统、动到什么程度、超过什么金额或影响面需要人来确认？

怎么追溯：事后能不能还原它做了什么、依据是什么、当时的数据状态是什么？

这三个问题，靠模型能力提升是解决不了的，只能靠流程和规范。所以标准的立项本质上是把行业里已经出现的零散做法规范化。对你来说，越早按这套规范做，后面改造成本越低——因为规范里的要求，基本都是你现在就应该做但可能没做的事。

权限分级：三类数据，三种待遇

先做分类，再谈配置。把你的数据按敏感程度分成三类，每一类对应不同的处理规则。

第一类 · 可公开数据

官网内容、已发布文章、公开文档、产品说明。智能体可以自由读取、自由引用、可以进外部模型的上下文。这一类的处理原则只有一个：标注来源，方便溯源。

第二类 · 内部数据

未发布的选题、内部流程、客户名单、经营数据、代码仓库。这一类可以读，但要看去哪。如果你用的是外部 API，这类数据进上下文之前要过一遍脱敏；如果涉及个人信息，还要考虑告知义务。实践中一个简单规则：内部数据只在本地模型或企业协议下的服务里处理。

第三类 · 敏感数据

账号凭证、身份证件、支付信息、医疗与未成年人相关信息、劳动合同与薪酬。默认不进智能体。确有必要时，走单独通道：单独的最小权限账号、单独的审计日志、处理后的结果脱敏再进入主流程。

分类不需要多复杂，一张三列表格或者一个文档就够了。但必须写下来，因为它是后面所有配置决策的依据。没有分类，你每一次授权都是在凭感觉拍板。

最小权限怎么落地：五个具体动作

分类做完，接下来是配置。最小权限说起来简单，落地靠的是五个具体动作。

动作一 · 独立账号

不要让智能体跑在你的主账号下。给它一个独立的系统账号，这个账号只能访问它需要的一到两个目录。多花十分钟建账号，能省掉后面无数次"它为什么能读到这个"的排查。

动作二 · 目录白名单

不要用"排除法"（禁止访问某些目录），要用"白名单法"（只允许访问某些目录）。排除法永远会有漏网的目录，而且新目录一出现就自动获得了访问权限。

动作三 · 只读优先

默认给只读权限。需要写入时，单独申请写权限并限定到具体目录。绝大多数自动化流程其实只需要读，写入往往是顺手加上的。

动作四 · 凭证隔离

API Key、数据库密码、私钥这类东西，不要放在智能体能读到的目录里，也不要写进它的配置文件明文。用环境变量或密钥管理服务，并且给智能体用的 Key 单独限权、单独配额、可随时吊销。

动作五 · 高危动作加确认闸门

凡是涉及发消息给外部、转账下单、删除数据、修改权限、对外发布的动作，都必须在智能体和执行之间插一道确认。可以是人工确认，也可以是规则引擎（金额低于某阈值自动放行，超过则转人工）。这一道闸门是整个安全体系里最值钱的部分。

审计留痕：记录什么才有用

很多人的日志只记录了"调用成功/失败"，这在事后追溯时基本没用。有用的日志要能回答四个问题。

它做了什么：调用了哪个工具、传了什么参数、改了哪个文件、发了什么消息。参数要记，尤其是涉及外部动作时。

它依据什么做的：当时读了哪些文件、上下文里有哪些关键数据。这一条是复现的前提——没有它，你连"它为什么会这么决定"都还原不出来。

谁触发的：是用户直接指令、定时任务、还是它自己触发的后续动作。自动触发的动作风险更高，要单独标记。

结果如何：成功、失败、被闸门拦截。被拦截的记录特别有价值，它告诉你智能体在试图做什么你没预料到的事。

日志保存多久取决于业务，但建议至少留 90 天。很多问题不是当天发现的，追溯窗口太短等于没有追溯能力。

另外一个容易被忽略的点：日志本身也是敏感数据。它里面可能有内部内容、用户信息、甚至凭证片段。日志要单独设权限、单独加密，不能因为"只是日志"就放在谁都能读的地方。

责任划分：出事了谁担

这一块最容易被跳过，但它是合规检查里必问的。

部署者责任：你选择了这个模型、配置了这些权限、决定了它在什么场景下运行。模型出错导致损失，部署者是第一责任人，这一点不会因为"是 AI 自己决定的"而转移。

使用者责任：下达指令的人，对指令本身的合法性负责。用智能体批量抓取竞品数据，抓取行为本身如果违规，责任在下达指令的人。

提供者责任：模型与工具提供方对其服务本身负责。这一块通常在服务条款里界定，你要做的是把条款存档，出事时知道该找谁、条款怎么写的。

实操上，建议给每个智能体写一份一页纸的"运行说明"：干什么、能访问什么、不能干什么、谁负责、出问题联系谁、怎么停掉它。这份东西平时没人看，出事时是唯一能快速止损的依据。

常见误区

"我只是自己用，不用管这些"

个人使用确实没人查你，但权限收紧是系统层面的，你的自动化流程该跑不通还是跑不通。而且个人使用最容易出的事故是把私密内容误发到外部服务——这类事故对个人同样有实质伤害。

"收紧权限太麻烦，先全开着"

全开权限的真正代价不是安全风险，是你永远不知道该关哪些。因为没有分类、没有日志，等到要收紧时只能重新做一遍。

"日志记了就行"

记了不看的日志等于没有。至少每周扫一次高危动作记录和被拦截记录，看它在尝试什么你没预料到的事。

"用大厂服务就不用管"

大厂服务解决传输与存储安全，解决不了"你的智能体被授权读了什么"。权限配置的责任始终在部署者这边。

上线前检查清单

把上面的内容压缩成一份可以直接照着勾的清单，建议每个智能体上线前走一遍。

• 是否运行在独立账号下，而不是个人主账号。
• 可访问目录是否为白名单，白名单里是否只有它真正需要的目录。
• 默认权限是否为只读，写权限是否单独申请并限定目录。
• 凭证是否不在其可读范围内，所用 Key 是否可单独吊销。
• 是否明确划分了可公开、内部、敏感三类数据，敏感数据是否默认排除。
• 外部动作（发消息、下单、删除、对外发布）是否都有确认闸门。
• 日志是否记录了动作、依据、触发者、结果四类信息。
• 日志本身的访问权限是否与智能体隔离。
• 是否有一页纸的运行说明，包含责任人、停机方式。
• 是否做过一次"故意让它越界"的测试，确认拦截真的生效。

最后一条最容易被省略，但它才是真正验证前九条的方法。清单勾完了不等于安全，测过才算。

现在就该做的三件事

第一，今天就把你正在跑的智能体从主账号挪到独立账号。这件事半小时能做完，是所有后续改造的前提。

第二，做一次数据分类，把敏感数据从可访问范围里显式排除掉。不要等系统强制你做，那时候你是被动的。

第三，给外部动作加确认闸门。哪怕只是"发消息前打印出来等我回车"这种最朴素的实现，也比直接放行安全一个数量级。

智能体能力还在快速涨，但权限治理是它能不能走进真实业务的地基。地基现在不打，等规模起来了再补，代价是现在的一百倍。