如何给AI Agent一个稳定身份Agent Substrate MintJWT与MintCert实战【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrateAgent Substrate 是一个为 AI Agent 打造的、默认安全secure-by-default的执行运行时能把成百上千个 Agent称为 Actor高密度地复用在一组物理 Worker 上。当 Agent 被挂起、恢复甚至跨节点迁移时它的身份必须保持不变。本文将带你读懂负责稳定身份签发的两个核心接口MintJWT 与 MintCert以及谁有权限调用它们。为什么 AI Agent 需要稳定身份Agent Substrate 的核心思想是把大量逻辑 Actor映射到少量物理 WorkerAgent 大部分时间处于空闲系统随时可以把它们从一台 Worker 挂起、再在另一台 Worker 上恢复官方标称恢复延迟低于 500ms恢复速率超过 500 次/秒。这就带来一个身份难题Pod 身份是临时的Agent 跑在哪个 Kubernetes Pod 里、IP 是多少、Pod 的临时凭据是什么都会随迁移而改变。下游服务需要认得出你是谁Agent 访问外部 API 时网关、业务系统需要知道它对应的是哪个逻辑 Agent而不是某个转瞬即逝的容器。因此 Substrate 引入了Actor 稳定身份无论 Agent 被传送到哪台机器它对外出示的凭据始终指向同一个逻辑身份——atespace actor 名称。签发这些凭据的正是ateapi控制平面上的两个 RPCMintActorJWT文档中常称 MintJWT和MintActorCertificate文档中常称 MintCert定义在 pkg/proto/ateapipb/ateapi.proto。30 秒速览两个签发接口做什么接口产物典型用途MintJWT一个 OIDC 兼容的 JWT出站请求时由 egress 网关为 Agent 注入身份头下游按标准 OIDC 方式校验MintCert一张带 SPIFFE 地址的 mTLS 客户端证书签署 CSRAgent 与 egress 网关之间建立双向 TLS网关凭证书认出是哪个 Actor两者都用atespaceactor 名称标识 Agent与 API 其他接口完全一致。详细说明见 docs/api-guide.md 的 Actor Identity Credentials 章节。MintJWT给 AI Agent 签一个标准 JWT调用MintActorJWT时请求里需要带上 Actor 的引用、Actor UID防止删除后同名重建的换票攻击和至少一个受众audience最多 16 个——定义见 pkg/proto/ateapipb/ateapi.proto。签出的 JWT 是一个OIDC Discovery 兼容的令牌携带以下声明见 pkg/proto/ateapipb/ateapi.protoiss签发者一个可以拉取 OIDC 发现文档的 URLsub主题格式为atespaces:${atespace}:actors:${actorname}——这就是 Agent 的身份证号aud受众令牌被绑定到具体服务不能随便乱用nbf/exp/iat标准时间声明令牌天然有有效期ate.devSubstrate 扩展段含atespace与actorName。典型调用方是egress 网关当某个 Actor 配置了出站请求注入 JWT策略时网关在转发前调用 MintJWT把短期身份令牌附在出站流量上下游 API 无需了解 Substrate 内部细节只需按 OIDC 规范验签。MintCert给 AI Agent 签一张 mTLS 证书MintActorCertificate接收一张 DER 编码的CSR证书签名请求——签名方只从中提取公钥其余内容一律忽略——外加一个用途purpose字段用来区分Agent 本人在行动和系统组件代表 Agent 行动。请求/响应定义见 pkg/proto/ateapipb/ateapi.proto。签出的叶子证书携带SPIFFE URI作为身份spiffe://substrate-actor.local/atespace/atespace/actor/actor_name响应返回 DER 编码的证书链叶子在前、中间证书跟随实际寿命为 1 小时由ateapi内部的本地 CA 池签发CA 实现见 internal/localca/localca.goActor 身份扩展字段写入逻辑见 internal/substratex509/substratex509.go。它有两个实际用途atunnel 通道节点上的 atelet 为 Actor 申请证书用于与 egress 网关通信客户端证书注入出站请求配置了注入 Actor 客户端证书策略时由 egress 网关调用。最终egress 网关会拿着证书里的 SPIFFE 身份反查控制平面确认这个 Actor 确实存在且在运行——这个双因素验证流程可以在 internal/e2e/suites/egressauthz/actoridentity_test.go 的端到端测试里看到完整示例。谁能调用 MintJWT 与 MintCert三重护栏 关键设计Actor 自己不能直接调用这两个 RPC。必须由节点监督者atelet通过 mTLS Pod 证书来调用且必须同时满足三个条件详见 docs/api-guide.md调用方证书身份是atelet服务账号spiffe://cluster.local/ns/ate-system/sa/atelet并携带 Pod Identity 扩展把它钉死在某一台节点上目标 Actor 在 Actor 数据库中当前处于运行状态承载该 Actor 的 Worker Pod 与调用它的 atelet在同一节点且仍分配给该 Actor。这意味着每台节点上的 atelet 只能为自己机器上正在跑的 Actor签发凭据无法越权。两条错误处理也值得学习任一检查失败返回PERMISSION_DENIED且不带任何细节——接口不能被人用来探测某个 Actor 存不存在、跑在哪台机器Actor 存在但处于挂起/暂停/崩溃状态则返回FAILED_PRECONDITION。另外配置 docs/authentication.md 中的actorIdentityJWTProvider可以指定哪个 JWT 提供商的用户被允许调用 ActorIdentity.MintJWT进一步收窄签发入口。实战三步让你的 Agent 带着稳定身份出站以下是最小可跑的本地环境路径Kind 集群搭环境按 README.md 的 Quickstart 执行hack/create-kind-cluster.sh与hack/install-ate-kind.sh --deploy-ate-system再部署 Counter 演示--deploy-demo-counter。创建 Actorkubectl ate create actor my-counter-1 -a ate-demo-counter --template counterCLI 完整文档见 cmd/kubectl-ate/README.md。Actor 被调度到某个 Worker 进入 RUNNING 状态后就具备了被签发凭据的资格。出站带身份为 Actor 配置 egress 策略后出站流量经网关自动完成 MintJWT / 客户端证书注入网关侧的信任链校验与 MITM 拦截配置可参考 docs/egress-trust-bundle.md。对新手来说记住一句话即可身份跟着逻辑 Actor走不跟着 Pod 走签发权被牢牢锁在Actor 当前所在节点的 atelet 手里。相关文档与源码速查 资料路径API 完整指南含 Actor Identity 章节docs/api-guide.mdate-api 认证配置JWT 提供商docs/authentication.md威胁模型信任边界与假设docs/threat-model.md服务与消息定义gRPC/Protobufpkg/proto/ateapipb/ateapi.proto控制平面实现Mint 逻辑cmd/ateapi/internal/controlapi/actor.go本地 CA 池internal/localca/localca.go证书凭据包key chain 的 PEM 约定internal/credbundle/credbundle.goatunnel 凭据获取internal/atunnel/credential.go端到端验证egress 身份internal/e2e/suites/egressauthz/actoridentity_test.go常见问题 FAQ为什么不让 Actor 自己签身份因为零信任假设下沙箱内进程不可信。签发权收敛到节点级 atelet 且受同节点 运行中 已分配三重约束把伪造身份的窗口压到最小。Actor 迁移后已签发的凭据还有效吗凭据本身有短有效期证书约 1 小时过期后由新所在节点的 atelet 重新签发由于 sub / SPIFFE URI 只编码逻辑身份atespace 名称换机器不换身份。下游系统如何验证这个身份JWT 走标准 OIDC Discovery 流程验证iss/aud/签名mTLS 证书则由网关校验证书链并反查控制平面确认 Actor 正在运行两条路径互为补充。掌握 MintJWT 与 MintCert你就理解了 Agent Substrate 如何在百万级沙箱高密度复用的架构里给每一个 AI Agent 发一张随迁移不变、天然短效、可被标准协议校验的身份证。【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何给AI Agent一个稳定身份：Agent Substrate MintJWT与MintCert实战
如何给AI Agent一个稳定身份Agent Substrate MintJWT与MintCert实战【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrateAgent Substrate 是一个为 AI Agent 打造的、默认安全secure-by-default的执行运行时能把成百上千个 Agent称为 Actor高密度地复用在一组物理 Worker 上。当 Agent 被挂起、恢复甚至跨节点迁移时它的身份必须保持不变。本文将带你读懂负责稳定身份签发的两个核心接口MintJWT 与 MintCert以及谁有权限调用它们。为什么 AI Agent 需要稳定身份Agent Substrate 的核心思想是把大量逻辑 Actor映射到少量物理 WorkerAgent 大部分时间处于空闲系统随时可以把它们从一台 Worker 挂起、再在另一台 Worker 上恢复官方标称恢复延迟低于 500ms恢复速率超过 500 次/秒。这就带来一个身份难题Pod 身份是临时的Agent 跑在哪个 Kubernetes Pod 里、IP 是多少、Pod 的临时凭据是什么都会随迁移而改变。下游服务需要认得出你是谁Agent 访问外部 API 时网关、业务系统需要知道它对应的是哪个逻辑 Agent而不是某个转瞬即逝的容器。因此 Substrate 引入了Actor 稳定身份无论 Agent 被传送到哪台机器它对外出示的凭据始终指向同一个逻辑身份——atespace actor 名称。签发这些凭据的正是ateapi控制平面上的两个 RPCMintActorJWT文档中常称 MintJWT和MintActorCertificate文档中常称 MintCert定义在 pkg/proto/ateapipb/ateapi.proto。30 秒速览两个签发接口做什么接口产物典型用途MintJWT一个 OIDC 兼容的 JWT出站请求时由 egress 网关为 Agent 注入身份头下游按标准 OIDC 方式校验MintCert一张带 SPIFFE 地址的 mTLS 客户端证书签署 CSRAgent 与 egress 网关之间建立双向 TLS网关凭证书认出是哪个 Actor两者都用atespaceactor 名称标识 Agent与 API 其他接口完全一致。详细说明见 docs/api-guide.md 的 Actor Identity Credentials 章节。MintJWT给 AI Agent 签一个标准 JWT调用MintActorJWT时请求里需要带上 Actor 的引用、Actor UID防止删除后同名重建的换票攻击和至少一个受众audience最多 16 个——定义见 pkg/proto/ateapipb/ateapi.proto。签出的 JWT 是一个OIDC Discovery 兼容的令牌携带以下声明见 pkg/proto/ateapipb/ateapi.protoiss签发者一个可以拉取 OIDC 发现文档的 URLsub主题格式为atespaces:${atespace}:actors:${actorname}——这就是 Agent 的身份证号aud受众令牌被绑定到具体服务不能随便乱用nbf/exp/iat标准时间声明令牌天然有有效期ate.devSubstrate 扩展段含atespace与actorName。典型调用方是egress 网关当某个 Actor 配置了出站请求注入 JWT策略时网关在转发前调用 MintJWT把短期身份令牌附在出站流量上下游 API 无需了解 Substrate 内部细节只需按 OIDC 规范验签。MintCert给 AI Agent 签一张 mTLS 证书MintActorCertificate接收一张 DER 编码的CSR证书签名请求——签名方只从中提取公钥其余内容一律忽略——外加一个用途purpose字段用来区分Agent 本人在行动和系统组件代表 Agent 行动。请求/响应定义见 pkg/proto/ateapipb/ateapi.proto。签出的叶子证书携带SPIFFE URI作为身份spiffe://substrate-actor.local/atespace/atespace/actor/actor_name响应返回 DER 编码的证书链叶子在前、中间证书跟随实际寿命为 1 小时由ateapi内部的本地 CA 池签发CA 实现见 internal/localca/localca.goActor 身份扩展字段写入逻辑见 internal/substratex509/substratex509.go。它有两个实际用途atunnel 通道节点上的 atelet 为 Actor 申请证书用于与 egress 网关通信客户端证书注入出站请求配置了注入 Actor 客户端证书策略时由 egress 网关调用。最终egress 网关会拿着证书里的 SPIFFE 身份反查控制平面确认这个 Actor 确实存在且在运行——这个双因素验证流程可以在 internal/e2e/suites/egressauthz/actoridentity_test.go 的端到端测试里看到完整示例。谁能调用 MintJWT 与 MintCert三重护栏 关键设计Actor 自己不能直接调用这两个 RPC。必须由节点监督者atelet通过 mTLS Pod 证书来调用且必须同时满足三个条件详见 docs/api-guide.md调用方证书身份是atelet服务账号spiffe://cluster.local/ns/ate-system/sa/atelet并携带 Pod Identity 扩展把它钉死在某一台节点上目标 Actor 在 Actor 数据库中当前处于运行状态承载该 Actor 的 Worker Pod 与调用它的 atelet在同一节点且仍分配给该 Actor。这意味着每台节点上的 atelet 只能为自己机器上正在跑的 Actor签发凭据无法越权。两条错误处理也值得学习任一检查失败返回PERMISSION_DENIED且不带任何细节——接口不能被人用来探测某个 Actor 存不存在、跑在哪台机器Actor 存在但处于挂起/暂停/崩溃状态则返回FAILED_PRECONDITION。另外配置 docs/authentication.md 中的actorIdentityJWTProvider可以指定哪个 JWT 提供商的用户被允许调用 ActorIdentity.MintJWT进一步收窄签发入口。实战三步让你的 Agent 带着稳定身份出站以下是最小可跑的本地环境路径Kind 集群搭环境按 README.md 的 Quickstart 执行hack/create-kind-cluster.sh与hack/install-ate-kind.sh --deploy-ate-system再部署 Counter 演示--deploy-demo-counter。创建 Actorkubectl ate create actor my-counter-1 -a ate-demo-counter --template counterCLI 完整文档见 cmd/kubectl-ate/README.md。Actor 被调度到某个 Worker 进入 RUNNING 状态后就具备了被签发凭据的资格。出站带身份为 Actor 配置 egress 策略后出站流量经网关自动完成 MintJWT / 客户端证书注入网关侧的信任链校验与 MITM 拦截配置可参考 docs/egress-trust-bundle.md。对新手来说记住一句话即可身份跟着逻辑 Actor走不跟着 Pod 走签发权被牢牢锁在Actor 当前所在节点的 atelet 手里。相关文档与源码速查 资料路径API 完整指南含 Actor Identity 章节docs/api-guide.mdate-api 认证配置JWT 提供商docs/authentication.md威胁模型信任边界与假设docs/threat-model.md服务与消息定义gRPC/Protobufpkg/proto/ateapipb/ateapi.proto控制平面实现Mint 逻辑cmd/ateapi/internal/controlapi/actor.go本地 CA 池internal/localca/localca.go证书凭据包key chain 的 PEM 约定internal/credbundle/credbundle.goatunnel 凭据获取internal/atunnel/credential.go端到端验证egress 身份internal/e2e/suites/egressauthz/actoridentity_test.go常见问题 FAQ为什么不让 Actor 自己签身份因为零信任假设下沙箱内进程不可信。签发权收敛到节点级 atelet 且受同节点 运行中 已分配三重约束把伪造身份的窗口压到最小。Actor 迁移后已签发的凭据还有效吗凭据本身有短有效期证书约 1 小时过期后由新所在节点的 atelet 重新签发由于 sub / SPIFFE URI 只编码逻辑身份atespace 名称换机器不换身份。下游系统如何验证这个身份JWT 走标准 OIDC Discovery 流程验证iss/aud/签名mTLS 证书则由网关校验证书链并反查控制平面确认 Actor 正在运行两条路径互为补充。掌握 MintJWT 与 MintCert你就理解了 Agent Substrate 如何在百万级沙箱高密度复用的架构里给每一个 AI Agent 发一张随迁移不变、天然短效、可被标准协议校验的身份证。【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考