Agent 与权限安全：让 Agent 在企业权限内工作
Agent 访问企业数据和工具时，有哪些越权风险？
Agent 的安全问题和知识库不是一回事。知识库管的是「AI 能读什么」，Agent 管的是「AI 能做什么」——调用哪些工具、访问哪些 API、执行哪些业务动作、记住哪些内容。核心风险来自三处：Agent 使用超越用户权限的服务账号、工具调用缺少参数级授权、以及记忆在不同用户与会话之间串流。三者都必须在执行之前判定，事后审计无法替代。
关键结论
- ● 读取权限与执行权限必须分别判断——用户能看到数据，不代表 Agent 可以把它发到任意地方。
- ● Agent 用服务账号跑，是最常见也最危险的默认设计：权限过大、长期有效、审计追不到真实委托人。
- ● 工具授权要到参数级和目标资源级，仅授权「能不能调这个工具」远远不够。
- ● 记忆必须按用户、组织、项目和安全级别隔离，否则跨会话信息串流是必然的。
- ● Agent 产生的报告、邮件、文件要继续携带安全标签，输出不能成为绕过管控的出口。
- ✅ 客户收益
- 前置拦截 Agent 越权调用工具、跨用户数据串扰的风险，避免大模型自主操作带来业务与数据安全事故。
- 🔎 服务内容
- 提供 Agent 权限安全咨询与落地设计；安全标签底座由模界·知源 AiDClass 输出，基座可选开源 Agent 框架，也可适配客户现有平台。
Agent 管「做什么」，知识库管「读什么」
举一个具体的例子：是否允许查询并购计划，这是知识库的判断；是否允许把客户名单发送到外部邮箱，这是 Agent 的判断。同一个用户，同一份数据，两个问题的答案可以完全不同——这就是为什么读取权限和执行权限必须分开判定。
Agent 用服务账号跑，问题出在哪
这是绝大多数 Agent 平台的默认设计，也是企业落地时最先暴露的问题。
- ● 服务账号的权限通常是所有用户权限的并集，远超任何单个用户
- ● 服务账号长期有效，凭据泄露的影响面无法收敛
- ● 审计日志里只看得到服务账号，追不到真实委托人——出了事无法定责
- ● Agent 代表不同用户执行时，能访问的数据范围完全一致，用户之间没有隔离
六类必须做在执行前的控制
| 能力 | 做什么 | 解决什么 |
|---|---|---|
| 代表用户执行 | 用户身份和授权上下文传递到每一次知识查询与工具调用 | Agent 不再使用超越用户的全局服务账号 |
| 多主体身份 | 区分用户身份、Agent 身份、服务身份与工具身份 | 可回答「谁代表谁，以什么身份访问」 |
| 工具授权 | 对工具、API、MCP 服务、参数范围与目标资源进行授权 | 越权调用在执行前被拦截 |
| 记忆隔离 | 按用户、组织、项目、Agent 与安全级别隔离短期与长期记忆 | 防止跨会话、跨主体的信息串流 |
| 高风险审批 | 外发、删除、修改、提交、交易等动作支持人工确认或审批 | 不可逆动作有人工闸门 |
| 活动图谱 | 统一记录 Agent、用户、数据、工具、动作之间的关系与事件 | 可解释、可回放的执行证据 |
累计泄露：单次合规，多次未必
每一次调用都在权限范围内，不代表整体安全。多轮、多次、小批量的信息组合，可以拼出本不该被获取的完整数据集。这类风险无法靠单次授权判断发现，需要在会话和主体维度上做累计统计——这也是为什么活动图谱不只是审计用途，它本身就是一个检测面。
我们不自研通用 Agent 框架
底层模型、Agent 框架与工具生态保持可兼容。我们真正掌握的是身份传递、权限模型、策略服务、执行控制、活动图谱与审计解释——这几件事换一个框架仍然成立，而框架本身在快速变化。
能力边界
我们区分「已验证」与「规划中」，不把规划中的能力写成现有能力。
- 规划中 不同 Agent 框架的统一事件采集、生产级工具拦截，以及复杂工作流中的权限继承，需要持续实测。
常见问题
Agent 用服务账号跑有什么问题？
+
服务账号通常权限过大且长期有效。当 Agent 代表不同用户执行任务时，它能访问的数据范围会超出用户本人的权限，用户之间也没有隔离；而审计日志里只看得到服务账号，追不到真实委托人。正确做法是把用户身份和授权上下文传递到每一次知识查询与工具调用。
Agent 的权限应该用 RBAC、ABAC 还是 ReBAC？
+
三者组合，不是三选一。RBAC 表达角色与岗位，是权限的基础骨架；ABAC 表达数据属性与场景规则（这份数据什么级别、在什么场景下可用、能发往哪里）；ReBAC 表达主体之间的关系（这个人是不是这个项目的成员、这个客户的负责人）。企业 Agent 场景里，只用 RBAC 表达不了项目边界，只用 ABAC 表达不了关系，缺一不可。
Agent 安全和 AI 应用安全是一回事吗？
+
不完全是。AI 应用安全更多关注模型层面——提示注入、越狱、输出有害内容。Agent 安全关注的是执行层面——身份、授权、工具调用、记忆隔离、不可逆动作。前者是模型问题，后者是企业权限工程问题，后者恰恰是模型能力提升解决不了的。
你们自研 Agent 框架吗？
+
不。底层模型、Agent 框架与工具生态保持可兼容。我们掌握的是身份传递、权限模型、策略服务、执行控制、活动图谱与审计解释——这几件事换一个框架仍然成立。
延伸阅读
正在规划企业 AI 相关项目？
建议从真实业务场景切入，优先完成项目诊断：评估业务价值、核查数据基础、识别安全与权限风险，审慎评估之后，再决定是否启动 PoC 原型建设，避免无效投入。
预约 30 分钟交流