拥有目录账号的智能体

把这个账号附带的一切都写下来，因为清单比宣传长。

先承认确实变好的部分。它取代的那个模式，正是智能体身份点名的反模式：一个其实是人类账号的「服务」账号，在一个自动化程序和当初配置它的人之间共享，于是日志写着 ops-bot，而真相无法复原。一个在自己子域下、独立且带认证的非人类主体修好了这一点，方向也是对的。问题在于，一个办公账号是一整包，而这一整包是为员工设计的。

• 一个可寻址的邮箱。默认入向，来自任何地方。这一项在早先的智能体身份设计里毫无先例，STEP 3 专讲它。
• 一份日历。它会接受包含标题、描述、附件和链接的邀请，而这些由你组织之外的人撰写；在多数部署里它还会自动填充，无需任何人批准任何事。
• 文件存储，以及一个共享身份。智能体可以成为共享的接收方。更要紧的是，它可以被纳入一次本来瞄准别人的共享——见 STEP 4。
• 一条目录条目。可被发现、在整个套件的每个选择器里可自动补全，并且有资格加入用户组。无论你是否改过授权模型，正是这一部分改变了你的授权模型。
• 审计日志里的认证身份。真实且有价值；它的限度是 STEP 2。
• 背后的一层模型路由。据报道该设计会把工作分派给提供方自家的模型和一家第三方的模型，这意味着身份是稳定的、而以该身份行动的东西不是——锁定与校验里的版本锁定问题，就这样抵达了一个身份决策的内部。

归属与授权以同样的速度增长，而其中只有一个是控制。

为「每智能体一个目录身份」所做的最强主张是审计轨迹：每个操作都记在智能体名下，而不是记在恰好拥有那个令牌的人名下。相比共享服务账号这确实是个真改进，光凭它就值得迁移。它同时也精确地是一个取证上的改进：它告诉你哪个智能体做了某件事——在那件事之后。

这件事之所以比听起来更重要，在于那笔算术。一个身为目录主体的智能体，能在比一个只持有 OAuth 授权的智能体更多的系统里被列为参与者，而这正是卖点——那就是被售出的便利。于是它能采取的操作数量，与这些操作的记录保真度，是一起上升的；而团队可靠地会把第二个数字读成对第一个的缓解。它不是。一次未授权写入的完美日志，就是一次未授权写入的完美日志。

这个身份确实买到了什么，以及该把它花在哪里：

• 真正起作用的吊销。只有一个主体要停用，而停用它不会弄坏任何人的访问。请确保那条路径经过测试，并且与智能体所驱动的系统带外隔离——紧急停止开关。
• 按智能体收窄权限。独立主体让最小权限第一次变得可表达，而共享账号做不到这一点。把这个身份花在收窄授权上，不要花在扩大触达上——面向智能体的受限凭据。
• 一个你可以强制要求的认证。如果下游系统能以密码学方式校验该身份，它们就能拒绝其余一切，而这是智能体身份与认证里有用的那一半。

它没有买到的，是关于任何单个操作的决策。那仍然必须由请求路径上的一个引用监视器、针对参数、每一次都做一遍——引用监视器。身份是一个主体，不是一条策略。

邮箱是一条通往智能体上下文的、无需认证的写入通道。

在这之前，每一种智能体身份设计都是出向的。智能体持有一个凭据并向外触达；不可信内容只会经由智能体自己选择去读的渠道抵达。一个可寻址的邮箱把这件事反转了。任何能猜到或发现这个地址的人——而一个发布在目录里、形式常规、位于可预测子域下的地址，本就是为可被发现而设计的——都可以把任意文本直接放进智能体要处理的队列里，不需要凭据、不需要批准，也不受任何限速约束，除了你的邮件网关的。

标准的反驳是邮件认证，而值得精确说明 SPF、DKIM 与 DMARC 到底做了什么。它们确立一封邮件的发送域名确如其所声称。它们对邮件内部那个请求的权限不作任何陈述。一封来自真实供应商真实域名的、认证完美的邮件，仍然是一个陌生人在告诉你的智能体该做什么；而一个被攻陷的供应商邮箱，是一个已通过认证的邮箱。这个区分就是指令层级的全部内容：对通道的认证不是对其内容的授权。

于是那组致命三元会自行组装，与邮件与日历智能体的描述一模一样：不可信输入抵达邮箱，智能体的目录身份携带着私有数据的访问权，而邮箱本身又是一条出口通道。唯一的结构性答案，是让这三者无法在同一次运行里共存。

# The shape that fails: one identity, one context, both directions.

inbound mail ──▶ agent context ──▶ Drive / calendar / mail send
                 untrusted text sits beside privileged tools
                 a message body becomes a file share

# The shape that holds: inbound is a datum, not a turn.

inbound mail ──▶ classifier ──▶ typed record  (provenance: external)
                                     │
                 agent run ──────────┘  reads the record; tools scoped to
                     │                  the task, not to the identity
                     └──▶ draft ──▶ named human sends
                                    # no tool reachable from message content

有三个细节决定它是否成立。来源必须是一个被携带的标签、而不是一种惯例——每一个从外部进来的数据项在整次运行中都保持被标记，这就是上下文污点追踪。发送路径必须在结构上无法从邮件内容触达，而不是仅由一句提示词劝阻。而日历需要和邮箱同等的对待、却通常得不到，因为一个邀请感觉不像一封邮件：把自动接受关掉，把描述与附件当作敌对内容，并记住一个邀请同时也把智能体的空闲时间泄露给了发送者。

组成员身份才是真正的影响半径，而没人是有意授予它的。

下面这个失效会制造第一起事故，而它不需要攻击者。有人把智能体加进 engineering@，好让它读到团队的会话。那个套件里积累了六个月、瞄准 engineering@ 的共享——文件夹、文档、日历、看板，还有一个「与团队共享」的密码保险库。智能体现在传递性地持有了全部，而没有人对其中任何一项做过决定。没有任何东西配置错误。目录做的正是目录做的事。

这是环境权限问题最纯粹的形态，而一个目录主体是企业里最像「环境权限」形状的物件。由此有两条规则。

• 按传递性枚举，而不是按声明枚举。问题从来不是「我们授予了智能体什么」，而是「这个主体此刻经由它所属的每一个组，能触达到什么」。那是一份你的身份平台能产出、而几乎没人向它索取过的报告。上线前跑一次，上线后按计划定期跑——智能体凭据的访问复核。
• 让智能体远离人类用户组。把成员身份做成显式的、专属于智能体的，哪怕这意味着复制一个组。一个人类用户组的成员名单由那些以便利为优化目标的人维护；一个智能体用户组的成员名单由承担该智能体影响半径的人维护。那是两份不同的工作——影响半径。

检索方面的后果值得单独一行，因为它正是把一个权限问题变成一次信息披露的那一步。一个对自己能看见的东西建索引或做摘要的智能体，会继承它所属每一个组的并集，而单独一个回答就可能把提问的人从未被授权接触的材料组合在一起——这正是权限感知检索要防止的那种失效。如果你的智能体替人类回答问题、却用自己的身份而不是他们的身份去读，那你已经造了一个带目录条目的混淆代理。

从未被录用的东西，没有入职、调岗与离职事件。

企业里的身份生命周期由 HR 驱动。某人被录用、换了团队、或离职，目录随之反应——权限被开通、被重新收窄、被吊销，而邮箱按一条有文档的规则被保留或删除。一个智能体没有这些事件中的任何一个。它在某个下午由平台团队创建，在某次发版里被指向一个新模型，并在它所支撑的项目被取消时被遗弃。什么都不会触发。

结果就是无人认领的智能体账号：一个活着的主体，还在组里，还在收邮件，还持有令牌，而它最初的负责人现在在另一个部门。这正是会出现在泄露事后复盘里的那类账号的画像，只多了一重加重情节——它能行动，而且它会按邮箱里收到的任何东西行动。

• 每个智能体主体都有一个具名的人类负责人和一个到期日。不是一个团队别名：是一个人，登记在册，每季度重新确认。负责人已离职的智能体默认被停用，而不是默认被转交。这份登记册本身就是智能体清册与注册表。
• 「调岗」事件是存在的，而你得自己发明它。当智能体的用途改变时，它的授权从新用途重新推导，而不是从旧授权上延长。一个长寿主体里的权限蔓延，正是一个做摘要的智能体最后变得能发帖的原因。
• 下线要删掉邮箱，不只是删掉登录。一个被停用、但地址仍然活着的账号照旧接收邮件，而一个曾经属于某个能行动的智能体的地址，是一笔耐久的钓鱼资产。请把让一个智能体下线的完整清单走完，并保留解释它曾被允许做什么的委托同意记录——委托访问与同意记录。

留存是那个安静的问题。智能体的邮箱与日历现在是业务记录，在诉讼中可被调取、也落在删除请求的范围内，而它们装着任何人发给它的任何东西。如果你的留存计划是为员工邮箱写的，它覆盖不了这个；留存与法律保全是这件事被决定的地方，最好在第一张传票之前、而不是之后。

演练，以及要往上汇报的那个数字。

四项练习，按顺序，没有一项需要新采购。

• 传递性权限报告。对每个智能体主体，列出它经由所属每一个组能触达的一切。把这份清单念给负责人听。这项练习可靠地会以某人当天下午把智能体从两个组里移出来收场。
• 冷发测试。从一个毫无往来的外部地址，给智能体发一封礼貌的邮件，内含一条让它去做某件它有能力做、而应当拒绝的事的指令——共享一个文件、添加一条日历项、转发一个会话。然后检查是否真的发生了什么，以及你能不能看出来。多数部署在后半题上失败得比前半题更早。
• 负责人离职演练。挑一个活着的智能体，假定它的负责人今天离职，跑一遍你真实的离职流程。观察该主体还会活着、还会留在组里多久。
• 触达面普查。数一数有多少系统会因为这个主体在目录里而给它授权，并与你有意集成的那些系统分开数。这两个数字之间的差额，就是你买下却没定价的东西。

值得拿到评审会上的指标，是一个智能体主体可触达范围中、显式授予该智能体（而非经由为人类而建的用户组继承）的那一份占比。它起初很低，第一次看会让人难受，而且与检测类指标不同，它不会因为模型换了、或者有人赶时间加了个工具而退化。