数据库管理459期 2026-08-12胖头鱼的技术专栏-459 Agent 也需要“身份证”20260812一、Agent 身份该包含什么二、注册不等于自动获得权限三、身份、凭证和会话必须分三层四、注册 Token 怎么不变成后门五、身份让处置成为可能六、如何验证身份认证能力七、身份治理带来的组织变化总结胖头鱼的技术专栏-459 Agent 也需要“身份证”20260812作者胖头鱼的鱼缸尹海文 Oracle ACE Pro: Database PostgreSQL ACE 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVPITPUB认证专家 圈内拥有“总监”称号非著名社恐社交恐怖分子 全网同名胖头鱼的鱼缸 ITPUByhw1809 除授权转载并标明出处外均为“非法”抄袭本期继续“川序”的介绍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 得走完一条完整生命周期而身份就是这条链路的起点。六、如何验证身份认证能力使用“川序”可以用六个用例来检查身份实现到底靠不靠谱新用户注册后只能进规定的入口管理员创建业务 Agent 时必须指定负责人申请人不能批准自己的 AgentBusiness Agent 请求 Schema Owner 级别的数据如强行要求查看其他 Agent 的数据或所有数据时必须 fail-close撤销 Agent 凭证后旧会话调不动负责人组织关系变更后相关 Agent 进入待复核列表这些用例不能只从一个入口测。得从 Dashboard、Portal、HTTP、MCP 和 Skill 入口分别跑一遍。页面看不到按钮但直接接口仍然成功那说明只是 UI 隐藏不是授权完成。一个数据库版本能过但另一个只能靠应用层判断得记为适配差异不能宣传为“完全对等”。七、身份治理带来的组织变化Agent 的身份一旦成为数据库里的事实企业的 Agent 管理就不再依赖某个技术人员“记住所有 Key”了。管理员可以按组织、负责人、安全域和状态检索。审计人员可以按主体回放操作。业务负责人能看到自己负责的 Agent。应急人员只能处理被授权范围内的运行。这也意味着身份数据得纳入企业变更流程。人员离职、部门合并、项目结束、数据库账号轮换——都可能触发 Agent 重新审批。平台可以自动生成待复核清单但不能在没有企业策略的情况下擅自把 Agent 甩给另一个负责人。总结“川序” AI Agent 管理平台给了每个 Agent 一个可以查证的“身份证”。老规矩知道写了些啥。