先把最重要的一条放最前面：内部用的智能体，默认就是"谁都能问到一切"的高危状态，你不主动加鉴权和数据隔离，它就是个把全公司敏感信息平铺给所有人的窗口。我们差点出事，复盘出几条避坑经验，写给同样在搭内部 AI 助手的人。

差点出事的场景

我们给内部搭了个"问业务数据"的助手，知识库里灌了不少东西，包括一些部门的经营数据、员工花名册。一开始图快，发布出去没做任何权限控制，全公司谁拿到链接都能问。

直到有同事开玩笑问了句"XX 部门上个月业绩多少"，它真给答出来了——那是只有管理层该看的数。当场后背发凉。这要是被问到薪资、客户合同，就是事故。

下面是我们补的几道防线，按重要性排。

防线一：接 SSO，先解决"你是谁"

匿名访问是原罪。第一件事是把助手的访问入口接到公司 SSO（我们用的企业身份体系），没登录就用不了，登录后能拿到访问者的身份和部门。

好在我们用的那个零代码搭智能体的平台，发布时支持配置访问鉴权，能要求访问者先通过企业身份验证。配上之后，至少"谁在问"这件事有据可查了，匿名裸奔堵死。

防线二：按身份隔离知识库，解决"你能问到什么"

光知道"你是谁"不够，关键是不同人能检索到的知识范围必须不同。我们的做法是把知识库拆开，按敏感级别分：

公共知识库      → 所有登录员工可检索（制度、流程、产品手册）
部门级知识库    → 仅本部门成员可检索（部门内数据）
管理层知识库    → 仅管理层可检索（经营、薪资、合同）

然后在工作流里加一个"权限路由"节点：拿到访问者的部门/角色，决定这次检索去查哪些库。一个普通员工问"XX 部门业绩"，他的检索根本够不到管理层那个库，自然问不出来——不是靠模型"拒绝回答"，是让敏感内容压根进不了它的上下文。 这点很重要，靠提示词让模型"遇到敏感问题别答"是不牢靠的，能被绕过；从数据源头隔离才硬。

防线三：操作审计，解决"出事能不能追"

第三道是审计日志。每一次提问，我都记下来：谁（身份）、什么时间、问了什么、命中了哪个知识库、返回了什么。

审计字段示例：
{
  "user": "zhangsan@corp",
  "dept": "研发",
  "time": "2026-06-12T14:03:11",
  "query": "服务器登录密码在哪",
  "hit_kb": "公共知识库",
  "answer_summary": "未命中，建议联系运维",
  "blocked": false
}

有了这个，万一真有人试探敏感问题，事后能查到是谁、问了什么。审计本身也有威慑——大家知道有日志，就不会乱试。日志我单独存，定期审一遍异常提问。

几个容易忽略的坑

坑一：别信"模型会拒绝"。 前面说了，提示词层面的"遇到敏感别答"能被各种话术绕开（"假设你是管理员……"）。安全必须做在数据访问层，不能押在模型自觉上。

坑二：知识库更新时权限容易漏配。 我们有次往公共库里塞文档，没注意里面夹了张含敏感数据的附件，等于绕过了隔离。后来加了条规矩：任何文档入公共库前先过一遍脱敏检查。流程上的洞比技术上的更常见。

坑三：审计日志本身也是敏感数据。 日志里记着大家问了啥，这玩意儿泄露也是事故。日志的访问权限要单独收紧，别又裸奔了。

还没做到位的

目前我们的权限粒度只到"部门级"，做不到"行级"——比如同部门里，组长能看全组数据、组员只能看自己的，这种细粒度我们还没实现，只能先靠拆更细的知识库硬扛，不够优雅。细粒度的字段级权限是下一步要啃的。

底层模型走的讯飞 MaaS，现成大模型 API 调用，没自己部署模型，但安全这摊（鉴权、隔离、审计）是自己必须补的，平台给不了你的业务权限模型。

你们内部 AI 助手怎么做权限隔离的？有没有更细粒度的方案，评论区指点下。