structural-security-boundarylisted

# The Real Boundary Is Structural; String Guards Are Labelled Defense-in-Depth A guard that lives in the same trust domain as the actor it constrains is not a boundary — it is a speed bump the actor owns. Put the real boundary in a layer the actor cannot reach (a separate identity, a read-only mount, dropped capabilities, a VM), keep pattern/command guards as honest secondary friction that fails toward asking, and when you cannot yet reach the structural bar, label the residual and pin it as a test rather than letting a cooperative check masquerade as containment. ## When to use Reach for this whenever code you do not fully trust will execute: sandboxing an agent worker that holds write or shell tools, containing generated or third-party code, hardening a privileged registry or credential store, or answering "is this actually safe?" in a review. Red-flag thoughts — if you catch yourself thinking any of these, STOP and apply this skill: - "The regex blocks the dangerous command." (an alias, an obfuscation, or a subprocess slips it) - "The prompt tells the worker not to touch that file." (a prompt is not a boundary) - "It runs as the same user, but we check the path first." (same-privilege code can rewrite the check) - "We'll add a deny-list." (deny-lists enumerate the bypasses you thought of; the attacker finds the others) - "The isolation is structural." (is the separate UID / mount / namespace actually provisioned, or just planned?) - "I'll just hot-edit the guard while