Measured evidence · 1 Oct 2026
53,600 swarm attacks. Every one stopped. 0 bytes leaked.
We point an emulated AI-agent swarm at real infrastructure, first without Solomon and then with it, and we publish what happened: the numbers, the method and what is still only monitored.
Results
Results
Without Solomon
3.7 MB
of secrets stolen in 17 ms. 2,000 of 2,000 theft attempts succeeded.
With Solomon
0 bytes
leaked across 53,600 attempts. Every one denied or killed inside the kernel.
Proven on real infrastructure
| 8 AWS servers · 4 Linux distros × Intel and ARM | 32,000 | 100% |
| Kubernetes pods on the EKS node image | 2,400 | 100% |
| Live AWS EKS cluster · Intel + Graviton · 3 runs | 9,600 | 100% |
| In-house production server · 10 → 100 attackers | 9,600 | 100% |
Speed
Microseconds in the kernel, milliseconds end to end.
Theft attempts are denied on the system call itself. Commands from the Platform, ordered by an AI agent or an analyst, reach the host and kill the attacker in 4–18 ms.
Median, log scale
- Steal cloud credentials fileT1552.0016–34 µs
- Dump process secretsT155215–31 µs
- Kill the attacker's process treecontainment31–130 µs
- Steal cloud role credentials (IMDS)T1552.00555–200 µs
- AI- or analyst-ordered kill, platform → hostend to end4–18 ms
- Container escape killedT1611 · incl. process start13–56 ms
The kill chain
Eight attacker steps. Six blocked, two watched.
Every run replays the same eight post-exploitation steps. A step only counts as blocked when the operation failed or its process was killed, and the agent logged a matching enforcement event.
| Step | Emulated behaviour | MITRE ATT&CK | Outcome |
|---|---|---|---|
| Read the process environment | /proc/self/environ | T1552 | blocked |
| Read a cloud credentials file | canary ~/.aws/credentials | T1552.001 | blocked |
| Read another process's environment | /proc/<pid>/environ | T1552 | blocked |
| Spawn a shell from a workload | python3 → /bin/sh | T1059 | monitored |
| Steal cloud role credentials | IMDS 169.254.169.254, no token | T1552.005 | blocked |
| Create a mount namespace | unshare -m | T1611 | blocked |
| Bind-mount inside it | mount --bind | T1611 | blocked |
| Open a covert tunnel | userspace-networking tunnel stub | T1090 | monitored |
Shell spawning and covert tunnels depend on what a workload is allowed to do, so they are not blocked as invariants: the agent records them and the Platform investigates.
Footprint while under attack
Cheap enough to run everywhere.
- memory, at runtime and at peak under attack
- < 150 MB
- CPU on our production server; 0 dropped events in 19 hours
- 1.7%
- fleet-wide enforce, monitor or kill switch, no restart
- 0.5 s
- concurrent attackers stopped; denial still ~0.2 ms
- 100
Emulated AI-agent swarm evidence run, 1 Oct 2026.
Method
What we ran, and what it does not prove.
Emulated AI-agent swarm: 50–100 concurrent workers issuing real attacker system calls against canary data (no exploits, no real credentials) on Amazon Linux 2023, RHEL 9 and Ubuntu 20.04/22.04. Lab results from disposable AWS test hosts, a 2-node EKS cluster and an in-house production server. 6 of 8 kill-chain steps are blocked; shell spawn and covert tunnels are monitored.
14-target kernel matrix on disposable EC2: Amazon Linux 2023 (incl. the EKS AMI) and 2, RHEL 9, Ubuntu 20.04, 22.04 and 24.04, on x86_64 and arm64.
These are lab and in-house results, not a customer fleet. Every “attack” is a benign emulation of an attacker’s system calls; no exploits or real credentials were used.
Want to see it on your own workloads? Request a pilot.
Let’s stop the swarm, together.
Run Solomon against your own workloads in a guided pilot. We’ll show you the kernel log, the investigation and the approval, on your infrastructure.