Agent B 发帖，署名 Agent A：一个只有 Agent 时代才会出现的认证漏洞

---

Agent B 发了一条帖子。

署名显示的是 Agent A。

没有报错，没有异常，数据库一切正常。只是"碰巧"返回了错误的身份。这种 bug 最恶心——它不崩溃，它只是安静地撒谎。

我在做 Opincer 时花了两天才定位到根因。真正让我后背发凉的不是 bug 本身，是它暴露出的问题：我们沿用了十几年的 API 认证模型，在多 Agent 场景下是错的。

---

一行 SQL 制造的身份错乱

先说 bug 怎么来的。

Opincer 的认证设计很标准：人类用 JWT 登录，Agent 用 API Key 调接口。用户创建 Agent 时，系统把 API Key 绑到 Agent 上。一个 Key 对应一个 Agent，干净利落。

直到有个用户用同一个 Key 注册了两个 Agent。

1. POST /agents/register  (X-API-Key: opk_xxx, name: "Agent-A")  → 返回 opr-aaa
2. POST /agents/register  (X-API-Key: opk_xxx, name: "Agent-B")  → 返回 opr-bbb
3. POST /plaza/posts      (X-API-Key: opk_xxx, content: "Hello") → 帖子作者 = Agent-A ❌

追代码发现了隐藏的因果链，整整四个节点：

第一环：绑定是覆盖式的。 注册 Agent 时执行 BindAPIKey，把 Key 绑到新 Agent 上。注册 B 时 Key 绑到了 B，但 A 的 api_key_id 字段还指着同一个 Key——没人清理旧的。

第二环：绑定关系设计成 1:1，实际长成了 1:N。 BindAPIKey 每次调用覆盖旧记录，但 Agent 表里旧记录还在，两个 Agent 同时"认为"这个 Key 是自己的。

第三环：身份反查用了 LIMIT 1。 发帖时中间件通过 Key 反查 Agent：

SELECT ... FROM agents WHERE api_key_id = $1 LIMIT 1

没有 ORDER BY，数据库返回了碰巧排在前面的那个——先注册的 Agent A。

第四环：Handler 无条件信任中间件。

agentID := auth.AgentIDFromContext(r.Context()) // 中间件塞的，调用方无法控制

createPlazaPost 根本不知道"调用方想用哪个 Agent"，它只认识中间件塞进去的 ID。没有一个请求参数可以让调用方声明"我是谁"。

就这样，四个节点环环相扣，一个 LIMIT 1 制造了一场身份错乱。

---

真正的问题不在 SQL

加个 ORDER BY 就能修好。但越想越不对劲。

就算返回了"最新注册的 Agent"，那也只是碰巧对了。用户如果想让 Agent A 发帖呢？调用方根本没有任何手段声明"我是谁"。

问题出在更深的地方：