Agent RBAC权限模型，限制Agent调用Shell

Agent 一旦拥有过大的系统权限，Shell、数据库、支付接口都可能变成攻击入口。
RBAC（基于角色的访问控制）通过把权限提前绑定到角色，再让 Agent 扮演特定角色，从而严格控制它能做什么。
本文用一个通用的权限配置文件示例，拆解如何限制 Agent 调用 Shell、数据库和支付接口，适合零基础运维人员直接套用。

先把权限模型拆成最小单元

RBAC 的核心是「用户-角色-权限」三层关系。
对 Agent 来说，用户就是 Agent 的调用身份，角色是权限的集合，权限则是针对具体操作或资源的允许/拒绝规则。

建议先画一张权限矩阵，把 Agent 可能需要的能力列出来，逐个标记风险等级：

• Shell 执行：高风险，默认全部禁止。
• 数据库读写：中高风险，区分只读和读写。
• 支付接口调用：极高风险，必须白名单 + 人工审批。
• 普通 API 调用：低风险，按需开放。

画完矩阵后，把需要给 Agent 的权限压缩到最小范围，不要图省事直接赋管理员角色。

准备阶段：定义角色和资源标识

在写配置前，先准备好三样东西：Agent 的唯一标识、资源命名规范、以及权限文件的存放位置。
假设项目目录为 /etc/agent-rbac，所有角色策略都放在这里。

资源命名建议采用 服务:动作:目标 格式，例如 db:write:orders 表示对订单表有写权限，shell:execute:* 表示执行任意 shell 命令。
注意通配符 * 权限极大，非必要不要用。

配置 RBAC：三条策略锁死高危操作

下面是基于 YAML 的通用配置写法，不同 Agent 平台字段名可能有差异，但核心逻辑一致。

roles:
  - name: agent_readonly
    permissions:
      - db:read:*
  - name: agent_api
    permissions:
      - api:call:public
  - name: agent_forbidden
    permissions:
      - shell:execute:deny
      - db:write:deny
      - payment:create:deny

bindings:
  - agent: my-ai-agent
    roles: [agent_readonly, agent_api, agent_forbidden]

这段配置做了三件事：
给 Agent 分配了只读数据库角色、
普通 API 角色，
同时附加一个禁止执行 Shell、
禁止写数据库、
禁止创建支付订单的拒绝角色。拒绝规则的优先级必须高于允许规则，
否则 Shell 还是会被放行，
这一点一定要在策略引擎里确认。

如果你的 Agent 平台支持更细粒度的资源限制，
可以进一步把数据库写操作限定到指定表，
例如把 db:
write:
deny 改成 db:
write:
orders:
deny，
把支付接口的白名单写得再严格一些。

避坑：通配符和角色继承最容易出问题

很多 Agent 事故不是没配 RBAC，而是配置里有漏洞。
最常见的有三类：

• 通配符过大：像 db:*:* 会把删除表也放进去，应该拆成 db:read:* 和 db:write:表名白名单。
• 角色继承被覆盖：如果角色 A 继承自角色 B，而角色 B 中有允许写数据库的规则，单在角色 A 里加 deny 不一定生效，需要检查策略合并逻辑。
• 支付接口维度不全：支付接口不仅包括创建订单，还可能包括退款、查账、修改金额，每一类都要单独配置拒绝或审批。

建议在配置里加上审计日志开关，让每一次被拒绝的调用都记录下 Agent 身份、目标资源和时间戳。
下面是一个适用于生产环境的审计配置片段：

audit:
  enabled: true
  log_path: /var/log/agent-rbac/audit.log
  include_denied: true
  include_allowed: false

验证效果：故意让 Agent 越权试试

配置完成后，不要直接跑业务，先用测试环境验证三条高危链路是否真的被拦截。

1. 让 Agent 执行 curl http://127.0.0.1/shell?cmd=whoami，预期返回 403 Forbidden。
2. 让 Agent 尝试写入一条测试订单数据，预期报错 write denied。
3. 让 Agent 调用支付接口创建订单，预期返回无权限提示。

如果上面任何一步实际成功了，说明权限规则被绕过或优先级配置错误。
此时先检查 bindings 是否生效，再检查是否有其他角色叠加了允许权限。
确认全部拦截后，再恢复真实业务流量。

如果你正在处理 Agent RBAC 权限模型，建议先把上述最小配置跑通，再逐步放开必要权限。
遇到异常时优先回头看通配符、角色继承和审计日志三条链路，大部分越权问题都能定位到这三处。