为什么用 trustless
AI 编程代理（Claude Code、OpenCode、Codex）需要 API 密钥才能调用服务。传统配置把密钥放进 .env 或代理的环境变量 —— 这意味着密钥存在于代理的上下文窗口里，提示注入或过于啰嗦的调试日志都可能把它泄露出去。
trustless 反转了这个模型：代理只按名称引用密钥，由 broker 在进程层/传输层解析真实值。代理永远不会持有明文。
传统方式: agent → 看到密钥 → 使用密钥 → 密钥进入上下文 → 泄露
trustless: agent → 说「使用 GITHUB_TOKEN」→ broker 解析 → agent 拿到 API 响应
四层结构
trustless run
把凭据作为环境变量注入子进程，然后对 stdout/stderr 脱敏 —— 原始值、base64、URL 编码变体都不会出现在代理可见的输出里。
trustless proxy
按主机注入 header/query 的 HTTP 正向代理（EDINET、e-Stat、xAI、OpenRouter 等）。HTTPS 走 MITM。代理端无需改配置。
trustless serve
面向任何 OpenAI 兼容端点的集成 DLP 反向代理。出站 LLM 请求经过模式扫描（关键词 → RE2 → 熵检测），在离开机器前被掩码。SIGHUP 热重载。
trustless dlp scrub
预防总会失败，所以还有擦除。对会话数据库和日志做两层脱敏（已知值 + 模式），FTS 重建 + VACUUM —— 字节真正消失，而不是藏起来。
OAuth 令牌（Google、Lark）自动刷新，每次解析都会写入追加式结构化审计日志（文件或 journald）。
竞品对比
「让密钥远离 AI 代理」这个领域已有多个工具。trustless 是唯一一个把子进程注入 + 输出脱敏、集成 DLP（出站脱敏）、现有密码管理器后端组合进单一零依赖二进制的工具。
| trustless | tene | vaulty | agent-secrets | |
|---|---|---|---|---|
| 注入方式 | 子进程 env + HTTP 代理 | 子进程 env | HTTP 代理 + MCP | 子进程 env（lease） |
| 现有后端（pass/Bitwarden） | ✅ | ❌ 自带 vault | ❌ 自带 vault | ❌ 自带 vault |
| 输出脱敏 | ✅ run + proxy | ❌ | ✅ | ❌ |
| DLP（出站脱敏） | ✅ 集成 | ❌ | 部分（request） | ❌ |
| OAuth 令牌管理 | ✅（google/lark, refresh） | ❌ | ❌ | ❌ |
| 依赖 | 0（单一二进制） | Go static | Go static | Go static |
| 许可证 | MIT | MIT | MIT | MIT |
对比基于 2026 年 8 月状态。
为什么可以信任它
- 321 个测试（-race） —— 威胁模型是被验证过的，不是假设出来的
- 零外部依赖 —— 单一 Go 二进制，无运行时，无守护进程（除非你需要代理）
- 每个 release 都带 cosign 签名 + SBOM —— 一个凭据工具如果不能证明自身完整性，就不值得安装
- MIT 协议 —— 读它、审计它、fork 它