🔑 Agent 权限控制模型

🎯 为什么 Agent 需要权限控制

与传统应用不同，Agent 的行为边界由 LLM 动态决定，这使得传统的基于角色的访问控制（RBAC）面临新挑战。Agent 可能在一次对话中访问多个工具、读写不同数据源，甚至生成并执行代码。没有严格的权限控制，一个被注入的 Agent 可能造成灾难性后果。

📐 最小权限原则在 Agent 中的应用

最小权限原则（Principle of Least Privilege, PoLP）是 Agent 安全设计的基石：Agent 只应被授予完成当前任务所必需的最小权限集合，且权限应随时间、上下文动态调整。

🔢 三级权限模型

工具级权限（L1）

控制 Agent 可以调用哪些工具、以什么参数调用、调用频率如何。

权限维度	说明	示例
工具白名单	明确列出 Agent 可用的工具列表	{search_docs, query_db, send_email}
参数约束	限制工具调用的参数范围	query_db 只能 SELECT，不能 DELETE/DROP
速率限制	防止 Agent 滥用工具（拒绝服务）	每小时最多 100 次 API 调用
上下文限制	根据对话上下文动态调整可用工具	客服 Agent 不能访问财务工具

数据级权限（L2）

控制 Agent 能够访问的数据范围和操作类型（读/写/删除）。

控制维度	实现方式	说明
行级安全 (RLS)	数据库视图 + 行过滤	用户 Agent 只能看到自己的订单
列级掩码	敏感字段脱敏/加密	手机号、身份证号部分掩码
操作类型限制	只读连接 / 读写分离	分析 Agent 使用只读副本
数据量限制	Limit/Top 强制注入	单次查询最多返回 100 条

系统级权限（L3）

控制 Agent 对宿主系统的访问能力，这是最高风险层级。

• 命令执行：限制可执行的命令白名单（如只允许 ls、cat，禁止 rm、sudo）
• 网络访问：限制可访问的 IP 段、域名、端口
• 文件系统：限制可读写的目录范围（chroot / bind mount）
• 进程管理：禁止 fork/exec 或限制子进程数量

✅ 用户确认机制

对于高风险操作，应引入人工确认环节（Human-in-the-Loop）。用户在操作执行前审核并批准。

确认粒度设计

确认模式	适用场景	用户体验	安全级别
逐次确认	最高风险操作（转账、删除）	每次操作都需确认	最高
批量确认	多步骤工作流	生成操作计划，一次性审核	高
阈值确认	有明确风险阈值的操作	超过阈值（金额/数量）才确认	中
会话授权	低风险持续操作	会话开始时一次性授权	中-低

🔄 审批工作流集成

在企业级 Agent 部署中，权限控制需要与现有的审批工作流系统集成：

• 自动化审批：低风险操作（如只读查询）自动通过
• 规则引擎：基于风险评分和策略自动路由审批
• 多级审批：高危操作需要多级审批（如主管 + 安全官）
• 审批超时：超时未审批自动拒绝（Fail-Safe）

📊 权限模型对比

权限模型	核心思想	Agent适配度	灵活性	复杂度	适用场景
静态白名单	预定义允许操作清单	中	低	低	简单固定任务
RBAC	基于角色的权限分配	中	中	中	多角色 Agent 系统
ABAC	基于属性动态决策	高	高	高	复杂企业场景
Capability-based	Token/凭证传递权限	高	高	高	微服务/分布式 Agent
Just-in-Time (JIT)	按需临时授予+自动回收	极高	极高	高	零信任架构
Policy-as-Code	用代码定义权限策略 (OPA/Rego)	高	极高	中	云原生 Agent 部署