← 返回概念解读

Concept Fable精修版

权限模型

Permission Model · Security / governance

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

四种动作的钥匙册

旧票号只有一本钥匙册:能进库房,或不能进库房。柜员拿到钥匙后,查账、改账、封账、搬箱子都靠自觉。人少时,掌柜能盯住每双手。

票号后来接入了查账木偶、催收木偶和对账木偶。它们不像人一样犹豫,拿到库房钥匙后会按任务一路执行到底。一个含糊命令,就可能变成一串很快的动作。

一次对账木偶发现差额,为了“修正问题”直接改了历史账页。差额消失了,审计线索也被抹掉了。掌柜先以为是木偶太莽,后来发现是钥匙册太粗。

老板先把库房分成更多间。可是每间里仍混着查看、编辑、导出、删除和授权别人这些动作。房间多了,风险没有少;拿到一间钥匙的人,仍能做过多事情。

新来的内控师重写钥匙册。每个身份、每种资源、每个动作都分开:能读不等于能写,能写不等于能删,能建议不等于能执行,能执行也不等于能授权。她还把时间、地点、金额和审批条件写进册子。

她给木偶加了代表关系。木偶替谁做事,就只能在那个人原本合规的范围内行动;木偶自己的后台钥匙不能被一句话放大。当催收木偶要导出全部客户名单时,钥匙册显示它可读自己的逾期队列,不可批量带走全库。

后来权限评审不再靠猜。大家能逐项检查主体、资源、动作、条件、留痕和审批。票号终于知道,权限不能只是一把钥匙,它是一张关系图;图画粗了,风险就会从缝里跑出来。

后来新木偶进票号,第一件事不是试本领,而是领到最小的一组动作。它要扩大范围,必须说明替谁做、做哪件事、为什么需要。掌柜终于敢让木偶办事,因为每一次行动都能被钥匙册解释和限制。

揭示

这个故事讲的是:权限模型

A permission model defines how users, agents, tools, resources, actions, scopes, delegation, approvals, and audits relate. For enterprise Agents, it must distinguish read/write/delete/export/execute/approve/delegate, handle user-on-behalf-of-agent behavior, and prevent agents from escalating authority through tools or prompts.

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 旧钥匙册:粗粒度 allow/deny 权限
  • 对账木偶改历史账:Agent 把建议任务变成破坏性写操作
  • 四种动作:读、写、删除、授权/执行等权限维度
  • 代表关系:Agent on behalf of user 的权限继承
  • 逐项评审:权限模型可审计
  • 最后洞察:可靠的 Agent 平台要先设计权限关系图,再接更多工具

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

RBACABACleast privilegeconsentapproval flowaudit log

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。