胖头鱼的技术专栏-459 Agent 也需要“身份证”（20260812）

胖头鱼的技术专栏-459 Agent 也需要“身份证”（20260812）

作者：胖头鱼的鱼缸（尹海文） Oracle ACE Pro: Database PostgreSQL ACE 10年+数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP，ITPUB认证专家 圈内拥有“总监”称号，非著名社恐（社交恐怖分子） 全网同名：胖头鱼的鱼缸 ITPUB：yhw1809 除授权转载并标明出处外，均为“非法”抄袭

本期继续“川序”的介绍：https://db4agent.cn

在最近的交流中，看到过一个现象：一个员工只有一个 API Key，它代表一个 Agent？真不一定，可能是好几个 Agent 都使用的这个 Key；而有时候一个 Key 还会被多个人共用。

快速接入的时候确实方便。但真要进企业治理层面，这种做法根本回答不了几个基本问题：这个 Key 属于谁？是不是被好几个人 / Agent 共享了？它能代表 Agent 可以访问哪些数据？失效了以后还有没有别的 Key 能继续跑？

Agent 进企业生产以后，需要的不是一串认证字符串，而是一个独立、可追踪、可撤销的身份。

一、Agent 身份该包含什么

打个比方——Agent 的身份就像员工的工牌。

工牌上有什么？姓名、工号、部门、岗位、职级、有效期、可通行区域、照片。不是给你一个名字就完了。

Agent 身份也类似，至少要关联这些：唯一标识、负责人、组织归属、用途、数据分类、运行环境、允许的 Skill 和 Tool、模型配置、有效期、状态、部署记录。

而且人的账号、组织人员和 Human Principal 也要保持对应关系。在“川序”中，人的账号需要在组织架构之下，一个人可以拥有多个 Agent，而 Agent 只能属于一个人。这样当组织关系变化或人员离职时，平台才能自动判断哪些 Agent 需要复核——而不是靠某个运维人员记得去更新一张随时过期的表格。

二、注册不等于自动获得权限

在通过平台申请并创建 Agent 以外，为了满足更多的 Agent运行场景，“川序”保留外部 Agent 通过 Skill-first 注册的能力。但注册只解决两件事——“它是谁"和"它从哪来”。不自动授予更大的数据访问范围。（平台可以把外部 Agent 注册的功能设置为关闭、仅审批或开启，由企业根据实际环境选）

创建业务 Agent 的时候，授权人员得提交一整套信息：负责人、用途、模板、密级、模型、运行目标、隔离级别、能力理由。而且一般情况下申请人不能批准自己的申请——这是底线。审批完成之后平台才会创建独立的受限 Agent Principal 和部署记录。

平台原生的 Admin Agent 也不等于人类的 admin 用户。它是独立的系统身份，不该拿着 Schema Owner 回退权限到处跑。身份分离不是故意加流程折腾人，而是避免一个账号同时扛所有责任，否则出现任何问题谁都查不清。

三、身份、凭证和会话必须分三层

这是我觉得最容易被人忽略的一点。

很多人把 Principal、部署实例和短期令牌混成一个永久 API Key。但这三者的生命周期完全不同：Agent Principal 是长期的责任对象（就像工牌本身）；部署实例是它的一次运行载体（像工牌的一次刷卡记录）；短期令牌是一次访问会话（像闸机放行的那几秒）。

Principal 被暂停时，可以撤销该 Agent 的所有令牌并给运行实例设置围栏。单个实例异常时，可以只回收那个实例的本地会话，不影响别的节点。

配置文件里的 LLM URL、模型 ID 和 API Key 这些敏感信息也不该当普通文本随便读，需要被加密并定期轮换加密 Key。平台应保存加密配置和版本，平台的 Dashboard 页面只展示来源、状态和摘要。运行时按最小权限取得短期使用凭证，读写变更全记审计。API Key 留空的模型配置也要明确标为"无凭证模式"，不能被当成"平台已经验过了"。

四、注册 Token 怎么不变成后门

在“川序”中，注册外部 Agent 时会要求生成一个有时效性一次性 Token，它用于首次归属绑定。但它必须有明确的生成者、目标 Agent 或申请单、有效期和状态。

注册请求到了，服务端在事务里验证 Token，建立 Agent Principal 和 Human Principal（或组织）的归属关系，然后立即把 Token 标记为“已使用”。用完即废。

注册完后的调用不能再走管理员 Token。平台应使用 Agent 自身凭证完成 Gateway 激活证明，每次请求都重新检查状态、权限和有效期。说白了——“允许注册”和“允许运行”是两回事，得分开控制。

这三个层次也对应不同的处置动作：Principal 被禁用，所有新会话都被拒绝；单个部署实例异常，只回收该实例的本地会话；短期凭证过期，只需重新走一次合法激活流程。

如果三者混成一个 API Key，管理员就没法缩小处置范围，只能选“全关”或者“忍着”。（这跟安全边界是一个道理，详见《AI Agent 的安全边界不能是提示词》）

在“川序”中身份记录还和数据库用户边界对应。Oracle 的管理身份可以用受控管理凭证，但 Business Agent 必须用独立的 End User 或独立用户。PostgreSQL 和 YashanDB 也一样——独立登录角色，服务端授权。平台不能把“Agent 有自己的平台 ID”当作“数据库已经做完权限隔离了”。

五、身份让处置成为可能

有独立身份，企业才能对单个 Agent 做这些事：暂停、撤销令牌、终止会话、限制 Skill、调整运行范围、保留审计证据——而不必把整个系统都关掉。

Agent 的“身份证”不是为了给它拟人化（它又不是真的人），而是为了让企业在面对真实数据和真实操作时，能搞清楚谁在行动、依据什么行动、怎么停止行动。

这在生命周期管理中是核心前提——此前在《Agent 上线之后，谁来负责它》里聊过，Agent 得走完一条完整生命周期，而身份就是这条链路的起点。

六、如何验证身份认证能力

使用“川序”，可以用六个用例来检查身份实现到底靠不靠谱：

1. 新用户注册后只能进规定的入口
2. 管理员创建业务 Agent 时必须指定负责人
3. 申请人不能批准自己的 Agent
4. Business Agent 请求 Schema Owner 级别的数据（如强行要求查看其他 Agent 的数据或所有数据）时必须 fail-close
5. 撤销 Agent 凭证后旧会话调不动
6. 负责人组织关系变更后相关 Agent 进入待复核列表

这些用例不能只从一个入口测。得从 Dashboard、Portal、HTTP、MCP 和 Skill 入口分别跑一遍。

页面看不到按钮但直接接口仍然成功？那说明只是 UI 隐藏，不是授权完成。一个数据库版本能过但另一个只能靠应用层判断？得记为适配差异，不能宣传为“完全对等”。

七、身份治理带来的组织变化

Agent 的身份一旦成为数据库里的事实，企业的 Agent 管理就不再依赖某个技术人员“记住所有 Key”了。

管理员可以按组织、负责人、安全域和状态检索。审计人员可以按主体回放操作。业务负责人能看到自己负责的 Agent。应急人员只能处理被授权范围内的运行。

这也意味着身份数据得纳入企业变更流程。人员离职、部门合并、项目结束、数据库账号轮换——都可能触发 Agent 重新审批。平台可以自动生成待复核清单，但不能在没有企业策略的情况下擅自把 Agent 甩给另一个负责人。

总结

“川序” AI Agent 管理平台给了每个 Agent 一个可以查证的“身份证”。

老规矩，知道写了些啥。