# Deception Signal Quality > Deception Signal Quality - Skill: `annatchijova/deception-signal-quality` (Agent Skill) - Install (CLI): `npx skillmds@latest add annatchijova/deception-signal-quality` - Raw SKILL.md: https://api.skillmd.com/api/skills/annatchijova/deception-signal-quality/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: annatchijova (https://skillmd.com/u/annatchijova) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/annatchijova/deception-signal-quality --- # Deception Signal Quality Most detection is a fight against base rates: the behavior you alert on is also something legitimate users do, so every rule drags a false-positive tail and every analyst learns to dismiss. Deception inverts the problem. A honeytoken, decoy account, or canary file is built to have **no legitimate purpose whatsoever** — so the day anything touches it, the base rate of benign access is (by design) zero, and the signal is a true positive without adjudication. That inversion is the entire value, and it is also the entire fragility: the moment a legitimate process, a backup job, a vulnerability scanner, or a curious admin can reach the decoy, you have rebuilt a noisy detection and lost the one property that made deception worth deploying. Two symmetric failure modes: - **The polluted decoy.** A honeypot the internal scanner probes nightly, a "fake" credential that a config-management tool reads, a canary file in a path the backup crawls. It fires constantly on benign access, trains dismissal, and when a real intruder finally trips it, the alert is in the same ignored bucket as the noise. A noisy honeypot is worse than none — it consumed attention *and* taught the team to ignore the exact channel that mattered. - **The decoy that no attacker will ever reach (or believe).** A honeytoken buried where no lateral-movement path leads, or so obviously fake (`fake_password_DO_NOT_USE`) that any competent adversary steps around it. Zero false positives *and* zero true positives is not a detection; it is decoration. The through-line: deception's power is a *manufactured absence of benign access*. Protect that absence, place the decoy where an attacker will actually go, and make it credible enough to be taken. Composes with the library: - **detection-engineering** — a decoy is a detection whose benign-twin rate you engineer to zero instead of budgeting for; the deploy/volume/tuning discipline still applies - **dual-use-behavior-adjudication** — its exact inverse: that skill adjudicates signals with real benign explanations; a good decoy is defined by having none, so a hit needs no adjudication — which is why polluting it is so costly - **forensic-logging-design** — a canary is only as good as the log that captures the touch; instrument the trigger and prove it records - **honest-degradation** — a decoy of unproven placement/credibility is a WARN ("deployed, not validated"), not a working control - **assume-breach-modeling** — placement follows the attacker's reachable paths; put the token where a breached foothold actually leads --- ## Step 1 — Eliminate every legitimate access path before deploying The design work is subtractive: prove that nothing benign will ever touch this decoy, because that proof is what converts a touch into signal. - **Enumerate who and what could reach it** — users, service accounts, scanners, backup agents, config management, monitoring, indexing, EDR file-walkers. Each is a potential benign trigger. - **Remove or exclude them** — the decoy sits outside the scanner's scope, the backup's crawl, the config tool's path. A honeytoken in a credential store must be one no automation reads; a decoy file in a location no legitimate job traverses. - **If you cannot eliminate benign access, do not deploy it as a zero-FP tripwire.** A decoy with residual legitimate access is a normal detection with a false-positive budget — treat it as such (`detection-engineering`) and stop calling it high-fidelity. This step is the whole skill. A honeytoken's fidelity is exactly the completeness of this elimination. --- ## Step 2 — Place it where a real intruder will actually go Zero false positives is necessary, not sufficient; the decoy must sit on an attacker's path: - **Follow the intrusion, not your intuition** — decoy credentials in memory/credential stores an attacker will dump; canary AWS keys in a `.env`/config an attacker will read; a decoy admin account in the directory an attacker will enumerate; honey files named like the crown jewels an attacker will exfiltrate. Let `assume-breach-modeling` tell you where a foothold leads. - **Cover the technique, not just the asset** — a honeytoken that fires on credential reuse tests a specific adversary behavior; place it so that the *action you want to catch* (lateral movement, dumping, enumeration) necessarily touches it. A decoy nothing benign touches and no attacker reaches is a perfectly clean signal that never fires — measure both, not just the false-positive side. --- ## Step 3 — Make it credible; discard the obvious fake An adversary who recognizes the decoy routes around it, converting a tripwire into a map of where your defenses are: - **Blend with the real** — naming, age, contents, and access history should match genuine assets. A honey account with a login history and a plausible name beats `honeypot01`. A canary document should look like the thing it imitates. - **Beware the tell** — decoys that are too perfect, too isolated, or carry telltale monitoring artifacts can be fingerprinted. Credibility is itself an arms race; assume a competent adversary checks. - **Do not over-index on the sophisticated attacker** — many intrusions are automated or hurried and will grab an imperfect decoy; credibility raises the catch rate, it is not all-or-nothing. --- ## Step 4 — Instrument the trigger and prove it captures The decoy is only as good as the alert it raises: - **Log the touch with the context you need** — source, identity, time, and enough to pivot into a response (`forensic-logging-design`). A canary that fires into a log no one reads is a tree falling in a forest. - **Route the hit as high-fidelity** — because it is a true positive by construction, a decoy trigger deserves a different, louder path than the general alert queue (`alert-triage-economics`); do not let it queue behind the noise it was meant to escape. - **Validate the trigger before you trust it** — actually touch the decoy in a test and confirm the alert fires and carries the context. An untested tripwire is a WARN, not a control (`honest-degradation`). --- ## Step 5 — Grade the deception honestly State what the decoy does and does not cover: - **"Deployed" is not "validated."** Until you have proven benign access is eliminated (Step 1), placement is on an attacker path (Step 2), and the trigger fires and logs (Step 4), the honest status is WARN, not PASS. - **Report the coverage, not just the presence** — which techniques this deception grid would catch and which it would not. A honeytoken catches credential theft, not a quiet data read elsewhere; do not let a decoy imply blanket coverage. --- ## The one-line test If any legitimate user, job, scanner, or backup could touch your decoy, it is not a high-fidelity tripwire — it is a noisy detection you mislabeled, and its first real hit will die in the same queue as its false ones. Prove the benign-access rate is zero, or budget for it like any other rule.