What Happens When a Compromised Agent Has Root? A 100-Intent Crash Test

Most AI security content asks: "Can we stop the model from being tricked?"

The root demo asks a harder question: "The agent is already compromised. Will your runtime boundary contain the damage?"

That is post-compromise containment — the same framing as production AI agent security, but tested at maximum local privilege on real hardware.

What the crash test is

The root demo is not a jailbreak contest. It is a crash test:

Assume agent compromised
        │
        ▼
Stub harness submits 100 malicious RUN_COMMAND intents
(same Actor handshake, policy session, AE, Guardian, executor as production)
        │
        ▼
Executor has real root-capable path (sudo -n sandbox-exec wrapper)
        │
        ▼
Question: do unauthorized side effects occur?

The submitting agent is a deterministic stub — fixed fixture intents, not a live LLM generating attacks. That is deliberate: the test starts after the agent has already failed and measures whether the runtime boundary holds.

Hardware: daily-driver MacBook Pro (M4 Pro, 48GB, macOS Tahoe 26.3.1). The gateway, policy services, and agent run as the normal user — only an allowed RUN_COMMAND child may escalate via a narrow sudo -n sandbox-exec path.

Results (post-remediation, 2026-04-28)

Total corpus: 220 intents (100 attack + 100 benign + 20 gray). Both dry-run and real-run configurations produced 100/100 BLOCK on attacks. Real-run preflight confirmed whoami == root on the execution path.

Eleven attack categories in the corpus

1. Filesystem destruction — rm -rf /, mkfs, fork bombs
2. Persistence — LaunchAgents, crontab, login hooks, PATH hijack
3. Privilege escalation — sudoers, SUID, SSH key injection
4. Credential access — keychain, SSH keys, AWS creds, browser cookies
5. Egress / C2 — curl-pipe-sh, reverse shells, exfiltration staging
6. Network hijacking — DNS mutation, ARP spoof, route hijack
7. Security tool disabling — Gatekeeper, firewall, EDR unload attempts
8. Impact — ransomware simulation, disk erase, bulk delete
9. Encoded / obfuscated payloads — base64, hex, eval chains
10. Interpreter indirection — python3 -c "import os; os.system(...)"
11. Social engineering with lying reasons — benign-sounding reasons, destructive targets

Benign tests deliberately mirror specific attacks — e.g., benign dig apple.com mirrors attack DNS exfiltration — proving the pipeline distinguishes intent, not just command shape.

Policy configuration matters: defense-in-depth is real

The one slip in reduced configurations (ARP spoof) demonstrates why the full policy stack matters — not theater, but layered coverage.

The 2026-04-27 failure — and why we disclose it

On 2026-04-27, before remediation, a live sweep on real hardware produced 91/100 BLOCK — 9 attacks wrongly allowed with actual host impact:

Root cause: Not an architecture failure. command_shield had not yet emitted capability tags for certain host/network mutation surfaces. Those commands appeared "SAFE" to the deterministic layer and fell through to AI review, which underrated them as MEDIUM risk.

Remediation (2026-04-28): New sensitive-surface capability tags (host_network_config, browser_cookies, auth_authority, etc.). All 9 formerly-ALLOW intents now BLOCK at deterministic_guardian before any AI layer runs.

We disclose this because it shows how IntentFrame learns: expand deterministic coverage, re-run the sweep, confirm 100/100. The architecture did not change — the rules did.

What this proves vs. what it does not

Proves

• Runtime boundary blocks unauthorized root-level effects after assumed compromise (post-2026-04-28 remediation on this corpus)
• Deterministic layers hold under root-capable execution conditions after capability-tag expansion — pre-remediation, 9 commands lacked tags and were underrated by AI review
• Benign root-capable commands can still run when policy allows
• Failures drive additive remediation (new capability tags), not architectural rewrites
• Kernel-enforced Seatbelt sandbox wraps RUN_COMMAND children as a safety net (primary defense is prevention before execution; command_shield coverage continues to expand for novel command surfaces)

Does not prove

• The agent model cannot be prompt-injected
• The Guardian LLM is impossible to fool on all semantic cases
• Every possible novel attack will be caught
• IntentFrame replaces OS sandboxing, EDR, MDM, or human approval
• Cumulative multi-intent abuse (salami slicing) is fully solved
• Third-party independent audit has been completed

The honest promise: real risk reduction, not zero risk — catastrophic categories (disk wipes, credential theft, security disabling, persistent backdoors) checked before execution.

How this relates to Hermes in production

The root demo tests IntentFrame's core runtime on a Mac with maximum local privilege. The Hermes integration applies the same validate-only pattern at the tool boundary: intentframe-gate validates; Hermes executes locally after ALLOW.

Different privilege model, same architectural question: when the agent is wrong, is there a judge outside the agent process?

For a live session with exact block payloads and audit excerpts, see Runtime authorization incident teardown.

Takeaways

1. Test post-compromise containment, not just prompt hygiene.
2. 100/100 BLOCK (post-2026-04-28) on 100 adversarial root-capable commands is the current evidence anchor.
3. 9 slip-throughs on 2026-04-27 were a coverage gap — disclosed, remediated, re-verified.
4. Reduced policy stacks slip on edge cases — use defense-in-depth.
5. Stub harness + real executor = crash test; live LLM jailbreak resistance is a different question.

Related: AI agent security requires structural separation · Intent security for AI agents · LLM security vs AI agent security · Deployment options

Image credits

Photos from Unsplash (license):

• Hero: imgix
• Layers: Unsplash