القائمة
Use when containing untrusted or agent-generated execution, sandboxing a worker with write/exec tools, or judging whether a guard is actually a security boundary.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | structural-security-boundary |
| description | Use when containing untrusted or agent-generated execution, sandboxing a worker with write/exec tools, or judging whether a guard is actually a security boundary. |
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.
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:
EACCES on what it must not touch, a read-only mount, dropped capabilities plus seccomp, or a VM. A shared-kernel namespace or container reduces blast radius but does not fully contain a determined attacker (escapes are routine); treat it as a weaker tier than a separate UID + caps or a VM, not as "the boundary."EACCES writing the enforcement code, and a rejected push to the protected branch (branch protection, or a credential that structurally cannot merge — an authorization/remote error, not an OS one). Capture each denial as the evidence; a disposable checkout bounds accidents but is not, by itself, containment. (→ autonomous-self-improvement-loop-safety)A guard in the same trust domain as the attacker can be defeated by the attacker: string matching loses to obfuscation and laundering, and a same-privilege check can be overwritten by the very code it was meant to constrain. Only a mechanism enforced by a lower layer — the kernel, the filesystem, the build — holds when the actor is hostile rather than merely clumsy. That is why "we check the command" and "we told it not to" are speed bumps, not walls. And when you genuinely cannot reach the structural bar yet, an honestly labelled and test-pinned residual is worth more than a comfortable illusion: it tells the next reader exactly where the real edge is, instead of letting a cooperative guard be mistaken for containment until the day someone tests it.
Consider an agent platform that runs a write-capable worker. A command-pattern guard that denies dangerous actions is launderable — an attacker aliases the command or runs it through a subprocess and the pattern never matches — so that guard belongs as defense-in-depth that fails toward asking, not as the boundary. The boundary belongs in structure: run the worker under a separate identity, and own the privileged control state with an identity the worker cannot write, so even a fully subverted worker gets a permission error instead of forging authority. If that separate-identity isolation is not yet provisioned, the honest move is to name the gap as an explicit residual and pin it as a passing-by-design test, so "this is cooperative, not structural, until the identity split lands" cannot quietly harden into an unearned "secure." The shape generalizes to any stack: put the boundary in a layer the actor cannot reach, keep string guards as honest secondary friction, deny by default, and pin what you cannot yet enforce.
What a machine can check: the boundary, by failing through it. Tests where the sandboxed identity attempts the forbidden write or exec and pass only on the permission error; named residuals pinned as passing-by-design tests so a cooperative check can never masquerade as containment; CI running the worker under the restricted identity, not root. When the actor edits its own governing mechanism, the enforcement snapshot it runs under is pinned, and each denial is captured as evidence rather than asserted — a filesystem permission error (EACCES) writing the enforcement code, and a rejected push to the protected branch (an authorization/remote failure, not an OS error). A guard you cannot write a failing test against is not a boundary — it's a hope with a comment.
Use when shipping or handing off code — treat docs as a first-class deliverable — present-tense, diagrammed-as-code, verified against reality, reader-tested.
Use when making a load-bearing or security-relevant claim, or reusing inherited or unfamiliar code — treat recalled facts and unread code as unverified until re-grounded against the live source, and disposition every dangerous surface rather than eyeballing it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when an LLM or agent emits decisions or claims and you need to turn fuzzy output into a verifiable, regression-protected signal.
Use when the human's request rests on a premise you can check, contradicts evidence or a recorded principle, or proposes a direction you have not independently weighed — weigh the strongest alternative before taking a stance, challenge once with evidence before complying; their decision still wins.
Use when a live result contradicts the hoped-for story or a metric could be gamed — state what really works and never fake a green.