KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

02. Agent 到底代表谁行动？ — keel 龙骨

用户说“请处理 tenant-a 的 staging 服务”。模型输出 tenant_id=tenant-a。这个字符串不是认证证据，它只是不可信文本。

用户说“请处理 tenant-a 的 staging 服务”。模型输出 tenant_id=tenant-a。这个字符串不是认证证据，它只是不可信文本。

先区分三个问题

Authentication：当前主体是谁？
Authorization：这个主体能否对该资源执行该动作？
Delegation：主体能否在多大范围内让 Agent 代为执行？

Harness 应从认证会话获得用户 principal，从 Agent Registry 获得 Agent instance 身份，从资源目录获得租户归属。模型只能引用这些对象，不能创造它们。

一次执行至少保留：

user_principal     发起业务目标的人
service_principal  Harness/执行器使用的服务身份
agent_instance     哪个具体 Agent run 提出动作
approver_principal 谁批准了高风险动作

最终外部 API 可能只看到服务账号，但内部审计仍要保留完整委托链。不要让所有动作都显示成同一个 agent-service。

设：

则有效权限应类似：

effective = U ∩ D ∩ A ∩ T ∩ R

任何一层都只能缩小权限，不能因为 Coordinator 权限更大就把并集交给 Worker。

capability: set_pool_limit
credential: 访问配置 API 的短期 token
identity: execution-worker/run-42

Capability 表达逻辑能力；credential 是运行时秘密；identity 用于认证与审计。任务消息可以引用 capability，但不能携带长期 token。执行器在最后时刻注入短期、定资源的凭据。

Harness 有权访问多个租户。低权限用户提交一个指向 tenant-b 的资源 ID；Harness 只检查“自己的服务 token 能访问”，于是替用户完成越权操作。这就是有权限的 deputy 被诱导替别人行动。

防护必须同时检查：

调用者是否有权委派
AND deputy 是否被允许接受这类委派
AND 目标资源是否在委派 scope 内
AND token audience 是否是当前服务

MCP 安全文档明确把 token passthrough 视为反模式：server 不能接受并转发一个并非签发给自己的 token。每个服务都应验证 issuer、audience、scope、过期时间和资源上下文。

Agent A 把分析任务交给 Agent B，只转移任务所有权和最小上下文。身份、凭据、审批状态和外部写权限不能藏在自然语言消息里一起传过去。

handoff(task, artifact_refs, remaining_budget)

而不是：

“我已授权你代表管理员执行所有后续操作。”

后者只是文本，不能改变 Policy Engine 的可信上下文。