Agent Governance Toolkit 的 Dify 信任层集成方案：面向多智能体的 Ed25519 身份验证与信任治理

Agent Governance Toolkit 的 Dify 信任层集成方案面向多智能体的 Ed25519 身份验证与信任治理【免费下载链接】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-toolkitAgentMesh 信任层Trust Layer是 Agent Governance Toolkit 中为多智能体协作提供零信任身份与信任验证的关键组件。本文以仓库中的历史集成提案 DIFY-INTEGRATION-PROPOSAL.md 为主体结合 agentmesh-integrations/dify 目录下的真实实现源码完整解析该方案提出的四项信任工具、Ed25519 身份体系、信任评分机制、能力访问控制与审计日志设计以及提案被 Dify 主仓库关闭后的插件化演进路径。读完本文你将掌握如何在 Dify 场景中为 Agent 建立可验证的密码学身份并理解信任评分、能力校验、HTTP 信任头协议与中间件加固的完整落地方式。提案背景与历史脉络该文档是一份历史集成提案Historical integration proposal记录了 Agent Governance Toolkit 将 AgentMesh 信任扩展Trust Extension接入 Dify 的完整过程。关键时间线与状态如下提交时间2026 年 2 月 6 日向 Dify 主仓库提交 Pull Request编号 32079处理结果PR 被 Dify 维护者关闭未合并维护者建议作者改向 Dify 独立的插件仓库提交插件后续状态作者表示会跟进插件提交但截至文档复核2026-07-16未发现公开的插件提交或市场Marketplace上架记录仓库内现状对应实现代码保留在 agent-governance-python/agentmesh-integrations/dify/ 目录并附有 ARCHIVE_NOTE.md 归档说明状态标记为 Archived - Pending plugin submission已归档等待插件化提交。归档说明中保留了 Dify 维护者的原始指引Dify 主仓库不再接受第三方插件提交开发者应参考 Dify 插件开发文档将代码打包为 Dify 插件后提交至独立的插件仓库。这意味着该目录中的代码是插件化改造前的候选素材其架构与 API 设计仍然完整可用。提案的四项核心工具提案的核心是向 Dify 添加一个 AgentMesh 信任扩展为 Agent 提供密码学身份与信任验证能力并规划了四类工具Tools工具说明verify_peer使用 Ed25519 密码学签名验证另一个 Agent 的身份与能力verify_step检查某个 Agent 是否有权限执行特定工作流步骤get_identity获取本 Agent 的密码学身份DID 公钥用于与对端共享record_interaction记录交互成功/失败用于动态更新信任评分从仓库实现来看这四类提案工具与 agentmesh-integrations/dify 中的 Python 实现方法一一对应verify_peer→ TrustManager.verify_peer()校验对端 DID、公钥与能力列表verify_step→ TrustManager.verify_workflow_step()校验工作流步骤授权get_identity→ VerificationIdentity本地生成 DID 与 Ed25519 密钥对to_dict()输出对外共享的身份信息record_interaction→ TrustManager.record_success() / record_failure()按交互结果增减信任评分。为什么需要这套信任层在多智能体工作流中Agent 之间必须确认正在与谁通信。该提案给出的信任层提供了四层能力Ed25519 密码学身份DID每个 Agent 拥有一个由本地生成的去中心化标识符与 Ed25519 密钥对信任评分0.0–1.0基于行为历史动态计算反映 Agent 的可靠程度基于能力Capability的访问控制按工作流步骤粒度校验权限完整的信任决策审计日志为合规与事后追溯提供依据。这套设计对应的正是仓库项目层面强调的零信任身份理念身份可验证、信任可量化、权限可校验、决策可审计四个环节共同构成多智能体协作的安全底座。隐私与数据设计边界提案明确划定了该信任层的隐私与数据边界实现代码也遵循了同样的约束不收集任何个人用户数据完全在 Dify 环境本地运行不依赖外部信任服务Agent DID 通过 Ed25519 在本地生成identity.py 中基于名称、租户 ID、应用 ID 与纳秒时间戳生成种子并派生 DID信任评分存储在内存中TrustManager._trust_scores字典审计日志存储在内存中不对外持久化TrustManager._audit_log列表且有界控制。需要特别强调的是README.md 与源码共同表明信任评分、验证缓存与审计日志均为进程内内存状态。在多 worker 部署如 gunicorn 多 worker下数据不会跨 worker 共享重启即丢失若生产环境需要持久化审计轨迹应在TrustManager之上扩展外部存储如 Redis、PostgreSQL。HTTP 信任头协议与中间件信任启用后Agent 之间通过 HTTP 头传递信任凭证这是提案验证 Agent 身份后再执行的传输层实现请求头说明X-Agent-DIDAgent 的去中心化标识符X-Agent-Public-KeyBase64 编码的 Ed25519 公钥X-Agent-Capabilities逗号分隔的能力列表X-Agent-Signature请求体签名TODO中间件尚未验证重要限制X-Agent-Signature请求体签名验证在文档中已声明为未来实现当前中间件并未强制执行。现阶段的信任层只验证身份存在性与能力声明尚未将请求与声明的身份做密码学绑定这是该实现的一个重要安全边界接入方必须知悉。中间件实现位于 middleware.py核心组件有两个TrustMiddleware单例模式的中间件通过initialize(identity, min_trust_score)初始化持有全局TrustManagertrust_required 装饰器用于保护 Flask API 端点签名如下from extensions.agentmesh import trust_required app.route(/api/v1/workflows/workflow_id/run, methods[POST]) trust_required(min_score0.6, capabilities[workflow:execute]) def run_workflow(workflow_id): # Request is verified - peer has sufficient trust # Access verification result via g.trust_verification return execute_workflow(workflow_id)装饰器的三个关键参数及其语义middleware.pymin_score默认0.5要求的最低信任评分不足则返回 403required_capabilities对端必须具备的能力列表缺失则校验失败require_headers默认False为False时是宽松模式无信任头请求直接放行向后兼容为True时是严格模式缺少X-Agent-DID头的请求直接返回 401。校验通过后验证结果会写入 Flask 请求上下文g.trust_verification、g.peer_did视图函数可直接取用。中间件还提供add_trust_headers()在出站响应中附加本机身份头方便下游继续信任传播。源码级核心实现剖析1. 密码学身份VerificationIdentityidentity.py 实现了基于 Ed25519 的验证身份核心设计如下密钥生成优先使用cryptography库的ed25519.Ed25519PrivateKey.generate()若该库不可用则回退到基于 SHA-256 的派生方案此时签名验证会安全失败——verify_signature()在缺少密码学库时直接返回False并告警绝不降级放行DID 格式did:verification:sha256(seed)[:32]种子由名称、租户、应用与时间戳拼接能力声明capabilities列表与has_capability()方法支持通配符匹配签名与验证sign(data)生成VerificationSignature含公钥、签名、UTC 时间戳verify_signature()用公钥验签序列化安全to_dict()刻意排除私钥避免身份对象被意外整体导出泄露密钥。能力匹配规则由capability_matches()实现支持三种模式精确匹配workflow:execute匹配workflow:execute通用通配符*匹配任意能力前缀通配符workflow:*匹配workflow:execute。2. 信任管理TrustManagertrust.py 中的TrustManager是核心状态机具备线程安全内部threading.Lock保护全部可变状态与验证结果缓存缓存键为DID 公钥前 32 字符TTL 默认 900 秒两大特性。verify_peer 校验流程trust.py先检查能力逐一比对required_capabilities与对端声明能力缺失即失败再查缓存命中且未过期直接返回基础校验DID 或公钥为空即失败计算信任评分并与min_trust_score默认 0.5比较不足即拒绝通过则写入缓存并记录审计日志。信任评分计算_calculate_trust_score()新对端基础分0.5若提供了公钥额外0.1即新对端默认 0.6成功交互0.01record_success失败交互按严重度扣分record_failure(severity)默认每次-0.1最高可扣-0.5分数始终钳制在0.0–1.0区间时间衰减Time decay在文档中标记为 TODO尚未实现。信任评分等级参考来自 README.md评分区间信任等级建议策略0.0 – 0.3不可信默认拦截0.3 – 0.5低信任受限操作0.5 – 0.7中信任标准操作0.7 – 0.9高信任扩展权限0.9 – 1.0完全可信全量访问审计日志每条记录包含时间戳、动作如verify_peer/verify_step、目标、是否成功、信任评分与身份 DID日志列表有界存储——超过 10000 条时裁剪为最近 5000 条防止内存无限增长trust.py。3. 模块导出init.py 统一导出VerificationIdentity、VerificationSignature、capability_matches、TrustManager、TrustVerificationResult、TrustMiddleware、trust_required外部只需一条导入语句即可使用全部能力。配置参数与部署注意事项README 规划了三项环境变量配置但需注意标注为TODO当前尚未接线——现阶段必须通过代码编程式初始化TrustMiddleware.initialize(...)环境变量默认值说明AGENTMESH_ENABLEDfalse是否启用信任验证AGENTMESH_MIN_TRUST0.5最低信任评分阈值AGENTMESH_CACHE_TTL900验证缓存 TTL秒部署时必须正视的三个限制进程内状态信任评分、验证缓存、审计日志均驻留内存多 worker 不共享、重启丢失签名未验证X-Agent-Signature尚未被中间件强制校验请求体与身份的密码学绑定仍是 TODO环境变量未接线目前只能通过代码初始化无法纯配置驱动。现状总结与插件化改造路径该提案最终未进入 Dify 主仓库仓库内实现处于已归档等待插件化状态。ARCHIVE_NOTE.md 明确给出了后续步骤阅读 Dify 插件开发文档将本目录代码打包为 Dify 插件向 Dify 插件仓库提交 PR。对希望继续推进此集成的团队这意味着可以直接以本目录的 identity.py、trust.py、middleware.py 为内核将verify_peer、verify_step、get_identity、record_interaction四项能力封装为 Dify 插件工具并在此基础上补齐签名验证、时间衰减、环境变量接线与外部持久化即可形成生产可用的 Dify 多智能体信任治理方案。这也是本提案作为历史提案对后续集成最重要的参考价值所在。【免费下载链接】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），仅供参考