智能体有了工牌：Agent 上生产，先解决身份
48 小时内，Google 给智能体发了邮箱、日历和通讯录条目，AWS 把权限校验搬到查询那一刻，微软要求每个智能体必须有人类担保人。当 Agent 从个人助手变成团队同事，决定它能否上生产的不是模型分数，而是身份与归属。
企业智能体落地卡住的地方，已经从「模型够不够聪明」换成了「这个动作记在谁头上」。 过去 48 小时，三家云厂商几乎同时把答案指向同一件事：给智能体一个独立身份——自己的邮箱、自己的凭据、写在日志里的自己的名字。
48 小时里，智能体拿到了自己的工牌
10 月 8 日，Google 在 Gemini at Work 大会上发布了一个「通用的工作智能体」。真正值得记下来的不是它能写代码，而是一个更细的设定：它可以把智能体变成「同事」——这个同事有自己的 Workspace 账号、自己的邮箱（形如 @agents.company.com）、自己的日历和云盘，还会在公司通讯录里占一行。它会被拉进群聊、被 @，在文档的版本历史里以自己的名字留下修改痕迹。
配套的治理设计也在同一份发布里：每个智能体拿到一份可加密验证的、最小权限的身份，这份身份会盖在它产生的日志上；调用外部系统时，身份通过 OAuth 传递；它做的每个动作，都记在智能体自己名下，而不是某个员工名下。所有智能体跑在带独立网络边界的 Agent Sandbox 里，流量统一经过 Agent Gateway——一个「AI 网络防火墙」；项目级的花费上限触发时，被暂停的是智能体本身。
接着是 AWS。10 月 7 日发布的方案把 RAG 的权限校验拆成了两步：先用索引里已有的权限属性做一轮预筛、缩小候选集；再拿候选文档实时回源验证当前用户是否仍有权限——只有通过验证的段落才会进入模型上下文。它要解决的是三个具体毛病：AI 系统自己不是权限的权威源、同步周期内的权限会过期、数据源的权限模型还在不断变化。据 AWS 披露，亿滋国际（Mondelēz International）已在四大区域、超过 3.5 万名员工范围内使用这一方案。
国内也在同一周。10 月 8 日，由华为 2012 实验室、华为云等团队联合开发者社区构建的 openJiuwen 开源了企业级 AgentOS，把多租户隔离、安全沙箱、权限管理与安全护栏写进运行底座，对外则提供统一的 Agent 网关与五类可组合资产（技能、连接器、插件、专家、专家团）。
而 Google Cloud 同一天公布的客户案例，给出了这套东西跑起来有多快：Orange Spain 让员工用低代码搭了 1,000 多个自己的智能体，30 天内许可活跃率接近 100%；运动品牌 On 用多智能体把 24 个核心服务迁上云，单个服务的迁移周期从三个月压到两周，其中 15 个完全由内部工程师完成，计划内停机控制在每服务 5 分钟以内——此前外部供应商为其中一小部分服务报过 50 万美元的价。
把这几件事放在一张表里，方向就很清楚了：
| 厂商 | 给出的机制 | 关键设计 |
|---|---|---|
| 智能体独立的 Workspace 账号与可验证身份 | 动作记在智能体名下；Agent Sandbox + Agent Gateway | |
| AWS | 不改身份模型，改权限校验的时机 | 查询时向权威源实时校验访问控制列表 |
| Microsoft | Entra Agent ID 的智能体账号子类型 | 不能设密码、不能授特权管理员角色、必须有人类担保人 |
（Microsoft 那一行的依据，是 The Daily Brief 对两家身份模型的对照梳理。）
共享账号：一个伪装成便利的事故
上面这些设计，反过来说明了一个不太被摆上台面的现状：今天大多数企业里的智能体，用的是某个人的账号。
它一开始很自然——那个账号是现成的，权限也够，接进去就能跑。但它会在三个地方同时出问题。
第一，审计失效。 智能体代你下单、改配置、发通知，日志里写的是你的名字。出了事，你没法区分「我做的」「我批的」「它自己做的」。这不是合规部门的洁癖：当一个动作无法归因到具体的决策主体，调查、复盘、追责、改进就全都失去了着力点。
第二，权限通胀。 为了让智能体能干完整的活，通常要把它接进一个权限足够大的账号——往往是某位管理员。于是最小权限原则在第一步就被放弃了：一个只该读订单的智能体，实际握着那个账号的全部能力。一旦出现提示注入或越权，损失按账号权限的上限计，而不是按任务的实际需要计。
第三，生命周期错配。 人转岗、离职、权限收紧，智能体的可见范围不会跟着变；反过来，撤销智能体又不该动到那个人。两条生命周期被绑在一起，手动拆开的成本会随智能体数量线性上涨——而 2026 年的现实是，这个数量正在从个位数变成上千。
这其实是安全领域一个老问题的新版本：混淆代理人（confused deputy）——一个权限更大的主体，被诱导替低权限的请求者做事。业界对它的标准解法也早有答案：给代理一个属于它自己的身份，让它在日志里代表自己，而不是代表你。
微软在 Entra Agent ID 里把规则写得很死：智能体账号是一个独立的用户子类型，不能设置密码或通行密钥、不能被授予特权管理员角色，并且每个智能体必须指定人类担保人（sponsor），担保关系要随人员流动持续维护——因为担保人一旦离开，需要有人接续。（据 The Daily Brief 的对照梳理）
四个问题，第四个平台答不了
Google 把这件事收敛成了四个问题：它是谁、它能做什么、它做了什么、它绝不能碰什么。
| 问题 | 主要责任方 | 要落成什么 |
|---|---|---|
| 它是谁 | 平台 + 安全管理员 | 独立凭据、OAuth 身份传递、可验证声明 |
| 它能做什么 | 安全管理员 + 业务负责人 | 角色化权限、最小权限、项目级限额 |
| 它做了什么 | 运行底座 | 记在智能体名下的动作账本 |
| 它绝不能碰什么 | 数据与业务方 | 数据范围、字段敏感级、卡片级授权 |
前三个问题，云厂商正在用产品回答，而且答案越来越像：独立身份、最小权限、动作账本。它们共享同一个前提——「智能体是一个可被管理的实体」。这句话直到 2026 年下半年，才真正成为行业的默认设置；而它带来的，正是我们此前写过的行动账本那套东西——从建议变成了出厂配置。
第四个问题不一样。「绝不能碰」不是平台能替你决定的，它是你的数据的一个属性。 同一套 Agent Gateway 策略，在 A 公司可能意味着「不许碰薪酬表」，在 B 公司可能意味着「不许碰上个月的对账明细」。平台看得见流量走向，但不知道哪一列属于谁、哪个口径是真的、哪张表里其实混着两个业务域。护栏应该建在哪一层，我们此前专门讨论过——结论是：越靠近数据，越难绕过。
所以第四个问题只能回到数据层回答：范围内有哪些实体、每个实体里哪些字段默认不可见、敏感字段对谁开放。这件事不做，前三个问题即使全部答对，也只搭起了一套没有内容物的权限框架。
把授权粒度收进卡片
当智能体从 10 个变成 1,000 个（Orange Spain 的 1,000+ 与 openJiuwen 的「五类资产」都在朝这个方向走），逐个人工配置权限必然失效。规模问题只有一个解法：换一个有意义的授权单位。
- 单位太大（一个数据库账号）→ 一旦泄漏，爆炸半径等于整个账号；
- 单位太小（逐字段授权）→ 没人维护得动，半年后必然失真；
- 中间那层——按表或按 schema 授权——看似合理，但一张表里通常混着公开字段和敏感字段，权限只能取最严的那一档，可用性随之崩掉。
合理的单位是数据卡片：一张卡片对应一个业务实体（订单、退款、客户、设备），它同时带着三样东西——语义（每个字段是什么、指标口径是什么）、范围（哪些行属于这个业务域）、敏感级（哪些字段默认不可见、需要脱敏还是直接隐藏）。给智能体配权限，于是从「发一个账号」变成「把哪几张卡片交给它」。
这带来两个直接好处。可枚举：交付给智能体的是一份有限清单，可以被安全团队评审、被审计追查、被一键回滚。可复用：卡片是资产，新智能体接入时复用的是同一份范围定义，而不是重新复制一遍某个人的岗位权限。
顺带说一句语义层——它其实也是「身份」的一部分。如果「营收」在三个部门有三种算法，那么同一个智能体在不同部门的语境里会看到三个不同的世界，而日志里只会留下一个数字。让所有智能体从同一份定义出发，和让它们用自己的凭据说话，是同一种工程纪律的两面，语义层的价值正在于此。
最后是一份可以直接拿去对照的清单。它不复杂，难的是每一条都要有人负责：
- 独立凭据：一个智能体一个服务账号，永远不用个人 token——撤销的时候只删一样东西
- 人类担保人：明确到人，并跟着人员变动一起维护，而不是设完不管
- 动作账本：动作记在智能体名下，同时记下「谁授权了这个智能体」
- 卡片级授权：读范围写成一张卡片清单，字段敏感级在检索之前生效
- 关键动作人工确认：改价、删除、支付、发布、对外发消息，并配一条回滚路径
- 花费上限与熔断：到线先暂停智能体，而不是暂停项目——成本本身也是一种安全控制
结语
回过头看这一周，真正的变化不是某个模型又强了多少，而是智能体的失败模式从「说错话」变成了「做错事」，于是组织第一次需要为一件不是人做的事，分配身份、权限与责任。
有三个问题值得在今年剩下的时间里想清楚：你的智能体现在用谁的账号；它的动作在日志里记在谁头上；以及——如果明天要有一个新智能体上岗，你能不能拿出一份清单，说清楚它绝不能碰什么。
在 OntiCards 的架构里，这份清单就是数据卡片本身：卡片承载语义与范围，本体层保证同一个词在全组织只有一个意思，技能库声明风险等级与失败兜底，智能体生态只能在这三者划出的边界内行动。想看这套权限模型具体长什么样，可以从产品页开始；已经做过智能体试点、正在纠结权限怎么收口的团队，欢迎写信到 hello@onticards.com 聊聊你们的场景。
