القائمة
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 المهني
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm 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 about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
| 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."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. A guard you cannot write a failing test against is not a boundary — it's a hope with a comment.