AI 编码 Agent 到处用共享 API Key？Clay Seal 给每个 Agent 一个加密身份证，让系统知道「谁在调用」

问题：Agent 在系统里是「匿名」的

当 Claude Code 调用你的生产数据库、Codex 操作你的 GitHub、或者一个多 Agent 编排中的子任务访问你的内部 API——你的系统知道这是谁在调用吗？

现实很残酷：绝大多数 AI 编码 Agent 使用共享 API Key、无持有者绑定的 Bearer Token、或者干脆只靠 Prompt 里的一个名字字符串来标识自己。这意味着：

• 一个 Agent 会话盗用的 Token 可以在另一台机器上重放（Token 没有与持有者绑定）
• 同一服务里混入了来自不同 Agent 的请求，日志里分不清哪个操作来自哪个会话
• 子 Agent 继承了父 Agent 的全部权限，即使它只需要读取一个文件
• 出了问题只能查到「这个 Token 调用了 API」，查不到「哪个任务的哪个 Agent 在什么时候做了什么」

现有方案的局限性

Clay Seal Identity 的目标很简单：给每个 Agent 运行实例一个短期的、可加密验证的身份，让下游系统不依赖中心化服务就能确认「谁在调用」。

Clay Seal Identity 是什么

Clay Seal Identity 是一个开源的 Python 库（MIT 协议），为 AI Agent 提供基于 SPIFFE 标准的加密身份凭证。它不是一个新的认证协议，而是把 SPIFFE（Secure Production Identity Framework for Everyone）中成熟的工作负载身份模型适配到 AI Agent 场景。

核心能力：

• SPIFFE JWT-SVID 凭证：每个 Agent 运行实例获得一个短期（通常几分钟到几小时）的 JWT 凭证，sub 字段包含 SPIFFE ID
• Ed25519 持有者密钥：Token 与 Agent 的私钥绑定，被盗的 Token 无法在其他机器上重放
• 离线验证：不需要回拨认证服务，任何持有 JWKS 的服务端都可以离线验证 Token 有效性
• Biscuit 能力令牌：支持权限衰减，子 Agent 自动继承父 Agent 权限的子集
• FastAPI 身份服务：可选托管的身份签发服务，开箱即用

快速上手

安装

pip install clayseal-identity

如果需要运行内置的 FastAPI 身份服务：

pip install "clayseal-identity[server]"

给 Agent 签发身份

from clayseal.identity import ClaySeal

auth = ClaySeal(base_url="http://localhost:8000", api_key="sk-...")

session = auth.identify(
    agent_type="coding-agent",
    owner="alice@example.com",
    scopes=["db:read", "repo:write"],
    ttl_seconds=3600,
)
token = session.token

检查 Token 内容

from clayseal.identity import inspect_token

inspection = inspect_token(token)
print("\n".join(inspection.summary_lines()))

在服务端验证 Token

from fastapi import Depends, FastAPI
from clayseal.identity.integrations.fastapi import AgentIdentityVerifier

app = FastAPI()
require_agent = AgentIdentityVerifier.dependency(
    jwks=tenant_jwks,
    issuer="clayseal.io",
    audience="tools-api",
)

@app.post("/tool")
def tool(identity=Depends(require_agent)):
    return {"agent_id": identity.agent_id, "agent_type": identity.agent_type}

保护 MCP 服务器

如果 Agent 通过 MCP 协议访问你的工具，Clay Seal 提供了开箱即用的 MCP 集成：

from mcp.server.fastmcp import FastMCP
from clayseal.identity.integrations.mcp_server import (
    ClaySealTokenVerifier, ToolGuard, build_auth_settings,
)

verifier = ClaySealTokenVerifier(
    jwks=tenant_jwks,
    issuer="clayseal.io",
    audience=tenant_id,
)

guard = ToolGuard(
    biscuit_root_public_key=tenant_root_public_hex,
    server_url="https://tools.example.com/mcp",
)

mcp = FastMCP("tools", token_verifier=verifier, auth=build_auth_settings(...))

@mcp.tool()
@guard.require()
def search_web(query: str) -> str: ...

这个集成的关键点在于：Agent 每次工具调用都附带 Clay Seal 凭证，MCP 服务器在执行业务逻辑之前先验证身份，确认这是授权 Agent 发起的请求。

分层设计：不止于身份

Clay Seal 的设计分为三层，身份只是第一层：

L1 身份层没有 L2/L3 的依赖——它独立可用。对于大多数开发者来说，先给 Agent 加上可验证的身份凭证，就已经能从日志中区分「谁做了什么」，为后续的精细化权限控制打下基础。

真实场景

场景 1：多 Agent 访问同一数据库

你有一个编排 Agent 和三个工作 Agent 同时操作同一个 PostgreSQL 数据库。没有身份凭证时，数据库日志里三条连接都显示同一个用户名。有了 Clay Seal，每个 Agent 带着自己的 SPIFFE ID 访问：

Agent A (spiffe://team/agent/worker-1) → SELECT orders
Agent B (spiffe://team/agent/worker-2) → SELECT customers  
Agent C (spiffe://team/agent/worker-3) → INSERT payments

出问题时，直接查到是 worker-3 的支付操作，而非「某个 Agent 干的」。

场景 2：MCP 工具鉴权

你的团队内部运行着 10 多个 MCP 服务器（数据库查询、文件搜索、代码审查等）。没有身份层的情况下，任何能连上 MCP 端点的客户端都可以调用。Clay Seal 让 MCP 服务器只接受携带有效 Clay Seal 凭证的请求，并且可以根据凭证中的 SPIFFE ID 做细粒度的工具级授权。

注意事项

• Clay Seal Identity 不是完整的沙箱。它解决的是「谁在调用」的问题，而不是「调用能做什么」。运行时权限收缩和异常行为检测在 L2 中实现。
• Token 撤销需要在线验证。对于需要即时撤销的场景，使用服务端在线验证而非纯离线 JWT 验证。
• 项目目前处于早期阶段（GitHub 6⭐），但 SPIFFE 标准本身是成熟的云原生身份框架，已被 Kubernetes、Istio 等广泛采用。身份层的概念验证是可靠的。

总结

AI 编码 Agent 正在获得越来越多的系统权限——GitHub Token、云服务凭证、生产数据库访问。如果这些 Agent 在系统中是「匿名」的，安全事件响应和责任追溯就会变得几乎不可能。

Clay Seal Identity 给出的方案很直接：用成熟的 SPIFFE 标准给每个 Agent 实例一个加密身份凭证。它不重新发明轮子，而是把云原生基础设施中已验证的身份模型应用到 AI Agent 场景。对于已经在运行多个 AI 编码 Agent 的团队，这是安全体系中最基础但也最容易被忽略的一环。

相关链接

• GitHub: clayseal/clayseal-identity
• PyPI: clayseal-identity
• Clay Seal 官网
• SPIFFE 标准