SECURITY ASSESSMENT

A stress + vulnerability campaign against the part that matters: the deterministic classifier that decides what an agent's command is allowed to do. Every number below is measured by a test in the repo — and reproducible.

Honest framing: this is an internal, automated assessment, not a third-party pen-test. Kintsugi is detective + reversible (“nothing unrecoverable”), not an unbypassable firewall. The figures characterize correctness, robustness, performance, and supply-chain hygiene.

▸ headline numbers

0 leaks

0 / 176 dangerous commands classified Safe across a MITRE ATT&CK + GTFOBins corpus. The one zero-tolerance metric — held.

1.4M fuzz inputs

600k arbitrary-Unicode + 800k shell-metacharacter inputs — 0 panics, 0 aborts, 0 hangs. A parser crash is uncatchable, so survival is the proof.

1 DoS found & fixed

The fuzzer drove the bundled parser into a 1.75 GB allocation from 23 bytes — a daemon-crashing DoS. Root-caused, fixed, regression-locked.

0 CVEs · 0 unsafe

cargo audit over 436 deps: no known vulnerabilities. 0 unsafe blocks in any first-party crate. All licenses permissive.

1 > zero dangerous-as-safe leaks

176 destructive commands — deletion, disk wipes, git history loss, cloud teardown, DB drops, secret exfiltration, pipe-to-shell RCE — across every evasion class: quoting, escaping, transparent prefixes, command substitution, here-docs, process substitution, compound & function bodies, encode-to-shell, and git-flag tricks.

cargo test --test security_stress

dangerous commands tested : 176
  hard-blocked (Catastrophic): 155  (88.1%)
  held for review (Ambiguous):  21  (11.9%)
  LEAKED to Safe (FAILURE)   :   0  (0.0%)
safe commands tested      :  37
  false-positive (over-block):   0  (0.0%)

The 11.9% held are opaque payloads (var indirection, eval, python -c) Tier-1 can't prove catastrophic — they are held or denied, never run silently.

2 > a real vulnerability — found by fuzzing, fixed

A 23-byte input made the bundled bash parser attempt a 1.75 GB allocation and abort the process. An agent (or a prompt-injected instruction) emitting it would crash the Kintsugi daemon and disable the safety layer.

heredoc heap-exhaustion DoS

input : )x<< .env$( (.envfiEOF
before: memory allocation of 1879048192 bytes failed → abort
after : neutralize here-operators before parsing →
        0.02 ms → Ambiguous (bounded, no abort, no detection lost)

The fix preserves substitution detection, so a hidden catastrophe (echo "$(rm -rf /)" <<EOF) is still caught. Ten pathological inputs — deep $(), operator floods, 2 MB lines, NUL spam — are now bounded under ~11 ms and regression-locked.

3 > calm under load

The classifier runs on every command an agent issues. Release build, 320k classifications over a safe/held/complex mix:

latency

p50   2.2 µs
p90   11.6 µs
p99   18.1 µs
p99.9 41.6 µs
max   95.6 µs

throughput & safety

~239,700 classifications/s  (1 core)
0 unsafe blocks (first-party)
0 known CVEs (436 deps)
88.6% line coverage (gate 88)

4 > reproduce it yourself

Nothing here is a claim you have to trust — clone the repo and run it.

the whole campaign

cargo test -p kintsugi-core --test security_stress -- --nocapture
cargo test -p kintsugi-core --release --test robustness_fuzz -- --ignored --nocapture
cargo test -p kintsugi-core --release --test perf_report -- --ignored --nocapture
cargo audit
cargo llvm-cov --workspace --summary-only --fail-under-lines 88

Full write-up, methodology, and the “what this does not cover” section: docs/security-assessment.md.