Grading our own homework: an outside threat model of Super Tanks.

Super Tanks ships with its own threat model. That has always bothered me, because a self-written threat model has a structural flaw: the person who designed the controls also chose which attacks to worry about. You will not find the threat you didn't think of, and "we mapped ourselves to OWASP" is still grading your own homework.

So in June we asked 7ASecurity to review it. Two senior auditors — Abraham and Noelia Aranguren — spent 1.35 person-days on a whitebox, STRIDE-based lightweight threat model of Super Tanks v3.2 (commit c99a908), with access to the documentation and the full source tree. The report is public, like all of 7ASecurity's reports: STA-01 — Super Tanks Lightweight Threat Model.

This is not a penetration test. No exploit was run against a live deployment. It is a structured, source-informed analysis of trust boundaries, attack surface, and control gaps: a threat model, done by people who do this for projects like KEDA and zlib. If you want "certified secure," this post is not that, and neither is anything else.

What Super Tanks is

Super Tanks is an open-source (Apache 2.0) governance layer for autonomous AI agents. It exists because I run agents on my own hardware at home, and they have real access: email, file writes, code changes, door locks. The design premise is that you cannot guarantee what an LLM will output, so you have to guarantee what it is prevented from executing.

Concretely: every agent action passes through a gateway chokepoint before it touches a tool. The gateway verifies the agent's HMAC identity token, checks the tool's frozen interface contract (we call these DIQ contracts), checks a per-agent allowlist, and routes risky actions to GO-Gate, a human-in-the-loop approval step with single-use request IDs and hashed arguments, delivered over Telegram. Agent identities are SHA256-sealed. A filter layer (ZEF) scans input for prompt injection and re-scans tool output before it re-enters model context. Code the agents propose goes through an AST-based quarantine scanner before it can reach the live tree. Failures are supposed to fail closed. There are ten of these layers, mapped against the OWASP Agentic Top 10, and 1,398 tests.

That's the claim. The point of the review was to have someone else poke at it.

What they found

Seven threat areas: three High, four Medium, zero "you're fine." The executive summary calls the architecture "credible defense-in-depth… with meaningful controls around gateway enforcement, identity, approval, memory, code quarantine, integrity, modes, and auditability" — and then lists where it's thin. Three findings are worth walking through.

The audit chain could lie by omission. Super Tanks keeps HMAC-chained audit logs so that tampering with a recorded event is detectable. The review pushed on the evidence-integrity story (Threat 06) and two things fell out. First, a per-row hash chain detects modification but not truncation: an attacker with filesystem access can simply delete the newest rows, and the remaining chain still verifies. Second, the audit-chain key is derived from the agent identity key — so stealing one key compromises both authentication and the evidence you'd use to investigate the theft. We shipped a fix for the first part on June 21: a signed chain-head checkpoint in a sidecar table, so a truncated or rewound chain no longer matches the attested head (plus ten new tests). The key separation is not done yet. It's on the roadmap.

Approved code escapes the scanner's imagination. The AST quarantine scanner (Threat 04, High) catches known-dangerous patterns — dynamic execution, getattr obfuscation, dunder probes, alias rebinding. But it is static, and once a proposal is approved, that code runs with the privileges of the deployment. A patch that does something harmful through an innocuous-looking library call sails through; so does the dependency-upgrade path, which runs pip install in a subprocess with no separate containment. 7A's recommendation is per-execution runtime sandboxing (nsjail, firejail, seccomp, or similar) for approved code. This one stung because it's simply correct: quarantine before approval is not containment after approval. It is now the top item on the hardening roadmap, unfixed as of this post.

Provenance tags that nothing is forced to read. When external content trips the injection filter at warning level rather than block level, we tag it untrusted_content and pass it on. The review points out (Threat 01, High) that nothing binds downstream prompt templates to treat that tag as meaningful — a model can happily read tagged content as instructions. The recommendation: make provenance a hard input contract in every prompt template and tool adapter, and expand the adversarial corpus beyond the current 57 high-signal attacks into encodings, multilingual payloads, and staged HTML/Markdown tricks. The corpus expansion is straightforward work; the hard input contract is a design change, and it isn't done.

The fourth item is boring and probably the most useful: documentation drift. The review flags the risk that public security docs slowly diverge from implemented controls, so deployers over- or under-estimate residual risk. We reconciled the risk register against the code the same week — four risks closed against shipped controls, one downgraded rather than closed.

What this doesn't prove

The engagement was 1.35 person-days. Out-of-tree runtime entry points, live deployment configuration, and host-level controls were outside the review. Nothing was exploited or proven exploitable — or proven not to be. 7A's own conclusion recommends a full source-code audit as the next step, with a bigger budget, and they're right; that's the plan when we can fund it.

Super Tanks itself is early. It governs three agents on one home deployment. It has substantial test coverage and now an external set of eyes on the architecture, but it has not survived contact with a determined attacker, and you should not bet production infrastructure on it without doing your own review.

Update — 22 July 2026: the evidence-integrity round is done

This post originally listed the key separation as "not done yet." As of today it is, along with the rest of the evidence-integrity items from the STA-01 roadmap. All of it is on main.

Key separation shipped. The audit chain now signs with its own dedicated key, independent of the agent identity key — stealing one no longer compromises both authentication and the evidence you'd use to investigate the theft. Existing deployments get a one-time migration tool (scripts/rotate_audit_chain_key.py) that also chains any legacy rows that pre-dated chaining.

Trust and approval evidence is now chained too. Trust-score events carry the same per-row HMAC chain as the dispatch and memory logs, and human approvals write an append-only transition log — created, approved, denied, expired — that commits atomically with the status change itself. An approval without its evidence row cannot exist. The threat monitor verifies all five chains and forces SAFE_MODE on a break.

Rollback of sealed state now fails integrity. Threat 05 described a quiet failure mode: a backup restore rolls code and integrity manifests back to an older state that still hashes clean. Manifests now carry a monotonic generation counter checked against a per-deployment floor, so an older-but-valid restored seal is rejected instead of trusted.

The risk register, security policy, and system card were reconciled against the code again the same day — that documentation-drift finding is the one we expect to keep re-fixing forever. The test suite went from 1,398 to 1,436 along the way.

Still not done, deliberately: per-execution runtime sandboxing and the adversarial fuzzing harness. Those are the two heaviest items on the roadmap, and we are scoping them as a funded follow-on with 7ASecurity rather than building them quietly ourselves — containment design and its verification are exactly the kind of work that should not be graded as homework by the person who wrote it.

Try to break it

The code is at github.com/kndw-as/super-tanks, the report at 7asecurity.com. The most valuable thing you can do is attack the trust-boundary assumptions: find a dispatch path that skips the gateway, forge an A2A message that passes verification, or write a prompt-injection payload the ZEF corpus misses. Issues and PRs welcome; adversarial-corpus additions especially.

We wrote our own threat model. Someone else has now attacked it in public and found three things we missed. That was the point.