When verifying security/enforcement/safety claims — each layer needs its own evidence; don't over-extend a verified claim to the next unverified layer
Scanned 9/10/2026
Install to Claude Code
npx -y skills add nexuslinkproductions/yuri-os --skill security-verification-layer-discipline --agent claude-codeInstalls 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 automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/nexuslinkproductions-security-verification-layer-discipline-yuri-os)More formats (shields.io, HTML) on the badges page.
---
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!