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

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE

10年+数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）

全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭


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

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

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 留空的模型配置也要明确标为"无凭证模式"，不能被当成"平台已经验过了"。

在“川序”中，注册外部 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 得走完一条完整生命周期，而身份就是这条链路的起点。

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

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

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

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

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

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

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

Agent 也需要“身份证”

自由职业

人工智能

数据库

职业发展

Agent身份管理需区分Principal、部署实例与短期令牌，实现独立可追踪可撤销的身份。注册不等于授权，需严格审批流程，身份分离避免权限混乱。通过暂停、撤销令牌等操作实现精准处置，确保企业治理透明可控。

PostgreSQL

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

Agent 也需要“身份证”

Agent 也需要“身份证”

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐