AgentMesh 零信任架构详解DID 身份、mTLS 双向认证与动态信任评分【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit本文基于 AgentMesh 的零信任设计文档系统讲解在 AI Agent 互联场景中如何落地零信任原则显式身份验证、最小权限、假设失陷、微分段与持续验证。结合仓库中agentmesh的信任握手、mTLS 身份校验与信任评分源码你将掌握一套可对照实现的 Agent 间零信任通信方案并了解各机制在当前仓库中的真实实现位置与参数取值。什么是零信任零信任的核心假设是任何 Agent、消息或连接都不应被隐式信任无论它来自网络边界之内还是之外——每一次交互都必须经过验证。与传统安全模型的对照如下传统安全Trust but verify先信任再验证零信任安全Never trust, always verify永不信任持续验证在 AgentMesh 中这一理念被具体化为五个可实现的机制显式验证、最小权限访问、假设失陷、DID 身份与 mTLS、以及动态信任评分与微分段。零信任三原则1. 显式验证Verify Explicitly每个 Agent 的每个请求都必须携带可验证的凭据。设计文档给出的模型是每条消息都包含签名与时间戳接收方在处理前先验证签名# Every message includes cryptographic proof of identity message Message( from_agentdid:agentmesh:alice, to_agentdid:agentmesh:bob, payload{request: read_data}, signaturesign(payload, alice_private_key), timestampdatetime.now(timezone.utc), ) # Recipient verifies before processing if not verify_signature(message.signature, message.from_agent): raise TrustViolation(Invalid signature)仓库中的真实实现是 trust/handshake.py 中的Ed25519 挑战/应答握手challenge/responseHandshakeChallenge由服务端生成包含secrets.token_hex(32)的随机 nonce默认30 秒过期expires_in_seconds: int 30过期即拒绝防止重放可选开启RFC 9334 freshness noncerequire_freshnessTrue要求响应方在签名载荷中原样回显该 nonce以此证明证据Evidence的活性对齐 RATS 架构HandshakeResponse携带agent_did、capabilities、trust_score0–1000 整数、Ed25519 签名与公钥握手结果封装在HandshakeResult中包含verified标志、对端 DID、信任层级标签verified_partner | trusted | standard | untrusted、能力列表、握手时延latency_ms以及失败时的rejection_reason。跨组织 Agent 还会通过 JWKS 联邦填充external_identity字段对应 ADR-0007 跨组织身份联邦。从源码结构看这比消息签名更进一步它把身份验证、信任评级和握手性能观测合并为一次带超时的握手流程超时与身份错误分别以HandshakeTimeoutError、HandshakeError抛出。2. 最小权限访问Least-Privilege AccessAgent 只拥有完成其特定任务所需的权限。文档示例用策略语言表达# Policy: Agent can only access specific resources agent: did:agentmesh:data-reader permissions: - resource: /data/reports actions: [read] # Cannot write, cannot access other paths对应到仓库实现agentmesh/governance/目录下提供了完整策略执行链governance/policy.py 定义策略模型governance/policy_evaluator.py 负责逐请求评估governance/trust_policy.py 将信任分作为策略决策的输入条件之一。身份侧同样内置了权限边界identity/agent_id.py 中AgentIdentity的max_initial_trust_score字段注释明确写着这是Lineage-bound trust cap谱系信任上限对应 Sybil 抗性的不变式 6且delegation_depth受 constants.py 中DEFAULT_DELEGATION_MAX_DEPTH 5的委托链深度限制——委托不会无限放权这正是最小权限在身份谱系上的落地。3. 假设失陷Assume Breach以攻击者已经在内部为前提做设计限制爆炸半径。文档给出的拓扑是┌─────────────────────────────────────────────────────────────┐ │ AGENTMESH │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Agent A │────►│ Gateway │────►│ Agent B │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Audit │ │ Policy │ │ Audit │ │ │ │ Log │ │ Check │ │ Log │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ Every hop: Verify identity, check policy, log action │ └─────────────────────────────────────────────────────────────┘即每一跳都做三件事验证身份、检查策略、记录审计日志。仓库中审计链路由 governance/audit.py 与governance/audit_backends.py支撑网关侧策略供给见 gateway/policy_provider.py。实现细节去中心化身份DID每个 Agent 拥有唯一、密码学可验证的身份。文档给出的概念格式为did:agentmesh:production:finance-bot:v1.2.3 ↑ ↑ ↑ ↑ method network agent-name versionDID 具备三个特性自主权Agent 掌控自己的身份、可验证性公钥可解析、可移植性跨组织可用。需要注意与源码的差异当前仓库实际实现的 DID 格式更简洁。从 identity/agent_id.py 看AgentDID的 method 固定为mesh格式为did:mesh:unique-id且unique_id直接取secrets.token_hex(16)——源码注释解释了原因此前用Agent 名 组织名 8 字节随机量做种子哈希前两者是攻击者可知的不提供熵因此改为直接使用 128 位随机 hex32 个十六进制字符。AgentIdentity则在此之上扩展了Ed25519 身份密钥public_keybase64 编码与verification_key_id人类担保人sponsor_email——每个 Agent 身份都关联一个可问责的真人能力声明capabilities与生命周期状态active / suspended / revoked模块 docstring 声明吊销传播延迟 ≤5 秒委托谱系parent_did、delegation_depth、max_initial_trust_score。从源码结构看did:mesh:与文档示例中更长的多段格式并不冲突后者描述的是方法 网络 名称 版本的语义分段思路前者是当前代码库落地的最小实现实际集成时以仓库中的AgentDID为准。双向 TLSmTLS文档要求所有 Agent 间通信使用 mTLS双方向彼此出示证书不存在匿名连接Agent A AgentMesh Agent B │ │ │ │── Client Certificate ──►│ │ │◄── Server Certificate ──│ │ │ │── Client Certificate ──►│ │ │◄── Server Certificate ──│ │ │ │ │◄─────── Encrypted Channel ──────────────────────►│仓库中的实现见 identity/mtls.py其设计要点值得注意身份与证书的密码学绑定X.509 证书直接由 Agent 的Ed25519 身份密钥签名RFC 8410证书公钥即 Agent 的 Ed25519 公钥自签名证明了私钥持有性——TLS 层认证与 DID 身份层认证是同一把钥匙而非两套体系DID 内嵌 SANAgent DID 以 URI 形式写入证书 Subject Alternative Name形如URI:did:mesh:xxx接收方可从证书直接还原 DID并可结合身份注册表做 key-to-DID 交叉核验服务端强制客户端证书MTLSConfig中require_client_cert默认True、verify_peer默认True即无客户端证书即拒绝是缺省行为与无匿名连接的文档表述一致支持临时ephemeral证书/密钥对cert_path、key_path为None时自动生成也支持挂载 PEM 文件与 CA 证书做对端校验。信任评分Trust Scoring文档定义了一个 0.0–1.0 区间、以 0.5 为中性的动态信任分模型class TrustScore: Trust score calculated from agent behavior. base_score: float 0.5 # Start neutral # Factors that increase trust successful_interactions: int policy_compliance_rate: float uptime: timedelta # Factors that decrease trust policy_violations: int anomalous_behavior_count: int failed_authentications: int def calculate(self) - float: Calculate current trust score (0.0 - 1.0). score self.base_score score min(0.2, self.successful_interactions * 0.01) score 0.2 * self.policy_compliance_rate score - 0.1 * self.policy_violations score - 0.05 * self.anomalous_behavior_count return max(0.0, min(1.0, score))信任分影响三个决策面是否放行请求、应用何种限流、需要哪个级别的审批。当前仓库的实现采用了0–1000 整数标度核心常量集中在 constants.py常量值含义TRUST_SCORE_MIN / MAX0 / 1000分数区间TRUST_SCORE_DEFAULT500新 Agent 初始中性分对应文档中 0.5 的start neutralTIER_VERIFIED_PARTNER_THRESHOLD900verified_partner层级TIER_TRUSTED_THRESHOLD700trusted层级TIER_STANDARD_THRESHOLD500standard层级TIER_PROBATIONARY_THRESHOLD300probationary层级TRUST_REVOCATION_THRESHOLD300低于此值触发吊销评估TRUST_WARNING_THRESHOLD500警告阈值层级标签的映射集中在 trust/levels.py 的trust_level_for_score()注释明确它是 trust-engine HTTP API、agentmesh trustCLI 与所有需要渲染分数标签的调用方共享的唯一事实来源。分数本身由五个维度加权合成权重合计为 1.0见 constants.py 注释维度权重策略合规policy compliance0.25安全态势security posture0.25输出质量output quality0.20资源效率resource efficiency0.15协作健康度collaboration health0.15可以推断这与文档示例中违规扣分、成功加分、合规率加权的朴素模型是同源思路的工程化扩展维度化权重替代了单一加减分且阈值与文档中的 0.3/0.5 等边界一一对应300/500/700/900 正好落在 0–1000 标度的 0.3/0.5/0.7/0.9 位置。更完整的接口说明可参考 docs/trust-scoring-api.md。微分段Micro-SegmentationAgent 按职能与数据敏感度分段跨段通信必须显式通过策略审批┌─────────────────────────────────────────────────────────┐ │ PRODUCTION MESH │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ SEGMENT: │ │ SEGMENT: │ │ SEGMENT: │ │ │ │ PUBLIC │ │ INTERNAL │ │ SENSITIVE │ │ │ │ │ │ │ │ │ │ │ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │ │ │ │Bot A │ │ │ │Bot C │ │ │ │Bot E │ │ │ │ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │ │ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │ │ │ │Bot B │ │ │ │Bot D │ │ │ │Bot F │ │ │ │ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ │ │ │ └──────────────────┼──────────────────┘ │ │ │ │ │ Policy-controlled cross-segment │ │ communication │ └─────────────────────────────────────────────────────────┘跨段cross-segment通信要求显式的策略批准这与前述每跳策略检查是同一套机制的两种视角策略引擎同时约束能不能做这个动作与能不能跟那个段说话。持续验证Continuous Verification信任不是一次性决策。文档列出四个持续验证机制会话令牌有过期时间必须刷新行为监控实时检测异常策略再评估每个请求都重新执行凭据轮换确保泄露的密钥影响范围有限。文档示例# Example: Session-based verification session await mesh.create_session(agent_did, ttl300) # 5 min TTL # Every 30 seconds, verify session is still valid while session.is_active: if not await mesh.verify_session(session): raise SessionExpired() await asyncio.sleep(30)仓库中的对应证据握手挑战的 30 秒短 TTL 与is_expired()校验trust/handshake.py体现了短命凭据 主动过期检查的模式凭据轮换的常量CREDENTIAL_ROTATION_THRESHOLD_SECONDS 60constants.py与 identity/rotation.py、identity/revocation.py 共同构成轮换/吊销能力风险与奖励评分均以 30 秒为更新周期RISK_UPDATE_INTERVAL_SECONDS、REWARD_UPDATE_INTERVAL_SECONDS与示例中每 30 秒复核一次会话的节奏一致。与传统安全模型对比Aspect传统安全零信任AgentMesh信任边界网络边缘每个 Agent认证方式登录一次每个请求授权方式基于角色基于属性 上下文监控方式边界日志全网状可观测性失陷响应在边界检测在故障点遏制对照仓库实现身份层identity/下的 mTLS、SPFIRE 风格的spiffe.py、external_jwks.py联邦、策略层governance/下的 policy evaluator 与 Cedar/OPA 后端、可观测层observability/下的 Prometheus/Grafana/OTel 导出分别对应上表的三个转变方向。启用零信任功能按文档给出的方式在 AgentMesh 配置中打开各开关# agentmesh.yaml security: zero_trust: enabled: true identity: require_did: true did_method: agentmesh tls: mtls_required: true min_tls_version: 1.3 verification: continuous: true session_ttl_seconds: 300 segmentation: enabled: true default_segment: internal配置要点identity.require_did强制所有 Agent 携带 DIDdid_method指定身份方法注意仓库当前代码的 method 取值为mesh见AgentDID的Literal[mesh]配置该字段时以实际发行身份的组件为准tls.mtls_required: true对应MTLSConfig.require_client_cert的缺省行为min_tls_version: 1.3约束最低 TLS 版本verification.session_ttl_seconds: 300与上文会话示例的 5 分钟 TTL 一致segmentation.default_segment: internal规定未显式分段的 Agent 落入 internal 段遵循默认不暴露的原则。适用前提与限制以上机制依赖部署方正确发行与轮换 Ed25519 身份密钥、配置 CA 与证书链信任分初始值为 500中性新 Agent 需要通过持续交互积累到 700 以上才会进入trusted层级跨组织场景则需额外的 JWKS 联邦支持。延伸阅读Identity Management — DID 的创建与管理Trust Scoring API — 信任评分接口的完整说明docs/trust-model-guide.md — 信任模型指南核心源码trust/handshake.py、identity/mtls.py、identity/agent_id.py、constants.py【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AgentMesh 零信任架构详解：DID 身份、mTLS 双向认证与动态信任评分
AgentMesh 零信任架构详解DID 身份、mTLS 双向认证与动态信任评分【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit本文基于 AgentMesh 的零信任设计文档系统讲解在 AI Agent 互联场景中如何落地零信任原则显式身份验证、最小权限、假设失陷、微分段与持续验证。结合仓库中agentmesh的信任握手、mTLS 身份校验与信任评分源码你将掌握一套可对照实现的 Agent 间零信任通信方案并了解各机制在当前仓库中的真实实现位置与参数取值。什么是零信任零信任的核心假设是任何 Agent、消息或连接都不应被隐式信任无论它来自网络边界之内还是之外——每一次交互都必须经过验证。与传统安全模型的对照如下传统安全Trust but verify先信任再验证零信任安全Never trust, always verify永不信任持续验证在 AgentMesh 中这一理念被具体化为五个可实现的机制显式验证、最小权限访问、假设失陷、DID 身份与 mTLS、以及动态信任评分与微分段。零信任三原则1. 显式验证Verify Explicitly每个 Agent 的每个请求都必须携带可验证的凭据。设计文档给出的模型是每条消息都包含签名与时间戳接收方在处理前先验证签名# Every message includes cryptographic proof of identity message Message( from_agentdid:agentmesh:alice, to_agentdid:agentmesh:bob, payload{request: read_data}, signaturesign(payload, alice_private_key), timestampdatetime.now(timezone.utc), ) # Recipient verifies before processing if not verify_signature(message.signature, message.from_agent): raise TrustViolation(Invalid signature)仓库中的真实实现是 trust/handshake.py 中的Ed25519 挑战/应答握手challenge/responseHandshakeChallenge由服务端生成包含secrets.token_hex(32)的随机 nonce默认30 秒过期expires_in_seconds: int 30过期即拒绝防止重放可选开启RFC 9334 freshness noncerequire_freshnessTrue要求响应方在签名载荷中原样回显该 nonce以此证明证据Evidence的活性对齐 RATS 架构HandshakeResponse携带agent_did、capabilities、trust_score0–1000 整数、Ed25519 签名与公钥握手结果封装在HandshakeResult中包含verified标志、对端 DID、信任层级标签verified_partner | trusted | standard | untrusted、能力列表、握手时延latency_ms以及失败时的rejection_reason。跨组织 Agent 还会通过 JWKS 联邦填充external_identity字段对应 ADR-0007 跨组织身份联邦。从源码结构看这比消息签名更进一步它把身份验证、信任评级和握手性能观测合并为一次带超时的握手流程超时与身份错误分别以HandshakeTimeoutError、HandshakeError抛出。2. 最小权限访问Least-Privilege AccessAgent 只拥有完成其特定任务所需的权限。文档示例用策略语言表达# Policy: Agent can only access specific resources agent: did:agentmesh:data-reader permissions: - resource: /data/reports actions: [read] # Cannot write, cannot access other paths对应到仓库实现agentmesh/governance/目录下提供了完整策略执行链governance/policy.py 定义策略模型governance/policy_evaluator.py 负责逐请求评估governance/trust_policy.py 将信任分作为策略决策的输入条件之一。身份侧同样内置了权限边界identity/agent_id.py 中AgentIdentity的max_initial_trust_score字段注释明确写着这是Lineage-bound trust cap谱系信任上限对应 Sybil 抗性的不变式 6且delegation_depth受 constants.py 中DEFAULT_DELEGATION_MAX_DEPTH 5的委托链深度限制——委托不会无限放权这正是最小权限在身份谱系上的落地。3. 假设失陷Assume Breach以攻击者已经在内部为前提做设计限制爆炸半径。文档给出的拓扑是┌─────────────────────────────────────────────────────────────┐ │ AGENTMESH │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Agent A │────►│ Gateway │────►│ Agent B │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Audit │ │ Policy │ │ Audit │ │ │ │ Log │ │ Check │ │ Log │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ Every hop: Verify identity, check policy, log action │ └─────────────────────────────────────────────────────────────┘即每一跳都做三件事验证身份、检查策略、记录审计日志。仓库中审计链路由 governance/audit.py 与governance/audit_backends.py支撑网关侧策略供给见 gateway/policy_provider.py。实现细节去中心化身份DID每个 Agent 拥有唯一、密码学可验证的身份。文档给出的概念格式为did:agentmesh:production:finance-bot:v1.2.3 ↑ ↑ ↑ ↑ method network agent-name versionDID 具备三个特性自主权Agent 掌控自己的身份、可验证性公钥可解析、可移植性跨组织可用。需要注意与源码的差异当前仓库实际实现的 DID 格式更简洁。从 identity/agent_id.py 看AgentDID的 method 固定为mesh格式为did:mesh:unique-id且unique_id直接取secrets.token_hex(16)——源码注释解释了原因此前用Agent 名 组织名 8 字节随机量做种子哈希前两者是攻击者可知的不提供熵因此改为直接使用 128 位随机 hex32 个十六进制字符。AgentIdentity则在此之上扩展了Ed25519 身份密钥public_keybase64 编码与verification_key_id人类担保人sponsor_email——每个 Agent 身份都关联一个可问责的真人能力声明capabilities与生命周期状态active / suspended / revoked模块 docstring 声明吊销传播延迟 ≤5 秒委托谱系parent_did、delegation_depth、max_initial_trust_score。从源码结构看did:mesh:与文档示例中更长的多段格式并不冲突后者描述的是方法 网络 名称 版本的语义分段思路前者是当前代码库落地的最小实现实际集成时以仓库中的AgentDID为准。双向 TLSmTLS文档要求所有 Agent 间通信使用 mTLS双方向彼此出示证书不存在匿名连接Agent A AgentMesh Agent B │ │ │ │── Client Certificate ──►│ │ │◄── Server Certificate ──│ │ │ │── Client Certificate ──►│ │ │◄── Server Certificate ──│ │ │ │ │◄─────── Encrypted Channel ──────────────────────►│仓库中的实现见 identity/mtls.py其设计要点值得注意身份与证书的密码学绑定X.509 证书直接由 Agent 的Ed25519 身份密钥签名RFC 8410证书公钥即 Agent 的 Ed25519 公钥自签名证明了私钥持有性——TLS 层认证与 DID 身份层认证是同一把钥匙而非两套体系DID 内嵌 SANAgent DID 以 URI 形式写入证书 Subject Alternative Name形如URI:did:mesh:xxx接收方可从证书直接还原 DID并可结合身份注册表做 key-to-DID 交叉核验服务端强制客户端证书MTLSConfig中require_client_cert默认True、verify_peer默认True即无客户端证书即拒绝是缺省行为与无匿名连接的文档表述一致支持临时ephemeral证书/密钥对cert_path、key_path为None时自动生成也支持挂载 PEM 文件与 CA 证书做对端校验。信任评分Trust Scoring文档定义了一个 0.0–1.0 区间、以 0.5 为中性的动态信任分模型class TrustScore: Trust score calculated from agent behavior. base_score: float 0.5 # Start neutral # Factors that increase trust successful_interactions: int policy_compliance_rate: float uptime: timedelta # Factors that decrease trust policy_violations: int anomalous_behavior_count: int failed_authentications: int def calculate(self) - float: Calculate current trust score (0.0 - 1.0). score self.base_score score min(0.2, self.successful_interactions * 0.01) score 0.2 * self.policy_compliance_rate score - 0.1 * self.policy_violations score - 0.05 * self.anomalous_behavior_count return max(0.0, min(1.0, score))信任分影响三个决策面是否放行请求、应用何种限流、需要哪个级别的审批。当前仓库的实现采用了0–1000 整数标度核心常量集中在 constants.py常量值含义TRUST_SCORE_MIN / MAX0 / 1000分数区间TRUST_SCORE_DEFAULT500新 Agent 初始中性分对应文档中 0.5 的start neutralTIER_VERIFIED_PARTNER_THRESHOLD900verified_partner层级TIER_TRUSTED_THRESHOLD700trusted层级TIER_STANDARD_THRESHOLD500standard层级TIER_PROBATIONARY_THRESHOLD300probationary层级TRUST_REVOCATION_THRESHOLD300低于此值触发吊销评估TRUST_WARNING_THRESHOLD500警告阈值层级标签的映射集中在 trust/levels.py 的trust_level_for_score()注释明确它是 trust-engine HTTP API、agentmesh trustCLI 与所有需要渲染分数标签的调用方共享的唯一事实来源。分数本身由五个维度加权合成权重合计为 1.0见 constants.py 注释维度权重策略合规policy compliance0.25安全态势security posture0.25输出质量output quality0.20资源效率resource efficiency0.15协作健康度collaboration health0.15可以推断这与文档示例中违规扣分、成功加分、合规率加权的朴素模型是同源思路的工程化扩展维度化权重替代了单一加减分且阈值与文档中的 0.3/0.5 等边界一一对应300/500/700/900 正好落在 0–1000 标度的 0.3/0.5/0.7/0.9 位置。更完整的接口说明可参考 docs/trust-scoring-api.md。微分段Micro-SegmentationAgent 按职能与数据敏感度分段跨段通信必须显式通过策略审批┌─────────────────────────────────────────────────────────┐ │ PRODUCTION MESH │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ SEGMENT: │ │ SEGMENT: │ │ SEGMENT: │ │ │ │ PUBLIC │ │ INTERNAL │ │ SENSITIVE │ │ │ │ │ │ │ │ │ │ │ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │ │ │ │Bot A │ │ │ │Bot C │ │ │ │Bot E │ │ │ │ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │ │ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │ │ │ │Bot B │ │ │ │Bot D │ │ │ │Bot F │ │ │ │ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ │ │ │ └──────────────────┼──────────────────┘ │ │ │ │ │ Policy-controlled cross-segment │ │ communication │ └─────────────────────────────────────────────────────────┘跨段cross-segment通信要求显式的策略批准这与前述每跳策略检查是同一套机制的两种视角策略引擎同时约束能不能做这个动作与能不能跟那个段说话。持续验证Continuous Verification信任不是一次性决策。文档列出四个持续验证机制会话令牌有过期时间必须刷新行为监控实时检测异常策略再评估每个请求都重新执行凭据轮换确保泄露的密钥影响范围有限。文档示例# Example: Session-based verification session await mesh.create_session(agent_did, ttl300) # 5 min TTL # Every 30 seconds, verify session is still valid while session.is_active: if not await mesh.verify_session(session): raise SessionExpired() await asyncio.sleep(30)仓库中的对应证据握手挑战的 30 秒短 TTL 与is_expired()校验trust/handshake.py体现了短命凭据 主动过期检查的模式凭据轮换的常量CREDENTIAL_ROTATION_THRESHOLD_SECONDS 60constants.py与 identity/rotation.py、identity/revocation.py 共同构成轮换/吊销能力风险与奖励评分均以 30 秒为更新周期RISK_UPDATE_INTERVAL_SECONDS、REWARD_UPDATE_INTERVAL_SECONDS与示例中每 30 秒复核一次会话的节奏一致。与传统安全模型对比Aspect传统安全零信任AgentMesh信任边界网络边缘每个 Agent认证方式登录一次每个请求授权方式基于角色基于属性 上下文监控方式边界日志全网状可观测性失陷响应在边界检测在故障点遏制对照仓库实现身份层identity/下的 mTLS、SPFIRE 风格的spiffe.py、external_jwks.py联邦、策略层governance/下的 policy evaluator 与 Cedar/OPA 后端、可观测层observability/下的 Prometheus/Grafana/OTel 导出分别对应上表的三个转变方向。启用零信任功能按文档给出的方式在 AgentMesh 配置中打开各开关# agentmesh.yaml security: zero_trust: enabled: true identity: require_did: true did_method: agentmesh tls: mtls_required: true min_tls_version: 1.3 verification: continuous: true session_ttl_seconds: 300 segmentation: enabled: true default_segment: internal配置要点identity.require_did强制所有 Agent 携带 DIDdid_method指定身份方法注意仓库当前代码的 method 取值为mesh见AgentDID的Literal[mesh]配置该字段时以实际发行身份的组件为准tls.mtls_required: true对应MTLSConfig.require_client_cert的缺省行为min_tls_version: 1.3约束最低 TLS 版本verification.session_ttl_seconds: 300与上文会话示例的 5 分钟 TTL 一致segmentation.default_segment: internal规定未显式分段的 Agent 落入 internal 段遵循默认不暴露的原则。适用前提与限制以上机制依赖部署方正确发行与轮换 Ed25519 身份密钥、配置 CA 与证书链信任分初始值为 500中性新 Agent 需要通过持续交互积累到 700 以上才会进入trusted层级跨组织场景则需额外的 JWKS 联邦支持。延伸阅读Identity Management — DID 的创建与管理Trust Scoring API — 信任评分接口的完整说明docs/trust-model-guide.md — 信任模型指南核心源码trust/handshake.py、identity/mtls.py、identity/agent_id.py、constants.py【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考