RFC: opt-in deterministic guard for shell commands inside the Docker sandbox (destructive + secret-exfil, <2ms)

Hey team — big fan of SWE-agent's Docker-first execution model; container isolation is the right foundation. This is a proposal for a complementary layer on top of it, not a rework.

Context

Docker gives strong isolation against host escape, but the container boundary restricts where the agent can reach — it doesn't restrict what the agent does inside the sandbox it's legitimately allowed to touch. An agent with shell access can still:

• rm -rf . the repo it was asked to fix (irreversible, inside the container)
• read ~/.ssh/id_rsa, .env, *.pem if they're mounted in
• curl secrets to an undeclared host (egress is open in many setups)

This is the AI "confused deputy" problem: the agent holds legitimate access by design, so the fix can't be "ask the model nicely" — it has to be deterministic and below the model.

What I'm proposing

Grimdall (MIT) is a deterministic policy checkpoint that AST-parses shell commands and enforces policy regardless of what the sandbox allows:

• blocks destructive commands (rm -rf, dd, mkfs) and secret reads (~/.ssh/*, ~/.aws/*, .env, *.pem) — validated case: aider #5076
• blocks egress to undeclared hosts
• <2ms overhead, no LLM in the hot path
• shadow mode by default — logs what it would block, zero behavior change unless enabled

OS sandboxing is the car; Grimdall is the seatbelt. You want both.

Proposed integration (small, opt-in)

SWE-agent already has a tool/command dispatch path. Wrap it behind an opt-in flag:

• off by default — zero behavior change
• shadow-mode sub-flag to observe before enforcing
• denial returned as tool output, so the agent can react and retry within policy

Would you be open to a small PR? Happy to write tests/docs and keep it atomic.