Installs into .claude/skills of the current project.
Are you the author of Security Verification Layer Discipline?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/nexuslinkproductions-security-verification-layer-discipline-yuri-os)
---
name: security-verification-layer-discipline
description: "When verifying security/enforcement/safety claims — each layer needs its own evidence; don't over-extend a verified claim to the next unverified layer"
---
# Security Verification Layer Discipline
## The Pattern
When verifying whether a guard/safety mechanism works, each LAYER of the claim requires its OWN evidence. Proving layer N does NOT prove layer N+1.
## Common layer gaps (where overclaims hide)
1. **Config-wired ≠ runtime-firing** — a hook existing in `.codex/config.toml` or `.claude/settings.json` doesn't prove it EXECUTES at runtime. Different harnesses (Claude Code vs Codex vs OMP) invoke hooks differently; each needs its own live E2E test.
2. **Code-routing ≠ hook-invokes-at-runtime** — tracing `functionA() → functionB() → evaluateToolCall()` in HEAD code proves the ROUTING, not that the harness actually calls `functionA()` when a tool runs.
3. **Catches-accidental ≠ adversarial-boundary** — a JS monkeypatch (`--require` shim) that stops accidental `fs.rmSync` is NOT a sandbox against adversarial in-process code (`process.binding`, cache-bust, native binaries).
4. **HEAD-committed ≠ on-disk-live** — `git show HEAD:path` proves committed content; it does NOT prove the file exists on disk in the working tree. When the tool filesystem view is partial/sandboxed, use multiple verification methods.
## Evidence standards (name them explicitly)
- **HEAD code-trace** (`git show HEAD:path | sed -n`) — proves committed code logic, nothing about runtime.
- **Live E2E test** (real tool event → observe block/allow) — proves the hook fires AND reaches the guard for a specific harness.
- **Runtime block-test under bypass flag** — proves the guard survives the specific bypass mechanism (e.g., `--dangerously-bypass-approvals-and-sandbox`).
- **On-disk check** (`test -f`, `ls`, NOT `git show`) — proves the file exists in the working tree.
## Rules
- Don't transfer evidence between harnesses (Claude Code live block ≠ Codex live block).
- Don't collapse tiers — state each harness/path separately with its own evidence standard.
- The conservative default for any unverified safety layer: assume UNGUARDED until the exact test that settles it passes.
- For destructive-op boundaries specifically: removing a safety precaution carries the burden of proof; the reversible default wins.
## Verification methodology
- `git grep` searches the WORKING TREE; when the working tree is unresolved (sandbox/partial view), it returns false negatives. Use `git show HEAD:path | sed -n` for reliable HEAD-content verification.
- `git ls-files --deleted` = empty means git considers the tree intact; if your `ls`/`find`/`test -f` disagree, YOUR tool view is the suspect, not the tree.
- When concluding 'fabrication' or 'does not exist': verify with MULTIPLE methods (git show, git ls-files, test -f) before drawing the negative conclusion. A wrong file extension in your search path produces a false negative that looks like a fabrication.