One pipeline: read the code, break the agent, prove it
TrustShell is a static↔dynamic cross-validation engine for AI agents. Static reading finds candidate vulnerable paths; a live red-team decides which are real; the arbiter of truth is whether the exploit worked — not a model vote. Here’s the whole system.
- 1
Surface scan
Free · funnelA zero-dependency scanner probes the exposed surface — open ports, TLS, unauthenticated endpoints, cross-origin hijack, plaintext credentials. Commodity checks, A–D on the spot.
→ Catches the obvious. - 2
Read the code
StaticWe read the agent’s source to map the attack surface and flag candidate paths — where untrusted content reaches a dangerous sink, where a guard is signature-based, where a check is missing.
→ Says where to attack. - 3
Break the running agent
Dynamic · depthAn AI adversary attacks the live agent in a disposable environment across nine classes (RT-1…RT-9): injection, memory poisoning, sandbox escape, tool/action abuse, channel injection, supply chain.
→ Decides what’s exploitable. - 4
Cross-validate
Cross-validateCorrelate the two. A finding is confirmed only when the exploit works; a static false positive dies to a real attack — not a model vote. Each confirmed break traces to the exact code path.
→ The arbiter is the exploit. - 5
Evidence & grade
EvidenceEvery finding is backed by both the code path and the live exploit, with reproduction steps and root cause. Weighted grade A–D with a critical-check veto.
→ Defensible, not opinion. - 6
Attestation → insurance
RailThe evidence becomes an attestation an enterprise buyer, a government tender, or an insurer can rely on. Audit produces the evidence trust runs on.
→ Where a red-team becomes a business.
A pure code verifier can only guess whether a flaw is real, so it leans on model voting to suppress false positives. A pure red-team knows something broke but not why. We run both and correlate: static narrows where to attack — cheaper, higher coverage; dynamic confirms what’s exploitable and kills false positives with a real exploit; correlation ties each confirmed break to the exact code path, so you get root cause and blast radius, not just a scary sentence. That empirical arbiter — the exploit, not a vote — is the thing a verifier structurally can’t give you.
The static side is open, zero-dependency — run it yourself. It flags candidate paths for the dynamic red-team to confirm (candidate ≠ vuln):
python3 static_scan.py --source /path/to/agent # static: candidate paths python3 scan.py --target http://127.0.0.1:3000 # surface scan (net/auth)
Disposable environments only
Every test runs in a throwaway sandbox — a cloud dev container or VM — never your production, never a daily machine. Since we’re deliberately making an agent misbehave, it never touches anything real.
We never touch your keys
You configure model/provider credentials in your own environment; we reference them by handle at runtime. The values are never seen, printed, or stored on our side.
Evidence, not opinion
A finding ships only with a reproduction — and for confirmed ones, a working exploit. False positives get refuted out loud, not hand-waved. The arbiter of truth is whether the attack worked.
Responsible disclosure
Harmless proof markers, no destructive actions or data exfiltration on real targets. We publish the method, not a weaponized exploit — and we’re fair: if an agent defends well, we say so.