AI Agent 调用 MCP/API，怎样证明请求来自正确身份？拆解 Arken 的签名认证核心
给 Agent 一把长期有效的 API Key，接入越多服务，泄露后的影响面就越大；把密钥放进代理或环境变量，也只是改变了保管位置，并没有回答服务端如何验证调用者身份。ArkenForge 的 arken-core 尝试用公钥身份和逐请求签名解决这个问题：服务端发出一次性挑战，Agent 用私钥签名后重试，验证方据此识别 did:key 身份。它值得关注的不是“彻底消灭凭据”，而是把长期共享秘密替换成可验证的签名流程。
一次请求如何完成身份验证
项目 README 描述的流程由挑战、签名、验证三部分构成：客户端访问受保护资源，服务端以 401 返回 nonce 和 statement；客户端用 secp256k1 私钥对挑战签名，再通过 Authorization: Signature 请求；验证成功后，服务端返回对应的 did:key。挑战 nonce 有 60 秒 TTL，降低旧请求被重放的机会。
客户端 服务端 | ---- GET /protected ------> | | <--- 401 + nonce/statement | | | 验证签名、nonce | -- Authorization: Signature ->| | <--- 200 + did:key -------- |
did:key 是从密钥对派生的标识。同一把密钥在不同集成中得到同一身份，服务端不需要把共享密码发给 Agent。签名证明的是请求方持有对应私钥，不代表它天然有权访问所有资源；授权策略、密钥轮换、私钥保护仍要由集成方设计。把认证和授权混为一谈，会高估这类方案能提供的安全边界。
arken-core 当前提供什么
这是 ArkenForge 生态的 Rust 加密核心，不是完整的 MCP 网关或可直接部署的认证服务。README 列出三项 C 兼容导出函数：generate_challenge_into、verify_request_into 和 verify_signature_only_into。函数把 JSON 写入调用方缓冲区，返回写入字节数；缓冲区不足时返回 -1。更高层的中间件、客户端 SDK 和 MCP 集成属于生态中的其他组件，不能仅凭核心库的函数清单就推断其已可用或生产就绪。
int generate_challenge_into(const char *statement, char *out, int cap); int verify_request_into(const char *header, char *out, int cap); int verify_signature_only_into(const char *header, char *out, int cap);
仓库给出的构建方式要求安装 Rust 工具链：
cd rust cargo build --release
构建会生成平台对应的共享库（.dylib、.so 或 .dll），供上层通过 FFI 调用。当前 README 明确标注项目尚未达到生产就绪状态，并指出 nonce 仅存于内存：进程重启会丢失挑战状态，多实例间也无法自然共享；目前没有密钥恢复机制，私钥丢失意味着身份无法继续使用。预编译二进制仍在路线图上，因此把它当成即插即用的生产认证设施并不合适。
适用场景与落地前的检查
对正在设计 Agent 工具链的团队，这种模式适合先作为架构评估对象：如果多个服务需要确认“请求由哪个 Agent 密钥签署”，可研究签名身份如何接入现有认证中间件，而不必把长期 API 密钥直接交给 Agent。落地前应逐项确认：挑战是否一次性消费、nonce 存储是否支持多实例、statement 是否绑定方法和资源、代理是否会校验重放、密钥如何轮换和吊销，以及授权规则在哪里执行。README 已说明 nonce 的内存限制，其他部署语义需以具体集成组件的文档和源码为准，不能从概念流程自行补全。
私钥仍是关键资产：应由可信执行环境或受控密钥存储保护，避免写进提示词、日志和普通配置文件。服务端还需要限流和挑战过期处理，防止攻击者利用大量挑战占用资源。安全测试应覆盖错误签名、过期 nonce、重复 nonce、错误 DID 编码、缓冲区边界和多实例一致性。尤其是 nonce 重放与签名绕过，项目自己的安全策略也将它们列为关注范围。
结语
Arken 的思路清晰：以签名挑战替代共享密码式的 Agent 身份凭据，并把加密验证封装在 Rust 核心中。但当前仓库是早期组件，内存 nonce、无密钥恢复、需本地构建等限制都是真实的工程约束。它适合帮助团队讨论 Agent 身份、请求证明和授权边界，不应被包装成已经成熟的生产方案。先验证完整协议和集成层，再决定是否引入，比只看“无密码”口号更可靠。