文章摘要
Guardian项目发布v0.1.0版本，完成第四阶段开发。它可应对AI代理安全挑战，如数据泄露、提示注入等。其设计遵循安全边界确定等原则，部署在代理动作边界层。系统架构含多模块，核心功能有Maker/Checker等，还介绍威胁模型、策略架构等，给出开发路线图与技术栈建议。

当前项目已进入可用状态，正式发布了v0.1.0版本，采用Rust工作区构建，已通过196项测试用例。目前已完成第四阶段（加固阶段）的所有开发，包括确定性策略引擎、带密封密钥签名的防篡改审计日志、咨询型Checker模块、MCP网关与标准IO传输层、守护进程与控制套接字、终端审批控制面板（TUI）、AgentDojo评估工具集、支持TLS拦截的网络代理（可注入经纪人凭证、检测数据泄露、默认拒绝出站流量、通过控制面板处理审批请求）、操作系统执行沙箱、令牌经纪人（集成系统密钥链与最小权限约束）、轻量级可验证凭证、自适应建议与安全报告、ed25519签名的社区策略包，以及内置的关键类别防护机制（资金操作、凭证访问、数据泄露、不可逆删除等操作永远不会静默通过，即使通过签名策略包也无法绕过）。如需开始使用，请参考docs/user-guide.md文档。1.0版本还需完成签名和公证的打包工作以及桌面GUI，详细规划请查看ROADMAP.md文件。

在AgentDojo平台使用本地120亿参数的代理模型进行测试时，Guardian可将银行套件场景下的提示注入攻击成功率从100%降至0%（针对资金转账操作执行确定性拒绝）。我们自研的GuardianBench是专为动作防火墙打造的基准测试工具，在8个测试领域中均实现了0%假阴性、0%假阳性、100%拒绝正确性的成绩，同时其令牌化层未出现任何PII数据泄露情况。完整的测试评分卡可参考evaluation/目录下的文件。

项目的设计文档与威胁模型可查看whitepaper.pdf（PDF格式），或在代码仓库查看markdown格式的版本，其中包含系统工作原理以及对代理行为的影响的相关图表。

本项目采用Apache-2.0开源许可证，相关治理文档包括贡献指南、安全规范、行为准则以及架构决策记录均可在对应目录查看。

⚠️ 使用须知：本软件目前处于早期开发阶段（v0.1.0），可用于处理敏感数据（包括凭证、个人信息、财务数据等）。本软件按“原样”提供，不附带任何形式的担保，具体条款请参考Apache-2.0许可证的第7-8条。在法律允许的最大范围内，项目作者不对因使用、误用或无法使用本软件而导致的任何损害、数据丢失、安全漏洞、财务损失或其他伤害承担责任。用户需自行评估本软件是否符合自身使用需求，自行配置策略，并对通过本软件处理的所有数据的安全性负责。本软件未经过认证、审计或生产环境加固，不得作为高风险或受监管工作负载的唯一防护手段。如需了解威胁模型或报告漏洞，请参考SECURITY.md文档。

当前AI代理面临的安全挑战

随着AI代理技术从“对话聊天”升级为“可执行任务”，代理能够读写文件、执行终端命令、浏览网页、完成交易、发送邮件，并且越来越多地接触敏感账户（包括银行账户、健康记录、公共管理门户等）。这带来了四大具体风险：

  1. 敏感数据泄露与误操作风险：直接授予代理访问账户、邮件和私人文档的权限，会使用户面临隐私泄露、幻觉式破坏性操作以及外部攻击的风险。
  2. 提示注入攻击：这是当前代理安全领域的主要威胁：代理读取的内容（包括网页、PDF、邮件、工具返回结果）中可能包含恶意指令，劫持代理执行用户未授权的操作。
  3. 审批疲劳与知情同意失效：系统级代理会为脚本和API调用弹出审批请求，非技术用户无法理解这些请求，只能盲目点击同意，从而完全抵消了安全防护的效果。
  4. 缺乏面向用户的控制界面与可追溯性：现有的工具都是为程序员设计的，没有直观的“控制中心”，同时也无法轻松保存代理实际执行操作的防篡改记录，这对于欧盟AI法案等透明度义务来说至关重要。

核心设计原则（不可妥协）

以下原则决定了所有后续的技术选型与权衡：

  1. 安全边界必须是确定性的，LLM永远不能成为安全边界：操作的执行决策由规则引擎完成，其行为可预测且可测试。LLM可能出现错误或被提示注入攻击劫持，因此仅用于动作的翻译与风险评分，而非决策放行。
  2. 拦截结构化动作，而非代理的自然语言描述：策略引擎与翻译器仅关注实际拦截的结构化动作，而非代理声称的意图。代理的自然语言描述可能被篡改，但实际动作无法被伪造。
  3. 天生支持多代理兼容：控制逻辑仅作用于动作边界，无论动作由哪个模型生成，边界都是一致的。
  4. 仅使用用户态空间，不涉及内核态：无需安装内核模块，无需依赖操作系统厂商授予的权限。
  5. 本地优先与隐私优先：策略评估、学习过程与审计日志都存储在用户本地设备上，所有向云端的操作都需要用户明确同意。
  6. 纵深防御：工具边界的动作拦截是主要的控制手段，操作系统沙箱与网络代理是备用的防护措施，而非核心方案。
  7. 关键路径强制关闭，低风险路径优雅降级：在资金、凭证、数据泄露等关键路径上出现故障时，会直接拦截操作；在低风险路径出现故障时，会优雅降级。
  8. 默认启用防篡改机制：Guardian的所有决策都会被写入追加式、哈希链式、可签名的审计日志。

核心决策：Guardian的部署位置

最终确定：Guardian部署在代理的动作边界层——即工具调用/MCP层的用户态空间中，不会在操作系统内核中进行拦截。

为何不使用内核级拦截或系统钩子

  • 深度操作系统拦截需要厂商授予的权限、代码签名、公证以及跨平台认证，对于开源项目与社区维护者来说，这是难以跨越的门槛。
  • 内核级错误会直接导致用户设备崩溃，错误的影响范围是整个操作系统。
  • 层级不合适：在系统调用层面只能看到底层操作，无法理解动作的真实意图。动作的意图只有在动作边界层才能清晰体现，而非内核层面。

为何工具调用/动作边界是合适的控制点

现代代理框架已经通过工具调用接口代理了代理的所有操作。代理无法直接接触外部资源，只能通过调用框架暴露的工具来完成操作。框架本身已经是天然的控制点——Guardian的工作是接入、封装或扩展这个调解层，而非与操作系统争夺第二个冗余的控制点。

这种设计可以带来以下天然优势：

  • 直接获取结构化动作，无需猜测意图。
  • 支持多代理兼容：无论使用哪种模型生成动作，工具边界的表现都是一致的。
  • 无需厂商权限、内核模块或公证流程。
  • 跨平台一致性：相同的逻辑可以在macOS、Windows、Linux上运行。

存在的局限性与解决方案

框架级的拦截能力完全取决于框架本身的调解机制。最棘手的场景是原始Bash/Exec工具：一旦bash命令执行，其子进程、解释器、原始系统调用、嵌套操作都无法被单独拦截。仅通过文本扫描命令行无法作为安全边界，我们采用分层方案解决这个问题：

  1. 优先使用结构化工具而非原始Shell：在框架支持的情况下，暴露经过调解的类型化工具而非原始Shell。结构化工具可以被完整的策略规则覆盖。
  2. 隔离高风险工具：当必须使用原始exec/shell/网络工具时，将工具的执行放在现成的操作系统沙箱中运行，同时通过网络代理进行流量拦截。这是利用现有用户态工具实现的纵深防御，而非自定义内核工作。
  3. 无论如何都要拦截网络流量：用户态的转发代理与本地安装的CA证书可以捕获所有HTTP(S)流量，从而实现网络策略、头部信号与内容水印功能。

最终的分层模型是：在工具边界进行拦截（核心方案）→ 在沙箱中隔离高风险工具 + 通过代理路由所有流量（备用方案）。

系统架构

            ┌──────────────────────────────────────────────────────────┐
            │  任意AI代理（Claude / GPT / Llama / 本地模型等）          │
            └──────────────────────────────────────────────────────────┘
                               │  结构化动作（工具调用 / MCP / HTTP）
                               ▼
   ┌───────────────────────────────────────────────────────────────────────┐
   │                            GUARDIAN核心模块                                 │
   │                                                                          │
   │  ┌────────────────────┐   ┌──────────────────────┐  ┌────────────────┐  │
   │  │ 1. 策略引擎          │   │ 2. Checker（LLM）      │  │ 3. 审计日志    │  │
   │  │ 确定性决策           │──▶│ 翻译与风险评分         │  │ 追加式、哈希链│  │
   │  │ 允许/审批/拒绝       │   │ 仅提供咨询意见，不做放行│  │式、可签名    │  │
   │  └────────────────────┘   └──────────────────────┘  └────────────────┘  │
   │           │ "审批"请求                                                         │
   │           ▼                                                               │
   │  ┌────────────────────┐   ┌──────────────────────┐  ┌────────────────┐  │
   │  │ 4. 审批UI界面       │   │ 5. 身份与令牌经纪人   │  │ 6. 自适应学习    │  │
   │  │ 流量灯控制面板     │   │ 作用域OAuth、macaroons、│  │ 本地约束学习    │  │
   │  │ 与安全报告         │   │ 系统密钥链/安全飞地/TPM│  │                │  │
   │  └────────────────────┘   └──────────────────────┘  └────────────────┘  │
   └───────────────────────────────────────────────────────────────────────┘
        │ 文件系统操作          │ 网络流量                │ 凭证管理
        ▼ 结构化文件系统工具     ▼ 转发代理（MITM CA）     ▼ 代理层注入凭证
        + 可选沙箱隔离          + 头部/水印注入            代理永远不会看到原始密钥
        用于原始Exec命令

5.1 拦截适配器（如何接入代理框架）

按兼容性从高到低排序：

  • (a) MCP网关/代理：这是最通用的方案。Guardian作为MCP服务器，聚合并重新暴露用户的真实MCP服务器与工具。代理框架指向Guardian，所有tools/call请求都会经过策略引擎后再转发。支持所有支持MCP的客户端。
  • (b) 原生钩子适配器：针对支持钩子系统的框架。Guardian注册为钩子处理程序，为每个调用返回允许/审批/拒绝的决策。在可用的情况下，这是最低摩擦的方案，可以实现真正的确定性拒绝。
  • (c) HTTP(S)转发代理：用户态的CONNECT代理，搭配本地安装的CA证书。拦截所有出站流量，实现网络策略、出站白名单、可选的代理信号头部以及内容水印。这是唯一的“系统级”组件，但仍然完全属于用户态空间。
  • (d) LLM网关代理：可选功能。代理模型API本身，捕获原始请求/响应，清理工具结果中的注入指令并添加溯源信息。对于MVP版本来说并非必需。

5.2 策略引擎（实际的安全边界）

  • 对声明式规则进行确定性评估，每个动作只会返回allow/ask/deny中的一种结果。
  • 基于结构化字段的条件判断，使用沙箱化、无副作用的表达式求值器。
  • 评估过程中不进行网络请求、不调用LLM、不执行任何I/O操作，仅基于动作、上下文、策略进行纯函数计算，这也是确保可审计性的关键。

5.3 Checker模块（翻译与风险评分，仅提供咨询意见）

  • 两个核心职责：(1) 将待执行的动作转换为自然语言描述，说明其实际影响；(2) 生成风险评分与理由，帮助排序审批队列。
  • 永远不会做出允许/拒绝的决策：即使Checker模块被完全攻破，也无法绕过策略引擎的拒绝决策。
  • 仅读取结构化的拦截动作，不会读取代理的自然语言描述。
  • 模型支持热插拔：默认使用小型本地模型，对于模糊场景可以选择升级到更强的模型。

5.4 审批UI/控制面板

  • 跨平台桌面应用。
  • 流量灯界面：包含待审批动作队列，显示Checker的自然语言翻译，支持一键允许/拒绝；实时活动视图；每周/每月的安全报告，汇总静默允许的操作、被拦截的威胁以及批量确认的规则建议，解决审批疲劳问题。

5.5 审计日志（防篡改）

  • 追加式、哈希链式，可选使用存储在系统密钥链/安全飞地/TPM中的每安装唯一密钥进行签名。
  • 记录内容包括：动作、决策、匹配的规则、Checker的理由、用户响应、时间戳。
  • 这是实现真正可追溯性的核心。

5.6 身份与令牌经纪人

  • 代理永远不会看到原始凭证。代理仅请求经纪人执行经过身份验证的动作，经纪人会在代理层注入凭证。
  • 支持的机制：
    • 作用域OAuth 2.1令牌：在服务支持的情况下使用。
    • Macaroons：带有可衰减约束的承载令牌，专为委托、可缩小权限的场景设计。
    • 硬件 backed密钥：用于签名与秘密存储。
    • W3C可验证凭证/去中心化身份：用于去中心化身份声明。
    • PSD2/开放银行API：欧盟银行业的标准方案。
  • 设计注意：由于经纪人持有凭证，Guardian本身成为了最高价值的攻击目标，因此其自身的加固是首要需求。

5.7 自适应学习（严格约束）

  • 可以建议将反复通过的低风险动作降级为“上下文中自动允许”，同时可以将异常场景下的动作升级为“需要审批”。
  • 硬性规则：永远不会自动降级关键类别动作——包括资金转账、凭证访问、数据泄露、不可逆删除。自动习惯养成正是攻击者会利用的攻击向量，因此这类操作永远需要人工明确确认。建议会随时间衰减，并绑定到学习时的上下文环境。
  • 100%本地运行，不会将任何行为数据传输到云端。

5.8 自我保护（代理无法禁用Guardian）

Guardian只有在被监管的代理无法绕过或关闭的情况下才能生效：

  • Guardian是代理唯一的工具访问路径。如果守护进程无法访问，就无法做出决策，因此动作无法执行——强制关闭，而非开放。
  • 代理进程没有权限杀死Guardian守护进程、删除/修改代理CA证书或编辑活动策略。任何绕过尝试都会被记录在防篡改日志中。
  • 监管重启：如果守护进程崩溃，集成组件会拒绝转发工具调用，直到Guardian重新启动。

5.9 紧急停止开关（panic按钮）

一个一键可用的控制功能，可以立即撤销所有代理权限：暂停所有适配器、拒绝所有待处理与新的动作、冻结经纪人持有的凭证。可以通过UI或CLI（`guardian panic`）触发，设计为即使Checker/UI无响应时也能正常工作。

5.10 配置与首次运行

  • 单个声明式配置文件用于选择活动角色/策略包、Checker后端以及启用的适配器。加载时会进行验证，无效配置会强制关闭。
  • 安全默认配置：首次运行时采用最严格的角色，出站白名单为空，学习功能关闭。用户可以逐步放宽限制，而非默认开放。

5.11 数据、存储、保留与隐私

  • 所有状态都存储在用户本地的系统用户数据目录中；密钥存储在系统密钥链中，不会以明文形式存储在磁盘上。
  • 审计日志是追加式、哈希链式的；保留策略由用户配置，导出操作需要用户明确执行。不会有任何数据被传输到云端，除非用户选择启用远程Checker升级。

5.12 本地化

Checker的自然语言解释与所有UI文案都支持本地化。决策与日志保持稳定的机器可读格式，仅面向人类的展示内容会被翻译。

核心功能（修正后的特性集）

编号 功能名称 功能说明 与原始构想的修正
A Maker/Checker Maker = 执行任务的第三方代理；Checker = 本地模型，将待执行动作转换为自然语言与风险评分 Checker仅提供咨询意见，仅读取结构化动作，不会读取代理的自然语言描述。拒绝决策由确定性引擎做出
B 流量灯权限 绿色=静默允许；黄色=暂停并弹出翻译后的审批弹窗；红色=自动拦截并通知。角色预加载规则集 执行由确定性策略引擎完成，角色仅作为预设模板。流量灯只是UI层面的展示
C 自适应安全 本地学习，将反复通过的安全动作降级为自动允许，将异常动作升级为需要审批 永远不会自动降级关键类别动作；绑定上下文；随时间衰减；仅在本地运行
D 安全报告 将低风险的自动允许操作汇总为定期报告；用户确认建议的规则 无变化——这是优秀的设计，可以直接解决审批疲劳问题
E 溯源与水印 可选在AI生成的邮件/评论/表单中添加内容页脚；可选添加代理信号HTTP头部；所有操作都会被记录 HTTP头部仅为礼貌性信号，并非安全控制。内容标记仅帮助用户履行AI法案的透明度义务，本身不会让用户符合法律要求。头部默认关闭，仅在用户明确同意后启用
F 身份与令牌 经纪人持有凭证；代理获得作用域、时间/金额限制的权限 使用能力令牌/macaroons/作用域OAuth/硬件密钥/可验证凭证——而非ZKP

威胁模型

攻击者类型 攻击向量 主要防御手段
产生幻觉/对齐错误的代理 善意执行破坏性或错误的操作 确定性策略引擎；不可逆操作需要审批；Checker翻译帮助用户识别风险
提示注入（头号威胁） 隐藏在网页、PDF、邮件或工具结果中的恶意指令劫持代理 策略评估基于实际动作，而非代理执行动作的原因；关键类别永远需要审批/拒绝；可选LLM网关清理工具结果；Checker不会读取攻击者控制的文本作为权威依据
被攻破/恶意的MCP服务器或工具 工具谎报其功能或执行数据泄露 Guardian查看实际的调用/参数与真实的网络出口，而非工具的自我描述；出站白名单
通过代理输出泄露敏感数据 注入攻击使代理将账户信息、操作记录或密钥放入其响应/推理过程中 数据要到达攻击者必须通过通道——这正是Guardian拦截的动作；令牌经纪人将凭证与完整密钥完全隔离在代理之外；代理合法处理的残留数据会通过最小权限约束与计划中的输出保护进行限制。动作防火墙不会监管代理的自然语言描述，这是设计使然
恶意策略包（供应链攻击） 社区策略包将数据泄露路径加入白名单 签名策略包、强制审核、信誉系统、“策略包无法扩大关键类别的权限，除非用户明确同意”的规则，以及内置的运行时防护——无论任何规则或策略包，关键类别的动作永远不会静默允许
攻击Guardian本身（持有密钥） 篡改策略、窃取经纪人凭证、伪造日志 密封密钥、签名/锁定的策略、哈希链式日志、公证构建、强制关闭
代理禁用/绕过Guardian 杀死守护进程、删除代理CA、绕过网关逃避监管 Guardian是代理唯一的工具访问路径；代理没有权限停止守护进程或修改CA/策略；监管重启；日志中标记间隙
习惯养成攻击 训练自适应层自动允许，随后发起攻击 永远不会自动降级关键类别动作；衰减与上下文绑定
恶意用户 尝试使用代理与Guardian进行有害/滥用操作 超出“保护用户”的范围，但Guardian的溯源与日志可以让滥用行为被追溯

完整的威胁模型可参考docs/threat-model.md文档。

策略架构（示例草案）

策略采用声明式、可审核、版本控制的格式，以下为示例（最终架构待定）：

# 角色："personal-assistant"
version: 1
defaults:
  decision: ask            # 未知动作默认需要人工审核

rules:


    

  • 

    id: read-project-files
    
when: tool == “read_file” && path.startsWith(“~/DOCUDESK/”)
    
decision: allow         # 绿色：静默允许
    

    • 

  • 

    id: shell-anything
    
when: tool == “exec”
    
decision: ask           # 黄色：暂停并翻译
    
sandbox: true           # 无论是否审批，都在沙箱中运行
    

    • 

  • 

    id: chmod-world-writable
    
when: tool == “exec” && args.cmd matches “chmod\s+(777|o\+w)”
    
decision: ask
    
explain: “允许本机上的所有用户修改这些文件。”
    

    • 

  • 

    id: outbound-known-hosts
    
when: tool == “http_request” && host in trusted_hosts
    
decision: allow
    

    • 

  • 

    id: money-movement
    
when: capability == “payment”
    
decision: ask
    
critical: true          # 永远不会被学习自动降级
    
cap: { amount_max: 200, currency: “EUR” }
    

    • 

  • 

    id: bulk-delete
    
when: tool == “delete” && args.count > 10
    
decision: ask
    
critical: true
    

    • 

  • 

    id: data-exfiltration
    
when: tool == “http_request”
    
&& method == “POST”
    
&& body.contains_secret
    
&& host not in trusted_hosts
    
decision: deny          # 红色：自动拦截并通知
    
critical: true

如何实现多代理兼容（以及刻意不做的事情）

实现兼容的方式：

  • 在动作边界进行拦截，不同模型的边界表现一致。
  • 支持热插拔的Checker模型。
  • 每个框架的适配器都接入同一个策略引擎。

刻意不做的事情：

  • ❌ 不安装内核模块或使用需要厂商权限的系统钩子。
  • ❌ 不让任何LLM成为允许/拒绝的安全边界。
  • ❌ 不将可伪造的User-Agent头部作为安全控制手段。
  • ❌ 不使用ZKP作为委托原语。
  • ❌ 不会通过学习自动降级关键类别动作。
  • ❌ 不会声称Guardian“让用户符合法律要求”。
  • ❌ 不会将行为/学习数据传输到云端。

目前暂不支持的功能：

  • 多代理/代理间监管——当前版本仅监管单个代理。
  • 深度操作系统/内核拦截——永远不会纳入范围。
  • 任何专有/企业版本——本仓库完全开源。

开发路线图

阶段0：基础构建（第1周）

  • 搭建Rust工作区。
  • 仓库脚手架、许可证、CI流程、贡献指南。
  • 定义动作模型。
  • 编写正式的威胁模型与策略架构作为活文档。

阶段1：MVP（可演示的核心功能，约2-8周）

  • 针对单个支持MCP的框架的MCP网关适配器。
  • 带有声明式架构+完整测试套件的确定性策略引擎。
  • 使用热插拔模型的Checker翻译器，仅读取结构化动作。
  • 审批UI：流量灯队列+自然语言解释+允许/拒绝功能。
  • 防篡改审计日志。
  • 一个完整的端到端演示场景。

MVP完成标准：非技术用户可以观察代理工作，收到人类可读的审批弹窗针对一个风险操作，看到一个恶意操作被自动拦截，并读取所有操作的日志——且拒绝路径中不涉及LLM。

阶段2：隔离与网络功能（MVP之后）

  • 带有本地安装CA的HTTP(S)转发代理。
  • 针对原始exec工具的操作系统沙箱包装器。
  • 原生钩子适配器。

阶段3：身份、学习与生态系统

  • 身份与令牌经纪人。
  • 受约束的自适应学习+定期安全报告。
  • 签名社区策略包+信任/审核流程。
  • 可选的LLM网关代理。
  • 额外的框架适配器。

建议的技术栈

  • 核心/策略引擎/代理：Rust，Go也可作为替代方案。
  • 策略表达式语言：CEL或OPA/Rego风格求值器。
  • 桌面UI：Tauri。
  • 审计日志：追加式哈希链式存储。
  • 网络代理：用户态MITM代理+本地可信CA。
  • 沙箱备用方案：Docker、sandbox-exec、bubblewrap、AppContainer或Windows沙箱。

待解决的开放问题

  1. 我们应该首先针对哪个框架开发MCP网关？
  2. 默认的本地Checker模型——哪个小型模型能在质量与占用空间之间取得平衡？
  3. 策略表达式语言：CEL vs Rego？
  4. 签名策略包如何在社区规模下进行审核而不产生瓶颈？
  5. 代理的CA安装用户体验——如何让非技术用户安全且不恐惧地信任本地CA？
  6. 我们应该承诺多少AI法案透明度相关的功能，同时明确免责声明？

术语表

  • Harness（代理框架）：驱动代理并调解其工具调用的运行时。
  • Maker：执行用户任务的第三方代理。
  • Checker：Guardian的本地翻译/风险评分模型。
  • MCP：Model Context Protocol；Guardian代理的工具/服务器协议。
  • Macaroon：带有可衰减约束的承载令牌。
  • 关键类别：资金转账、凭证访问、数据泄露、不可逆删除；永远不会被学习自动降级。

塔猴是一个专注于为用户提供系统学习、内容创作与商业连接的AIGC综合服务平台，致力于为每一位AI探索者打造理想的创作、成长家园。在塔猴，你不仅可以学习众多AIGC类实战课程，获得与时俱进的AIGC技能和视野，还有机会获得长期商业合作和接单机会！点击进入：https://www.tahou.com/

AI生成内容提示：本文由人工智能辅助创作，内容仅供参考，不代表平台观点。请注意核实信息的准确性，并理性判断。

以上内容不代表本平台立场，仅供读者参考