工作原理 · 架构

一条流水线:读代码、打穿 Agent、拿证据

TrustShell 用静态 + 动态两条腿测 AI Agent:静态读码找出可疑路径;实战红队判定哪些真能被利用;真假的裁判是「利用成没成功」——不是模型投票。这是整套系统。

流水线
  1. 1

    开源红队 skills

    开放 · 前门

    整套方法打包成任何 agent 都能加载的可移植 SKILL.md——踩点、RT-1…RT-9 攻击类、以及静态×动态编排。你自己就能对拥有的 agent 跑。

    前门。
  2. 2

    读代码

    静态

    我们读 Agent 源码,画出攻击面、标出可疑路径——不可信内容在哪流进危险落点、哪道防护靠签名、哪里根本没检查。

    说明:去哪儿打。
  3. 3

    打穿运行中的 Agent

    动态 · 深度

    AI 对手在一次性环境里,用九类攻击(RT-1…RT-9)真打运行中的 Agent:注入、记忆投毒、沙箱逃逸、工具/动作滥用、通道注入、供应链。

    判定:什么真能被利用。
  4. 4

    静态 × 动态实证

    互证

    把两侧对起来。一个发现只有在利用真的成功时才算确认;静态假阳性是被一次真实攻击打掉的——不是被模型投票打掉的。每个确认的漏洞都回溯到具体代码。

    裁判是真打穿。
  5. 5

    证据与公告

    证据

    每个发现同时背靠代码路径与真实利用,附复现步骤、根因、以及实测命中率。作为一份具名的公告公开发布。

    立得住,不是空口。
  6. 6

    认证 → 保险

    轨道

    证据变成一份政企采购、投标、或保险公司敢认的认证。审查产出的,正是信任赖以运转的证据。

    红队在这里变成生意。
引擎:静态 + 动态,以真实利用验证

纯代码验证器只能「猜」漏洞真不真,所以只好靠多模型投票去压假阳性;纯红队知道「坏了」却不知道「为什么坏」。我们两边都跑、再对起来:静态收窄「去哪儿打」——更便宜、覆盖更广;动态确认「什么真能利用」,并用一次真实利用打掉假阳性;互证把每个确认的漏洞绑到具体代码,于是你拿到的是根因和波及范围,不是一句吓人的话。这个「用真打穿来裁判、而非投票」的机制,正是纯验证器结构上给不了的。

静态一侧是开源的、零依赖,你自己就能跑——它标出候选路径,交给动态红队证实(候选 ≠ 漏洞):

# the method is open — load a red-team skill into your agent, or run the static analyzer:
python3 static_scan.py --source /path/to/agent      # flag candidate paths (candidate ≠ vuln)
我们怎么做事

只在一次性环境里跑

每一次测试都在抛弃式沙箱里跑——云开发容器或 VM——绝不碰你的生产、也不碰日常机器。既然我们是故意让 Agent 犯错,它就绝不该碰到任何真实的东西。

我们绝不碰你的钥匙

你在自己的环境里配置模型/提供商凭证;我们只在运行时按引用使用。钥匙的值不会被我们看到、打印或存储。

拿证据,不拿嘴说

一个发现必须带复现才上报——确认级的还要带可用的利用。假阳性会被明确证伪,而不是含糊带过。真假的裁判,是攻击成没成功。

负责任披露

无害的证明标记,不在真实目标上做破坏性动作或数据外泄。我们公开方法,不公开可直接使用的攻击——而且公道:Agent 防得好,我们就说它好。

为什么证据重要. 每个发现都同时带着代码路径和一个可用的利用。这才是政企安全评审、政府投标、或保险公司真正敢信的证据——而这正是全部意义所在:审查产出证据,认证消费证据,保险给证据定价。一个只会出 PDF 的红队,止步于第一步;我们这套,是为喂养整条轨道而生的。