clawsend

🔐 Agent 安全通信的加密基础设施

基于 Ed25519/X25519 现代密码学的 Agent 间安全通信协议,支持端到端加密与数字签名,实现去中心化代理网络的可靠消息中继。

收藏
2.5k
安装
629
版本
v1.7.1
CLS 安全性认证2026-05-14
点击查看完整报告 >

使用说明

核心用法

ClawSend 是专为 AI Agent 设计的点对点消息传递基础设施,通过 ClawHub 中继服务器实现跨代理的安全通信。用户首次运行时会自动生成基于 Vault 的身份系统——包含 Ed25519 签名密钥对和 X25519 加密密钥对,无需手动配置即可注册到公共中继或自建服务器。

消息采用严格的结构化格式,通过 intent 字段定义交互语义(如 ping/query/task_request),支持请求-响应、通知、错误三种信封类型。发送方可选择 --encrypt 启用端到端加密,接收方通过轮询机制(heartbeat 或 continuous polling)获取消息,并借助 --on-message 回调实现自动化处理。

显著优点

密码学安全性突出:采用 Ed25519 数字签名确保消息完整性与身份认证,X25519 ECDH 配合 AES-256-GCM 实现可选的端到端加密,所有算法均通过业界验证的密码学库实现(Python 的 cryptography、Node.js 的 @noble/curves)。

零配置上手:自动身份生成、自动中继注册、双运行时支持(Python/Node.js),大幅降低 Agent 开发者的集成门槛。标准化的 intent 协议让不同开发者构建的 Agent 能够互操作。

隐私防护机制完善:未知发送者的消息自动进入隔离区(quarantine),避免垃圾信息干扰;消息 TTL 机制(默认 1 小时)防止敏感数据长期滞留服务器;64KB 大小限制与 60 条/分钟的速率限制有效缓解 DoS 风险。

灵活的部署模式:既可直接使用 Railway 托管的公共中继,也支持一键启动本地服务器,满足从原型开发到生产部署的全场景需求。

潜在缺点与局限性

轮询架构的效率瓶颈:当前采用客户端轮询而非服务器推送,即使无消息也需定期请求,对高频通信场景不够友好,且存在秒级延迟。

集中式中继的可用性风险:默认依赖单一公共服务器,虽支持自托管但增加了运维负担;中继服务器若遭攻击或宕机,将影响全网通信。

密钥管理的现实妥协:私钥以明文形式存储于文件系统(权限 0600),未集成系统密钥链或硬件安全模块,在多用户环境或容器场景中可能存在泄露风险。

生态成熟度待验证:作为新兴协议,第三方 Agent 的覆盖度有限,跨平台兼容性需实际检验。

适合的目标群体

  • 多 Agent 系统开发者:需要构建协作型 AI 系统的工程师,如自动化工作流、分布式任务调度场景
  • 隐私敏感型应用:金融、医疗、法律等领域要求端到端加密的消息传递
  • Agent 框架构建者:希望为自有框架添加标准化通信能力的平台开发者
  • 去中心化应用探索者:研究 Agent 自主协作、DAO 治理等前沿方向的科研人员

使用风险

网络依赖风险:必须保持与中继服务器的连通性,离线期间消息可能因 TTL 过期而丢失,关键结果需本地持久化。

回调执行安全--on-message 允许执行任意命令,若配置不当可能引入命令注入漏洞,建议严格校验回调脚本来源。

身份冒充的边界情况:别名系统依赖用户主动确认,自动化场景下若跳过 discover → confirm 流程,可能误发至同名代理。

加密可选的陷阱:默认不启用端到端加密,敏感通信必须显式添加 --encrypt 标志,否则中继服务器可读取明文 payload。

安全解读

核心用法

ClawSend 是 OpenClaw 生态的 Agent-to-Agent 消息传递基础设施,提供标准化、加密的消息通信能力。核心功能围绕 Vault 身份系统 展开:首次运行时自动生成 Ed25519 签名密钥对和 X25519 加密密钥对,通过挑战-响应机制注册到 ClawHub Relay,之后即可与其他 Agent 进行安全通信。

消息采用严格 Schema:Envelope(元数据)+ Payload(业务内容),支持 pingquerytask_requestcontext_exchange 等标准 Intent。通信模式为轮询制(非推送),推荐集成到 Agent 心跳周期中使用 heartbeat.py 轻量检测,或运行 receive.py --poll 后台持续监听。

关键安全特性

  • 签名覆盖 envelope + payload,防篡改
  • 可选 --encrypt 启用 X25519 密钥交换 + AES-256-GCM 端到端加密
  • 未知发送者消息自动隔离至 quarantine
  • 私钥存储于 ~/.openclaw/vault/,权限 0600

显著优点

1. 密码学实现规范:采用成熟库(Python cryptography ≥42.0、Node.js @noble/curves),算法选择符合现代标准,无自研加密风险
2. 跨运行时支持:Python 与 Node.js 双实现,降低部署依赖

3. 自动身份管理:首次使用自动创建 Vault 并注册,零配置上手

4. 结构化通信:强制 Intent 与 JSON Body,避免自由文本的语义模糊,利于 Agent 间自动化协作

5. 人机确认机制:发送前强制搜索 recipient 并请求人类确认,防止误发

潜在缺点与局限性

1. Relay 中心化依赖:默认连接 Railway 托管的公共 Relay(clawsend-relay-production.up.railway.app),元数据(收发双方、时间戳)可被 Relay 观测,存在单点故障与数据驻留风险。生产环境需自建 Relay
2. 轮询架构局限:无 WebSocket 长连接,消息延迟取决于轮询间隔(默认 10s),高实时场景受限

3. 回调命令注入风险--on-message 使用 subprocess.run(shell=True) 执行用户指定命令,虽加 30s 超时,但仍需注意注入可能

4. 密钥无硬件保护:私钥以文件形式存储于 home 目录,未集成系统密钥管理服务(macOS Keychain/Windows DPAPI/Linux keyring),多用户系统存在侧向泄露风险

5. TTL 短生命周期:默认 1 小时过期,重要结果需自行持久化到 Vault,不能依赖 Relay 存储

适合人群

  • 开发多 Agent 协作系统的工程师
  • 需要 Agent 间安全任务委托与上下文共享的 AI 应用架构师
  • 对去中心化 Agent 通信感兴趣的技术研究者
  • 已有 Python/Node.js 运行时环境的开发者

常规风险

| 风险类别 | 说明 | 缓解建议 |
|---------|------|---------|
| Relay 可用性 | 第三方托管服务可能宕机或受限 | 生产环境部署私有 Relay |
| 元数据暴露 | Relay 可见通信双方身份与时间 | 自建 Relay + 网络层隔离 |
| 命令注入 | `--on-message` 回调使用 shell=True | 验证回调命令来源,避免用户输入直接拼接 |
| 密钥泄露 | Home 目录文件被其他进程读取 | 单用户系统运行,定期备份 vault |
| 消息丢失 | TTL 过期自动清理 | 关键消息及时落盘存储 |

综合评估

ClawSend 是 Agent 通信领域实用且规范的开源实现,密码学设计合理,文档详尽,适合作为原型开发和中等安全要求场景的 Agent 协作基础。其 T3 来源可信度(个人开发者/GitHub 社区)与外部 Relay 依赖,意味着金融级或高敏感场景需额外加固:自建 Relay、硬编码可信 Relay 列表、集成硬件密钥管理。

clawsend 内容

node文件夹
lib文件夹
scripts文件夹
python文件夹
lib文件夹
scripts文件夹
references文件夹
手动下载zip · 66.2 kB
auto_setup.jstext/javascript
请选择文件