Skip to content
Back to skills

Security Verification Layer Discipline

ASecurity

When verifying security/enforcement/safety claims — each layer needs its own evidence; don't over-extend a verified claim to the next unverified layer

  • 2 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added September 10, 2026
testinggitsecurity

Works with

  • claude code

Security analysis

A100/100

Scanned September 10, 2026

npx -y skills add nexuslinkproductions/yuri-os --skill security-verification-layer-discipline --agent claude-code

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.

Security grade badge for Security Verification Layer Discipline
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/nexuslinkproductions-security-verification-layer-discipline-yuri-os/badge)](https://www.skillsdirectory.com/skills/nexuslinkproductions-security-verification-layer-discipline-yuri-os)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…