核心用法
Clawvisor 作为代理与外部服务（Gmail、Calendar、Drive、GitHub、iMessage 等）之间的安全网关，通过三层机制实现精细化访问控制：
1. 凭据托管（Credential Vaulting）：所有 API 密钥和 OAuth 令牌由 Clawvisor 集中管理，代理仅通过 CLAWVISOR_AGENT_TOKEN 发起请求，永不直接接触用户凭据。
2. 任务级授权（Task-Scoped Authorization）：每次工作流需先声明任务（Task），定义用途（purpose）、授权动作（authorized_actions）和预期用途（expected_use）。任务需经用户审批后激活，支持临时任务（30分钟 TTL）和长期任务（standing tasks）。
3. 人类审批流（Human-in-the-Loop）：敏感操作（如发送邮件）需逐条审批；读操作在满足任务范围且通过意图验证后可自动执行。
典型工作流
获取服务目录 → 创建任务（?wait=true 阻塞等待审批）→ 网关请求（?wait=true）→ 完成任务
关键安全特性
- 链式上下文验证（Chain Context Verification）：通过
session_id追踪多步流程中的实体引用（如邮件 ID），防止攻击者利用历史结果伪造后续请求 - 意图验证（Intent Verification）：LLM 审核
reason字段，检测提示注入攻击；strict/lenient/off三档可调 - 来源追踪（data_origin）：处理外部数据时必须标注来源（如邮件 ID、网页 URL），用于安全取证
- 限制策略（Restrictions）：用户可设置硬阻断规则，匹配时立即拒绝
显著优点
| 维度 | 优势 |
|------|------|
| **安全架构** | 代理零接触凭据，消除密钥泄露风险；双层授权（限制+任务）提供纵深防御 |
| **可见性** | 完整的审计日志，每条请求附理由（reason）和上下文 |
| **灵活性** | 支持批量请求（最多20条并发）、范围扩展（scope expansion）、长期任务 |
| **防注入** | 专门针对 LLM 代理设计，识别"用户让我做的"等注入模式 |
| **合规友好** | 人类审批、任务 TTL、自动清理机制满足企业合规要求 |
潜在缺点与局限性
- 运维复杂度：需自建或托管 Clawvisor 服务，配置
CLAWVISOR_URL、CLAWVISOR_AGENT_TOKEN等环境变量 - 延迟开销：任务审批和意图验证引入额外延迟，不适合实时性极高的场景
- 生态限制：目前仅支持 Gmail、Calendar、Drive、Contacts、GitHub、iMessage（macOS），扩展性依赖官方适配器
- 学习曲线：
purpose/expected_use/reason等字段需遵循特定写作规范，否则易被验证器拒绝 - 单点风险：
CLAWVISOR_AGENT_TOKEN为高权限凭证，泄露则代理可访问所有激活服务
适合人群
- 企业安全团队：需为 AI 代理实施最小权限原则（PoLP）和审计追踪
- 高敏感数据处理场景：如邮件自动化、日历管理涉及商业机密或个人隐私
- 合规要求严格的组织：金融、医疗、法律等需人类监督的自动化流程
- 多账户管理用户：需批量操作多个 Gmail/Google Workspace 账户
常规风险
| 风险类型 | 说明 | 缓解措施 |
|----------|------|----------|
| Agent Token 泄露 | `CLAWVISOR_AGENT_TOKEN` 权限过高 | 专用令牌、最小服务范围、定期轮换 |
| 任务范围过度授权 | `authorized_actions` 过于宽泛 | 按任务复杂度精确限定范围，及时完成任务 |
| 提示注入绕过 | 精心构造的 `reason` 欺骗验证器 | 禁用 `"用户让我"` 等表述，依赖链式上下文 |
| 长期任务累积 | standing tasks 长期有效增加攻击面 | 定期审计、及时撤销、强制 session_id |
| 下游服务故障 | Adapter 层错误传播 | 正确处理 `ADAPTER_ERROR`，不静默重试 |
安全等级说明
- 来源可信度 T2：开源项目（GitHub），有完整文档和明确的安全模型设计，但尚未广泛生产验证
- 安全等级 A：多层授权、凭据托管、审计追踪、注入防护等机制完善，但 Agent Token 的高权限和单点架构存在潜在风险