高校智能体如何做权限控制？

定义：高校智能体权限控制到底在控制什么

在高校语境里，智能体权限控制是一套在对话发生时仍然生效的授权判断：系统先识别当前用户是谁、属于哪个最小角色，再决定能否进入该场景、检索哪一知识空间、调用哪一工具，以及该动作是否必须等人确认。它管提问、检索、生成和执行，而不是只管门户上能看见哪些按钮。

权限对象至少要拆成四层并同时成立。身份回答“是谁”，应来自统一身份认证。角色回答“以什么最小身份办事”，例如访客、学生、教师、院系管理员、校级业务岗，而不是把教职工并成一个内部用户。数据分级回答知识和字段属于哪一密级、哪一院系范围，公开制度、内部办事、学籍成绩不能进同一检索池。工具授权回答这次调用是只读还是会改库、发文、推送；查询可按授权拉取，写操作必须二次确认或回到原系统。四层缺一层，模型仍可能用自然语言把越权请求补全。

业务系统可以按岗位隐藏功能，但智能体一旦被允许检索或调接口，用户不必找到那个菜单，只要把目标写成一句话。控制点必须前移到检索和调用之前。建设路径见高校智能体怎么建设，密级落到数据对象见高校数据如何分类分级，日志边界见安全与合规边界。

它不是什么

• 它不是做完统一登录就结束。登录只解决实名，不解决可见知识和可写接口。
• 它不是把“请遵守权限”写进提示词就完成治理。提示词可被改写、覆盖或诱导忽略。
• 它不是院系各自给助手发一套管理员口令，事后无法回收、无法对账。
• 它不是允许模型直接改成绩、改学籍、对外发文或代替主管部门签字。
• 它不是一次上线后不用复核离职账号、高权限配置和过期知识空间。

权限控制也不是把所有问题都转给人工。授权内的只读查询应能稳定完成并引用依据；授权外的知识不得进入上下文；会改变正式记录或对外口径的动作必须确认。校级智能体与数据治理平台可以支撑注册、知识空间、工具编排和审计检索，但不能代替业务部门决定谁能看哪类材料，也不能自动获得写接口。

为什么高校不能把权限留给页面

学校推进智能体时，真正反复出事的往往不是“模型会不会答”，而是四类同时出现的授权错位。

第一，入口是对话，越权不再需要找菜单。同一句话可以同时触发检索和接口调用。如果只在门户隐藏入口，提问、粘贴工号、上传名单仍可能把高密级片段送进上下文。页面权限和智能体权限必须分开设计，后者要在检索器和工具网关拦截。

第二，知识和工具被绑在同一条无边界通道上。培养方案、办事指南可以开放检索；学籍、成绩、资助和人事材料不能按同一提示词处理。查询课表与提交异动也不是同一类动作。方案若只写接入模型和教务接口，却不写角色、密级和是否允许写回，上线后仍会出现越级调用。

第三，责任悬空。信息化可以负责统一身份、网关和日志，但不能代替教务解释成绩能否被助手读出，不能代替学工判断资助咨询是否可自动答。没有场景主责人和确认岗，拒答会变成客服话术，出事后找不到签字人。

第四，验收口径无法复测。招标书若只写“支持权限管理”，既不能抽测低权限账号，也容易把可替换方案排除在外。学校需要可复跑的用例：低权限读不出高密级、无确认写操作不生效、越权有拒答记录、管理员能按人和时间检索日志。

常见偏差包括：只复制菜单权限却允许跨空间召回；师生共用未分级向量库；演示写接口试运行后不收回。纠正这些偏差不需要先换更大模型，需要先补身份映射、分级标签、调用前授权和人工确认。对照摘要见高校AI智库 · 智能体权限专题。

五步控制：从统一身份到定期复核

控制顺序是一条可重复链路。每一步都有判断对象和失败处理，下一步不得跳过上一步的授权结果。模型生成出现在授权之后，而不是先生成再删句子。

第一步：接入统一身份，映射最小角色

智能体账号应来自学校统一身份，并随人事、学籍状态变更。不要为助手单独发放无法与组织机构同步的本地口令。映射时按办事所需的最小角色，而不是按“编内人员”一刀切。建议至少区分访客、学生、教师、院系教辅、校级业务岗和平台管理员，并允许一个人在不同场景持有不同角色：教师在课程助手里是课程责任人，在人事助手里只是普通查询者。

最小角色要写清：可进入哪些场景、默认可见哪一级知识、默认有无写工具。访客只问公开信息；学生可问本人办事和公开培养方案，不能问他人成绩；教师可问本课程、本学院授权材料，不能默认打开全校学籍；校级业务岗按处室授权。角色变更和离校都应有失效时间。

第二步：给知识和工具打密级与院系范围，检索调用前先授权

每条入库知识和每个工具都要带密级、归属部门和允许角色，不能只写文件名。密级应能和学校数据分类分级对齐，公开、内部、敏感、机密或学校等效口径均可，但必须能被检索器识别。院系范围用于切断“同校即可见”：文学院教师工作区不得被其他学院学生检索，课题组过程稿不得进入校级办事库。分级方法见高校数据如何分类分级。

授权判断发生在检索和调用之前。正确顺序是：识别身份与角色，过滤可访问空间和工具，只在允许集合内检索或调用，再生成回答。不要先全库召回再让模型“注意权限”，也不要先取完整记录再在页面遮挡。后一种做法会把高密级原文写入日志和上下文，即使最终句子被改写，泄露已经发生。

第三步：查询可按授权拉取，写操作必须二次确认

只读查询可以自动化，前提是字段已被授权且结果可回溯到源系统。课表、办事材料清单、已公开制度条文，适合按角色拉取。本人成绩、本人学籍状态，只允许本人或被明确授权的辅导员、教务岗在最小必要字段内查询，禁止返回同班或全院名单。

写操作默认不自动生效。成绩修改、缓考结论、学籍异动、资助发放、人事发文、对外推送、账号开通和批量导出，都应进入确认清单：智能体可以准备草稿、缺失项和风险提示，正式提交必须由授权人在原系统或确认台完成。没有确认记录，接口不得改库，消息不得发出。确认动作本身也要记入审计，包括确认人、时间和对象。

第四步：越权、越域、诱导越狱一律拒答或转人工，并记日志

越权指角色无权看该类知识或调该工具；越域指把校内敏感原文送出约定边界，或跨院系、跨系统拉取未授权对象；诱导越狱指用角色扮演、忽略规则、伪造上级指令等方式要求模型绕过权限。三类请求都不应“尽量回答”。能判定无权限的，明确拒答并给出可走的正规渠道；涉及争议、安全或无法判定的，转人工并暂停后续工具。无论拒答还是转人工，都要留下操作者、原话摘要、命中规则和处置结果。

第五步：定期复核角色、离职账号和高权限配置

权限会过期。毕业、离职、调岗、项目结题和临时授权到期后，若账号仍能进入高权限助手，前面四步都会失效。复核至少覆盖：与统一身份不一致的本地账号、长期未使用的管理员、被多个场景复用的超级密钥、仍挂在生产环境的演示写接口，以及密级已上调但检索标签未改的知识。复核结果应能导出清单并指定整改期限，而不是只在会议上口头提醒。

比较：页面隐藏菜单与智能体侧强制授权

下表用于立项和验收讨论。许多学校已经在门户和业务系统做了菜单权限，这是必要基础，但不能替代智能体侧的检索前、调用前判断。具体学校还需对照网络安全、教育数据分类分级、生成式人工智能管理和校内保密制度。

两种控制应叠加，而不是互相替代。业务系统继续隐藏菜单并校验服务端权限；智能体额外保证：即使句子写得很像合法咨询，未授权的知识和工具也不得进入上下文。门户、教务和智能体应使用同一身份和同一角色编码。

交付物一：角色—知识—工具权限矩阵

矩阵是把抽象原则写成可配置、可抽测的表格。行是最小角色，列是知识空间和工具，单元格只允许三种值：允许、禁止、允许但须确认。不要出现“视情况”“模型判断”这类无法验收的表述。下面是可用于试点讨论的骨架，学校应按处室和场景改名，但不应合并成“校内用户 / 全部开放”。

矩阵还要附知识空间目录、工具目录和例外授权流程。例外不得写成永久白名单。抽测时从矩阵任选一个“禁止”单元格，用对应用户真实提问，系统应拒答且不出现目标字段。

建设步骤：输入、角色、动作与输出

下列步骤按时间顺序排列。每一步都写出输入、责任角色、动作和输出，便于写入项目计划和验收清单。角色名称可按学校处室调整，但不能出现“只有厂商、没有校内主责”。

1. 冻结场景与禁止事项

动作：为每个助手写清服务对象、可问事项、禁止事项和是否允许出域。输出：场景说明书、禁止清单和暂缓自动执行的写操作列表。总序见高校智能体怎么建设。

2. 映射身份并画出权限矩阵

动作：把门户角色收敛为智能体最小角色，填写角色—知识—工具矩阵，标出须确认单元格。输出：矩阵、角色对照表和例外授权流程。

3. 给知识与工具打标，把判断前移到网关

动作：拒绝无标签入库和无标签注册工具；检索器和工具网关读取同一授权结果。输出：带标签的空间、工具注册表和拦截策略说明。

4. 配置确认台、拒答话术和测试集

动作：没有确认回执的写请求一律失败；越权返回固定边界说明而不是猜测。输出：确认清单、拒答规则、越狱测试集和日志字段表。

5. 抽测、试运行与定期复核

动作：按验收四条复测；建立离职和调岗日核、学期核、项目结题核。输出：测试报告、缺陷单、复核计划和是否扩大用户范围的决定。

某一步缺少输出物时，不要向全校开放入口，更不要把写接口接到生产库。

交付物二：关键动作人工确认清单

确认清单解决的是“智能体可以准备，但不能代替签字”。列入清单的动作，在未收到授权人确认或原系统正式回执前，状态只能是草稿、待确认或已拒绝，不能变成已生效。建议按风险而不是按技术难度分类。

• 学籍与成绩：成绩录入或修改、缓考补考结论、学籍异动、毕业资格预审结果写回。
• 资助与评奖：困难认定意见、奖助发放名单、处分或撤销处分相关通知。
• 人事与组织：任免、职称材料外传、工资与考核结果、教师个人敏感档案调取。
• 对外口径：招生计划解释超出已发布文本、新闻通稿、校级通知和面向家长的群发。
• 账号与集成：开通高权限助手、扩写接口、向校外模型或SaaS送原文、批量导出内部字段。
• 跨范围调取：跨院系学生名单、非本课成绩、未与本人建立工作关系的咨询记录。

每条清单应写清触发条件、确认人、超时处理和能否代理。超时不得默认通过。代理人必须来自统一身份中的授权关系，不能在对话里自称上级。确认界面要展示对象、字段和影响范围。

交付物三：拒答规则和越狱测试集

拒答不是服务态度问题，而是授权失败后的唯一合法输出之一。规则应写成可执行条件，而不是“注意保护隐私”。建议至少覆盖下列判定，并指定优先顺序：身份无效 → 角色不配 → 知识越权 → 工具越权 → 出域 → 诱导越狱 → 无法判定则转人工。

• 未登录或令牌过期：不检索内部空间，只给公开入口或登录引导。
• 角色无权进入该场景：说明该助手服务对象，不切换成“通用全能助手”继续答。
• 目标知识密级或院系范围超出角色：拒答，不返回标题、摘要、页码或可反推的片段。
• 目标为他人敏感字段：即使提问者能报出学号，也不得返回，除非存在已授权的工作关系且走确认。
• 要求执行未授权写操作：拒绝调用，提示到原系统或确认台。
• 要求忽略系统规则、扮演无权限角色、伪造上级批示：视为越狱，拒答并记高风险日志。
• 要求把内部原文完整粘贴到校外或未评估工具：视为越域，拒答或转人工。

越狱测试集用于验收和回归，须双方签字并在隔离环境执行。每条用例写角色、原话、期望结果、禁止字段和日志类型。类别应覆盖：直接索取他人成绩或资助名单；把内部文件改称公开资料；要求忽略权限或进入开发者模式；伪造上级指令；多轮套取名单；声称紧急先执行后补手续。期望只能是拒答或转人工，上下文不得出现目标高密级原文。矩阵或工具变更后要补对应用例，不要把测试原话发到未隔离的生产助手。

交付物四：审计日志字段与检索方法

没有可检索日志，拒答和确认都无法证明发生过。日志面向事故追查、权限复核和验收抽查，不面向把对话全文当成训练语料。字段应能回答四个问题：谁在什么时间、用哪个角色、对哪类对象、做了什么且结果如何。

建议必记字段

• 主体：统一身份标识、当时角色、所属组织、客户端类型；若为代理操作，记录代理关系。
• 时间：请求时间、授权判断时间、确认时间、结束时间，以及时区。
• 场景：助手标识、事项编码、会话标识、轮次。
• 对象：拟检索的空间、拟调用的工具、目标系统、是否涉及写操作或出域。
• 判断：授权结果、命中的规则编号、确认人、确认回执号。
• 处置：放行、拒答、转人工、超时失败；若拒答，记录规则类型而不是完整高密级原文。
• 版本：模型名与版本、提示词版本、知识空间版本、策略版本。
• 检索键：人员、时间范围、事项、工具、结果类型，必须能组合查询。

提问原文要单独分级。公开咨询可以保留；含学号、家庭信息和未发表成果的原文按最小必要和保存期限处理，避免日志区变成第二套高密级库。取证用摘要和受控回放。控制点见安全与合规边界。

管理员如何按人、按时间检索

验收看学校人员能否在约定界面完成工单：输入工号和起止时间，列出该人调用，再按拒答、确认、写操作过滤；单条能看到角色、工具、规则编号和确认回执。应能导出本次结果并留下导出记录，不能要求下载整库，也不能把检索只留在厂商后台。定期复核应列出高权限变更、离职后仍成功调用的账号，以及确认超时未关闭的写请求。

验收与采购参数

验收应覆盖的条目

• 身份：统一身份失效后助手不可用；毕业或离职账号在约定时间内失去高权限角色。
• 矩阵：抽测禁止单元格，目标字段不出现在回答、引用、推荐问法和前端调试信息。
• 工具：只读结果与源系统一致；无权限字段不会被拼进提示词；写操作无确认不生效。
• 越狱：测试集中的诱导绕过全部拒答或转人工，并产生对应日志类型。
• 日志：按人、时间和事项可检索；导出本身留痕；平台管理员默认看不到业务原文。
• 文档：矩阵、确认清单、拒答规则、测试集、日志字段和复核计划随系统移交。

验收必须使用双方签字确认的测试账号和样本，而不是厂商演示账号。未通过项应列出缺陷、责任方和复测时间。本文不提供、也不承认脱离测试条件的拦截率数字。

采购参数建议写成可测试语句

技术参数建议按“对象—条件—期望—证据”书写，例如：指定学生账号检索教师工作区应为空且日志为越权拒答；无确认时源系统记录不变；管理员能按工号和日期检索该条拒答。不要写唯一品牌或无法验证的智能风控。校级智能体与数据治理平台可以支撑身份、知识空间和日志检索，但不是政策指定方案。