场景：AI 编码 Agent 要调用 API 时，你的密钥安全吗？AuthSec 给每个 Agent 一个「身份」

问题：Agent 有权限，但人没有安全感

当你的 Claude Code 或 Codex 需要调用内部 API、查询数据库、或者向第三方服务提交请求时，通常会用一个通用 API Key 来解决。这个 Key 被写进 .env、CLAUDE.md 或者直接硬编码在 Agent 的指令里。

结果是：谁拿了 Key 谁就能用，Agent 之间没有身份隔离，审计日志一片空白。

具体来说：

• 凭证共享：多个 Agent 用同一个 API Key，你无法区分哪个 Agent 调了哪个接口
• 无权限边界：一个只负责代码审查的 Agent 意外获得了写入生产数据库的权限
• 密钥泄露无溯源：Key 被泄露后，你根本不知道从哪个环节流出去的
• Agent 重启后重新认证：会话级别的令牌在 Agent 重启后丢失，每次都要重新配置

这个问题在 AI 编码 Agent 进入生产环境后会急剧放大。多个 Agent 并行工作、跨仓库操作、调度到云资源——没有一个统一的身份层，安全管理就是一团乱麻。

AuthSec：给每个 Agent 发一张「身份证」

AuthSec 是一个用 Go 编写的统一身份与访问管理（IAM）服务，专门为 AI Agent 场景设计。它不是一个通用的 OAuth 服务器——它的 API 路由模块直接面向 Agent 的身份生命周期设计。

核心能力一览：

快速上手：启动 AuthSec 服务

AuthSec 以单一二进制发布，依赖 PostgreSQL：

git clone https://github.com/authsec-ai/authsec-ai.git
cd authsec-ai
cp .env.example .env

export DB_NAME=authsec_db
export DB_USER=authsec
export DB_PASSWORD=changeme
export DB_HOST=localhost
export DB_PORT=5432

go build -o authsec ./cmd/
./authsec

服务默认运行在 7468 端口。启动后，健康检查确认一切正常：

curl http://localhost:7468/authsec/uflow/health

预期响应：

{"status": "healthy", "database": "connected", "timestamp": "2026-07-02T06:30:00Z"}

场景一：为 Claude Code 创建专用的 Agent 身份

假设你有一个 Claude Code 实例负责代码审查工作，另一个负责 CI/CD 部署。它们需要的权限完全不同。

1. 注册第一个管理员

curl -X POST http://localhost:7468/authsec/uflow/auth/admin/login/bootstrap \
  -H "Content-Type: application/json" \
  -d '{"email": "admin@team.dev", "password": "temp-password-123"}'

2. 创建项目和 OAuth 客户端

curl -X POST http://localhost:7468/authsec/uflow/auth/admin/login \
  -H "Content-Type: application/json" \
  -d '{"email": "admin@team.dev", "password": "temp-password-123"}'

curl -X POST http://localhost:7468/authsec/uflow/admin/projects \
  -H "Authorization: Bearer $(ADMIN_TOKEN)" \
  -H "Content-Type: application/json" \
  -d '{"name": "Code Review Agent"}'

curl -X POST http://localhost:7468/authsec/clientms/tenants/{tenantId}/clients/create \
  -H "Authorization: Bearer $(ADMIN_TOKEN)" \
  -H "Content-Type: application/json" \
  -d '{"client_name": "claude-code-review", "grant_types": ["client_credentials"]}'

场景二：用 CIBA 实现 Agent 操作的「人在回路」审批

有时候 Agent 需要执行高风险操作（比如修改生产环境配置或触发数据库迁移）。AuthSec 支持 CIBA（Client Initiated Backchannel Authentication）——Agent 发起操作请求，通过推送通知等待用户批准，用户批准后 Agent 才能拿到令牌继续执行。

curl -X POST http://localhost:7468/authsec/uflow/auth/ciba/initiate \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "claude-code-review",
    "scope": "write:production"
  }'

curl -X POST http://localhost:7468/authsec/uflow/auth/ciba/token \
  -H "Content-Type: application/json" \
  -d '{"auth_req_id": "abc123", "client_id": "claude-code-review"}'

用户侧会收到推送通知（通过已注册的设备），确认或拒绝后，Agent 的轮询请求才会返回访问令牌。

这个流程特别适合以下场景：

• Agent 写了一个数据库 migration 脚本，需要人工确认后才能执行
• Agent 要修改生产环境的 IAM 策略
• Agent 要向外部 API 提交更改（比如发布到 npm 或 PyPI）

场景三：用 SPIFFE/SPIRE 实现 Agent 工作负载身份

对于运行在 Kubernetes 或云 VM 上的 Agent 进程，AuthSec 的 SPIRE Headless 模块提供了 SPIFFE 工作负载身份支持。每个 Agent 进程获得一个唯一的 SPIFFE ID（如 spiffe://team.dev/agent/claude-code-review），基于这个 ID 签发 JWT-SVID，无需任何 API Key 文件。

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│  Claude Code    │────▶│  SPIRE Agent     │────▶│  AuthSec        │
│  (Workload)     │     │  (Workload API)  │     │  (/spire/*)     │
└─────────────────┘     └──────────────────┘     └─────────────────┘
       │                                                │
       │  HTTPS + JWT-SVID                               │  Policy Check
       ▼                                                ▼
┌─────────────────┐                           ┌─────────────────┐
│  Internal API   │                           │  PostgreSQL     │
│  (验证 SVID)     │                           │  (RBAC 表)      │
└─────────────────┘                           └─────────────────┘

SPIRE Headless 模块的 OIDC 令牌端点可以签发与云厂商 Federation（AWS STS、Azure AD、GCP Access Token）交换的令牌：

curl -X POST http://localhost:7468/authsec/spire/oidc/exchange/aws \
  -H "Content-Type: application/json" \
  -d '{"svid": "spiffe://team.dev/agent/claude-code-review", "role_arn": "arn:aws:iam::123456:role/agent-readonly"}'

这意味着 Agent 无需任何长期凭证文件，就能以最小权限原则访问云资源。

架构设计

AuthSec 采用单二进制 + 可选插件的架构：

• 核心服务（authsec）：单一 Go 二进制，Gin 框架，默认端口 7468
• 数据库：PostgreSQL（必需），存储用户、角色、权限、审计日志
• HashiCorp Vault（可选）：托管 OIDC 提供商凭据和外部服务密钥
• Redis（可选）：缓存会话和权限数据
• mt-plugin（可选）：gRPC 微服务，提供多租户数据库隔离

所有 API 路由按模块划分前缀：

为什么这比传统的 API Key 方案更好

小结

当 AI 编码 Agent 从实验性工具升级为关键的日常生产力工具时，身份和访问管理不是一个可选项——它是 Agent 进入生产环境的必要条件。

AuthSec 提供了一个从基础到高级的完整 IAM 方案：从最基本的 client_credentials 客户端认证，到 CIBA 推送式审批、SPIFFE 工作负载身份、还有云平台 Federation。关键是它用 Go 写成一个单一二进制，部署和维护成本极低，但提供了企业级的功能覆盖范围。

对于那些已经在 Kubernetes 上运行 Claude Code、Codex 或者 OpenCode 的团队，AuthSec 的 SPIRE 集成可以直接与现有基础设施对接，让 Agent 用 SPIFFE ID 替代所有静态 API Key。

相关链接

• AuthSec GitHub 仓库
• SPIFFE/SPIRE 标准
• OAuth 2.0 CIBA Flow
• RFC 8628 设备授权