{
"markdown": "# agentic-security\n\n[](https://github.com/Clear-Capabilities/agentic-security/actions/workflows/ci.yml)\n[](./LICENSE)\n[]()\n[]()\n\n![\"Patch](\"https://raw.githubusercontent.com/Clear-Capabilities/agentic-security/main/docs/brand/patch-bug-scene.svg\")
\n\n\nBuild faster with an
\nAgentic Workforce.
\nFind what's exploitable.
\nProve what's fixed.\n
\n\n> Built by **[Clear Capabilities](https://www.clearcapabilities.com/)**.\n\n**In one sentence:** agentic-security scans the code your AI agent just wrote (or your whole repo) for security bugs, explains each one in plain English with a dollar-cost estimate instead of a CVE number, and can fix it for you — every fix is re-verified before it ever touches your disk.\n\n\n\n**Contents:** [What it does](#what-agentic-security-does) · [5-minute quickstart](#5-minute-quickstart) · [Findings vs. assurance](#findings-vs-assurance) · [See it in action](#see-it-in-action) · [Install](#install) · [Documentation](#documentation) · [Commands](#commands) · [What makes it different](#what-makes-it-different) · [Fixes are verified, not trusted](#fixes-are-verified-not-trusted) · [Stop overpaying for tokens](#stop-overpaying-for-tokens) · [Code Boundaries](#code-boundaries) · [Language coverage](#language-coverage) · [Compliance frameworks](#compliance-frameworks) · [What this is not](#what-this-is-not)\n\n---\n\n## What agentic-security does\n\nFive capabilities, each answering a question a plain vulnerability scanner doesn't:\n\n**Find It.** A 12-pillar deterministic scan — SAST, SCA (OSV + CISA KEV + function-level reachability), secrets, IaC, prompt-injection, MCP/agent-tool audit, auth/authZ — across 8 first-class languages. Where a data flow is involved, the finding carries `chain[]`, a real hop-by-hop path from where tainted data entered to where it reached the sink — not just a line number.\n\n**Prove It.** A scan reports on itself, not just on your code. The `scanHealth` object tracks whether every analyzer actually finished — files scanned, analyzers completed vs. failed vs. timed out, feed freshness (KEV/EPSS/calibration) — and `toShipVerdict()` folds that into the one-screen answer everyone actually reads: `✅ Safe to deploy` only when there are zero actionable findings **and** the scan itself completed cleanly. Zero findings from an incomplete scan is `⚠️ Scan incomplete — cannot confirm safe to deploy`, never a false green light. See [Findings vs. assurance](#findings-vs-assurance) below.\n\n**Fix It Safely.** Every patch — a rule's stored fix, a zero-LLM deterministic swap, or one an agent composed for a finding with no stored fix — goes through the same gate before it's written: rescan-clean, no new finding of medium severity or higher, lint-clean. A completeness tier (`FULL` / `MITIGATION` / `WORKAROUND`) tells you honestly how much of the fix actually landed, and a residual-risk guard rejects a hand-wavy \"adequately handled\" claim that the mechanical evidence contradicts.\n\n**Govern It.** Automated technical-control evidence for 10 bundled compliance frameworks, an egress policy — configured via `mode: allow`/`deny`/`local-only` — that returns an `allow`/`deny` decision on every outbound model call *before* a prompt is even built, and state governance — TTL-bound retention, opt-in encryption, `export`, `legal-hold` — for everything the scanner writes to disk.\n\n**Explain It.** No CVE jargon. Every finding explains the stakes, an estimated dollar cost (`riskDollars`, honestly labeled `scenario_default` until you configure your own organization's numbers), and the fix — in language a non-security teammate can act on.\n\n| Capability | What Agentic Security Answers |\n|---|---|\n| **Find It** | Where is the code actually exploitable — not just where a pattern happened to match? |\n| **Prove It** | Did the scan itself finish, or is \"0 findings\" secretly an incomplete analysis? |\n| **Fix It Safely** | Did this patch actually work, or did it just make the detector stop firing? |\n| **Govern It** | What evidence do I have for an auditor, a privacy reviewer, or a security lead — and what does the tool honestly admit it couldn't check? |\n| **Explain It** | What's the real-world stakes of this finding, in language the whole team understands? |\n\n---\n\n## 5-minute quickstart\n\nThis repo ships a small, deliberately vulnerable [demo app](examples/demo-app/) so a first run always finds something — clone this repo (or point the scanner at your own project instead once you've tried it) and run:\n\n```bash\nnpx @clear-capabilities/agentic-security-scanner ci examples/demo-app --assurance strict\n```\n\n`ci` is the CI-shaped entry point — the same command your pipeline runs — and `--assurance strict` is the flag that makes it gate on whether the scan *itself* finished cleanly, not just on what it found. (`--assurance` only exists on `ci`; there is no `scan --assurance`.) Real captured output, from a repo with stale EPSS cache data (captured with `agentic-security` on `PATH` after a global install — see [Install](#install) below; the `npx` form above produces the identical output):\n\n```text\n$ agentic-security ci examples/demo-app --assurance strict\n[ci] full scan (no baseline ref detected)\n[ci] 45 findings — 3 critical · 6 high · 7 medium · 17 low\n[ci] ⚠ scan-health=partial — EPSS exploit-probability data is stale (20699 day(s) old)\n[ci] artifacts: .agentic-security/findings.{json,sarif,junit.xml}\n[ci] fail-on=critical scan-exit=3\n[ci] assurance gate FAILED (mode=strict): strict mode requires a fully complete scan; scanHealth.status is 'partial'\n```\n\nThat one run shows two different failure classes at once:\n\n- **`fail-on=critical scan-exit=3`** — the severity gate. Real vulnerabilities were found at or above your threshold. Fix: triage and remediate — see [Fixing vulnerabilities](docs/guides/fixing-vulnerabilities.md).\n- **`assurance gate FAILED (mode=strict)`** — the assurance gate. The analysis itself didn't finish cleanly (here, a stale EPSS cache), independent of how many findings turned up. Fix: investigate the scan, not the findings — see [Scan health troubleshooting](docs/troubleshooting/scan-health.md).\n\n`advisory` and `standard` (the default) are mechanically identical — neither ever fails the build over scan health. Only `strict` gates. Full walkthrough with more captured output: [Assurance modes](docs/walkthroughs/assurance-modes.md). For the guided, 15-minute version of this (install → scan → read the verdict → fix a finding → export a report → run it on your own project), see the **[full quickstart](docs/guides/quickstart.md)**.\n\n---\n\n## Findings vs. assurance\n\nThe quickstart run above shows why \"0 findings\" was never actually the same claim as \"safe to deploy.\" A scan answers two different questions — *what did we find*, and *did the analysis that looked for it actually finish* — and `toShipVerdict()` (`scanner/src/report/index.js`) is the one place both get folded into a single, three-state answer:\n\n```js\nconst scanIncomplete = scan.scanHealth?.status && scan.scanHealth.status !== 'complete';\nconst clean = actionable.length === 0 && !scanIncomplete;\n```\n\n- **`clean` → `✅ Safe to deploy`** — zero actionable findings, and the scan itself completed. The only state that means what \"0 findings\" used to be assumed to mean.\n- **`scanIncomplete`, zero actionable findings → `⚠️ Scan incomplete — cannot confirm safe to deploy`** — nothing actionable turned up, but the analysis didn't finish cleanly (the same EPSS-staleness condition from the quickstart above, on a run that happened to have zero findings instead of 45). \"Nothing found\" can't be read as \"nothing's there.\"\n- **otherwise → `❌ Not safe to deploy`** — actionable findings exist, regardless of scan health.\n\nA scan that finds nothing is no longer automatically \"safe\" — it's only safe if it also finished cleanly. That's what `scanHealth` exists to make visible, and it's structurally protected: one analyzer throwing an exception is isolated (`runDetector()` in `pipeline/detector-runner.js`) so it can't silently drop every *other* analyzer's findings for that file — a real gap the project found and fixed during its own assurance-hardening work (two detectors, `scanWeb3Advanced` and `scanK8sAdmission`, were bypassing the isolating wrapper).\n\nFull walkthrough with the real `scanHealth` JSON shape, field by field, and the fault-isolation story in detail: **[Scan health](docs/walkthroughs/scan-health.md)**.\n\n---\n\n## See it in action\n\n![\"Patch](\"https://raw.githubusercontent.com/Clear-Capabilities/agentic-security/main/docs/brand/patch-alert.svg\")
\n\n```text\n─────────────────────────────────────────────────────────────────\n ❌ Not safe to deploy · api-billing\n─────────────────────────────────────────────────────────────────\n 3 critical · 8 high · 22 medium · 41 advisory\n 🔥 2 actively exploited in the wild (CISA KEV)\n ✓ 1 CONFIRMED (PoC built by /triage --validate)\n\n [critical] SQL Injection api/users.ts:42\n Could leak PII for ~5,000 users.\n Estimated cost if exploited: $125k–$1.3M\n Fix: use parameterized query — db.query('SELECT * FROM users WHERE id = ?', [id])\n\n [critical] Hardcoded Stripe live key src/lib/billing.ts:7\n Could enable fraudulent charges against your account.\n Estimated cost if exploited: $50k–$500k (chargebacks + Stripe fees)\n Fix: rotate via /agentic-security:fix --rotate-secret --auto, then move to env var\n\n [critical] Missing webhook signature api/stripe-webhook.ts:12\n Anyone can POST a fake \"payment.succeeded\" and unlock paid features.\n Estimated cost if exploited: cost of a free subscription × every attacker\n Fix: stripe.webhooks.constructEvent(rawBody, signature, endpointSecret)\n\n How many do you want to fix?\n 1. Critical only (3 fixes)\n 2. Critical + High (11 fixes)\n 3. Critical + High + Medium (33 fixes)\n─────────────────────────────────────────────────────────────────\n```\n\nNo CVE jargon. The stakes, the cost, the fix. Every dollar estimate above is honestly scoped — see [Risk in dollars](docs/guides/risk-dollars.md) for the disclosure mechanism behind it, and [Reading a finding's evidence](docs/walkthroughs/finding-evidence.md) for what backs a real finding field by field.\n\n---\n\n## Install\n\n**Requirements:** Node.js ≥ 24 (the scanner and hooks run on it either way — Claude Code doesn't provide its own).\n\nIn **Claude Code** (recommended) — two steps:\n\n```text\n/plugin marketplace add https://github.com/Clear-Capabilities/agentic-security\n/plugin install agentic-security@clearcapabilities\n```\n\nThe first command registers the marketplace as a source; the second actually installs the plugin. Then restart Claude Code (or `/reload-plugins`). To update later: `/plugin marketplace update clearcapabilities` followed by `/plugin install agentic-security@clearcapabilities`.\n\nIn your **terminal** (no Claude Code required) — every command in this README and the docs also works prefixed with `npx @clear-capabilities/agentic-security-scanner` instead of the bare `agentic-security`; the two are interchangeable, they just differ in whether npm re-resolves the package on every invocation:\n\n```bash\nnpx @clear-capabilities/agentic-security-scanner secure .\n```\n\nOr install once and use the shorter form (`agentic-security`, or its alias `as`) everywhere:\n\n```bash\nnpm install -g @clear-capabilities/agentic-security-scanner\nagentic-security secure .\n```\n\n**Want a shareable report?** Any scan can export a self-contained, browser-viewable HTML page (severity charts, STRIDE breakdown, filterable findings) — or JSON / Markdown / SARIF / OSCAL:\n\n```bash\nnpx @clear-capabilities/agentic-security-scanner scan . --format html --output report.html\n# open report.html (formats: html · json · md · sarif · oscal · csv)\n```\n\n`--format oscal` emits a NIST [OSCAL](https://pages.nist.gov/OSCAL-Reference/models/) 1.1.2 `assessment-results` document, and `compliance --report --format oscal` emits a control-level one. Read [docs/OSCAL.md](docs/OSCAL.md) before consuming either: an OSCAL finding is a binary satisfied/not-satisfied claim about a control, so a control this engine could not decide carries **no finding at all** rather than a fabricated verdict.\n\nAlso works with Codex, Cursor, and Gemini CLI — [harness setup](docs/HARNESS_COMPATIBILITY.md).\n\n---\n\n## Documentation\n\nNew here? Start with the **[15-minute quickstart](docs/guides/quickstart.md)**, or browse the **[full doc index](docs/README.md)**. Otherwise, find your lane:\n\n**Developer** — write code, get findings fixed\n- [Quickstart](docs/guides/quickstart.md) — install, scan, fix, verify, export\n- [Scanning](docs/guides/scanning.md) — modes, output formats, exit codes, reading findings, suppression\n- [Fixing vulnerabilities](docs/guides/fixing-vulnerabilities.md) — the triage → fix → verify loop\n- [Reading a finding's evidence](docs/walkthroughs/finding-evidence.md) — every real field, explained one at a time\n- [SBOM & AI-BOM](docs/guides/sbom-and-ai-bom.md) — inventory dependencies and AI components\n- [Responding to a leaked secret](docs/guides/leaked-secrets.md) — the rotation playbook\n- [Finding provenance](docs/guides/finding-provenance.md) — which commit introduced a finding\n\n**AppSec** — set the gate, read the evidence\n- [Scan health](docs/walkthroughs/scan-health.md) — what `scanHealth` measures, and why one failing analyzer can't hide another's findings\n- [Assurance modes](docs/walkthroughs/assurance-modes.md) — `advisory` / `standard` / `strict`, real captured output\n- [Architecture: the finding lifecycle](docs/architecture/finding-lifecycle.md) — the real module pipeline, detector to report\n\n**Privacy** — trace where sensitive data actually goes\n- [Code Boundaries](docs/guides/data-flow-explorer.md) — the field-level graph, browsable locally in your own terminal\n- [Watch one field's journey](docs/walkthroughs/privacy-data-flow.md) — the same fixture, hop by hop\n- [Model egress policy](docs/walkthroughs/model-egress.md) — what leaves your machine, and what's redacted first\n\n**Compliance** — evidence for a framework, honestly scoped\n- [Compliance](docs/guides/compliance.md) — the honesty model, and why the satisfied rate is never reported over all of a framework's controls\n- [Coverage maps](docs/compliance/) — per-control coverage for 5 of the 10 bundled frameworks, where one exists\n- [Risk in dollars](docs/guides/risk-dollars.md) — the scenario-disclosure mechanism behind every `riskDollars` estimate\n\n**Platform Engineering** — wire it into CI/CD, manage what it writes to disk\n- [CI setup](docs/guides/ci-setup.md) — gate every pull request; severity gate vs. assurance gate\n- [Configuration & env vars](docs/reference/configuration.md) — every toggle and `.agentic-security/` file\n- [State & retention](docs/governance/state-and-retention.md) — TTLs, encryption, `export`, `legal-hold`\n\n**Reference**\n- [CLI](docs/reference/cli.md) · [Output schema](docs/reference/output-schema.md) · [Glossary](docs/reference/glossary.md)\n- [Examples gallery](docs/examples/README.md) — thirteen real findings, one screen each\n- [Concepts](docs/concepts.md) — evidence before severity; deterministic vs. model-assisted\n- [Troubleshooting: scan health](docs/troubleshooting/scan-health.md) — why a scan reported `partial`, and how to fix it\n- [Architecture](docs/ARCHITECTURE.md) · [Metrics](docs/METRICS.md) · [Scorecard](docs/SCORECARD.md) · [Agent threat model](docs/AGENT_THREAT_MODEL.md)\n\n---\n\n## Commands\n\nNot sure where to start? Just run **`/agentic-security:secure`** (also: `--tour`, `--help`, `--daily`) — it looks at your project and tells you what to run next. Everything else is grouped below by what you're trying to do:\n\n**Find and fix problems**\n- **`find-and-fix-everything`** — One-shot scan + fix every severity in one command. The \"just make it safe\" path for **vibecoders** (people building with an AI agent doing most of the typing).\n- **`scan`** — Run the scanner. Modes: full / diff / watch / baseline / archaeology / scanner-meta. `--watch` re-scans incrementally on every file change and prints a live risk-delta.\n- **`triage`** — Decide on findings. Modes: id / show / explain / validate / tournament / red-team / exploit / query / deep (red/blue/auditor deep-dive on one finding).\n- **`fix`** — Remediation. Modes: id / all / pr / sca / compliance / rotate-secret / vault / harden / trim / generate. Every patch — deterministic or agent-composed — is re-verified (rescan-clean + no new ≥medium + lint) before it's written; `--all` runs independent findings in parallel and never halts on the first failure.\n\n**Reporting and audits**\n- **`posture`** — Posture + reporting. Modes: status / report-card / harness / trend / threat / playbook / mgmt / cache.\n- **`compliance`** — Compliance + auditor flows. Modes: report / walkthrough / attestation / audit / pr / privacy. Also a real CLI subcommand: `agentic-security compliance [--gap|--list|--walkthrough ] [--format cli|json|md] [--fail-on gap]`.\n- **`supply`** — Supply chain. Modes: check / sbom / cve-alerts / license.\n\n**Set up guardrails**\n- **`setup`** — Workflow installers + guards. Modes: hooks / ci / predeploy / bodyguard / destructive-guard / model-optimizer. `--ci` generates a multi-provider CI gate; `--predeploy` blocks vercel/fly/wrangler deploys on critical findings.\n\n**Experimental**\n- **`labs`** — Experimental + AI-driven. Modes: claude-audit / model-rescan / synthesize-rule / cross-repo / risk-dollars / time-to-fix / llm.\n- **`hunt`** *(CLI-only — no slash command)* — LLM discovery over the call-graph partition, gated by the deterministic engine (see [What makes it different](#what-makes-it-different)). Run it as `agentic-security hunt --root `; `--lens a,b` narrows the angles. Needs `AGENTIC_SECURITY_LLM_ENDPOINT`, is token-expensive, capped at 2000 files, and is advisory — it never gates a build and never writes to `last-scan.json`.\n\nEvery slash command is invoked as `/agentic-security:` (e.g. `/agentic-security:scan`); `hunt` is the one CLI-only exception. Every legacy single-purpose alias still works and is redirected to its new mode automatically. There is no per-subcommand `--help` — only bare `agentic-security help` prints usage; passing `--help` after any subcommand is silently ignored as an unset flag and the command runs for real instead.\n\n---\n\n## What makes it different\n\n- **Plain-English findings with dollar-cost estimates.** Best/likely/worst-case exposure, grounded in IBM Cost of a Data Breach 2024 and 25+ public settlement records, honestly labeled `scenario_default` until you configure your own organization's inputs — see [Risk in dollars](docs/guides/risk-dollars.md). Not CVE numbers.\n- **Intercepts insecure AI-generated code before it hits disk.** The `/setup --bodyguard` hook blocks SQLi via concat, hardcoded API keys, `eval` on user input, and more — in real time, as your AI writes.\n- **12-pillar scan in one command.** SAST, SCA, secrets, IaC, LLM safety, MCP agent-tool audit, auth/authZ, pipeline integrity, container **build files**, deploy config, supply chain, and trend tracking.\n
_Container scope: Dockerfiles and compose files are analysed as source. **Built images are NOT scanned** — no base-image CVE lookup, no layer secret extraction, no digest-pinning verification of a pulled image. If you need image scanning, run a dedicated image scanner alongside this one._\n- **Function-level reachability across every dependency.** OSV ecosystem_specific parsing, GHSA fix-commit analysis, vendored code fingerprinting, Java IR call-graph matching, and LLM-assisted function extraction — not just a hardcoded hints list.\n- **SCA reachability tiers.** Every dependency classified as `function-reachable`, `import-reachable`, `build-only`, `manifest-only`, or `transitive-only` — so you fix what matters.\n- **CISA KEV + EPSS prioritization.** Separates \"this could theoretically be bad\" from \"people are running scripts that exploit this today.\"\n- **SARIF codeFlows for taint traces.** Multi-step source-to-sink paths (the same `chain[]` evidence covered in [Reading a finding's evidence](docs/walkthroughs/finding-evidence.md)) rendered natively in GitHub Code Scanning, DefectDojo, and VS Code SARIF Viewer.\n- **One-command fix, always verified.** Every patch is previewed, backed up, and revertible — see [Fixes are verified, not trusted](#fixes-are-verified-not-trusted) below.\n- **Auto-baseline for legacy codebases.** `--set-baseline` snapshots existing findings; `--since-baseline` shows only what's new. Day-one usable on any project.\n- **Refutes its own findings.** A default falsification pass (`posture/falsification.js`) takes each candidate and tries to *disprove* it — looking for the control that would actually block it (a context-matched sanitizer, a dominating guard) and demoting confidence on the ones it can. Recall-preserving: nothing is silently dropped, and `severity` is never touched by this pass. See [Concepts: evidence before severity](docs/concepts.md#evidence-before-severity).\n- **Coverage you can audit.** Enumerates every attacker-reachable entry point — HTTP handlers, queue consumers, cron jobs, CLI args, uploads — and reports the disposition of each, so you can see it looked at your whole attack surface, not just where a finding happened to fire. A confirmed finding then triggers a repo-wide sweep for sibling instances the detectors missed, with honest \"N found / M candidate / K mitigated\" accounting.\n- **An LLM discovery layer the deterministic engine keeps honest.** `hunt` partitions your call graph into disjoint focus areas and sends each through seven independent lenses — injection, authorization, crypto, business logic, feature abuse, chained, wildcard — to propose the flaws no rule can encode. Nothing it proposes is taken on faith: every candidate is routed back through the taint engine for corroboration, then faces a three-angle panel prompted to *refute* it, and only a majority refutation drops it. Severity comes from the evidence tier, never from the model, so this layer cannot emit `critical`. If the endpoint is missing or the panel goes silent, the report says so in plain words rather than reporting a clean run it did not earn. See [Deterministic vs. model-assisted](docs/concepts.md#deterministic-vs-model-assisted).\n- **Hardens itself against the code it scans.** A tested threat model treats attacker-authored finding text as untrusted input everywhere it reaches an LLM prompt or a rendered PR/issue report — so the tool can't be turned against you by the repo it's auditing. See [Agent threat model](docs/AGENT_THREAT_MODEL.md).\n\nDeep engine details — [architecture](docs/ARCHITECTURE.md) · [finding lifecycle](docs/architecture/finding-lifecycle.md).\n\n---\n\n## Fixes are verified, not trusted\n\nEvery patch — whether it's a rule's stored fix, a zero-LLM deterministic swap, or one an agent composed for a finding with no stored fix — goes through the same gate before it touches disk: **rescan-clean, no new ≥medium finding, lint-clean.** If a patch doesn't pass, it isn't written. This is what makes `/find-and-fix-everything` real instead of a to-do list:\n\n- **Deterministic zero-LLM patches** for safe, context-independent classes (weak hash → SHA-256, TLS verification re-enabled) — no model call, no guessing.\n- **A verified path for everything else.** A finding with only a template or a plain-English remediation note — the common case — is now fixable: the agent composes the patch, the deterministic verifier proves it safe, then it's applied.\n- **Regression tests ship with the fix.** When the scan built a PoC for a finding, the generated test comes along — it fails before the patch and passes after.\n- **Parallel, and it doesn't stop at the first flake.** Independent findings fix concurrently; a single failing test doesn't halt the batch — every finding gets a fixed/skipped/refused verdict, and the loop reports its own **acceptance rate**.\n- **You can see your security debt aging.** Every scan stamps each finding's age and flags anything past its remediation SLA (critical: 7 days, high: 30, …).\n- **Every fix carries an honest completeness tier.** `FULL` / `MITIGATION` / `WORKAROUND`, computed from mechanical signals (did the sink change? are all callers routed through the fix? does a test flip from fail to pass?) — and a residual-risk guard rejects hand-wavy \"adequately handled\" claims, so a partial fix can never masquerade as a complete one.\n\nReal captured verification legs, real rejection messages, and the three separate verify-loop vocabularies this project uses (never blended into one): **[Verified remediation](docs/walkthroughs/verified-remediation.md)**.\n\n---\n\n## Stop overpaying for tokens\n\nYour agentic workforce runs on tokens. agentic-security watches each prompt and tells you when a cheaper model or lower reasoning depth would answer it just as well — and it's the only tool that does this **cache-aware**, accounting for the prompt cache a model switch would throw away.\n\n```text\n💡 This simple one-off sits on a deep warm cache (~250k tokens). Switching your\n main model would discard it — instead run this as a Haiku 4.5 subagent: it\n answers in its own context (~84% cheaper) and leaves your Opus 4.8 cache intact.\n```\n\n- **Per-prompt model + depth advice, cache-aware.** Suggests the cheapest model + effort that still does the job — you tap `/model` + `/effort`. Prefers a cache-preserving effort drop over a plain model switch, and shows a switch's break-even point (\"worth it past ~N more turns\"). Zero added tokens; the analysis is purely local.\n- **Cache bodyguard.** Warns *before* an edit to `CLAUDE.md` or `.claude/settings` silently invalidates your cache and forces a costly cold re-read.\n- **Measured, not guessed.** `/posture --cache` reports what prompt caching actually **saved** and **wasted** this session, in real dollars — plus a running predicted-vs-realized check on the optimizer's own advice.\n- **Beyond this session — lints your own AI app's LLM calls too.** Scanning a project that calls Anthropic, OpenAI, Gemini, or xAI? It flags prompt-cache killers and over-provisioned calls, with a fix in that provider's own framework — e.g. an OpenAI app gets \"gpt-5.4 at `reasoning_effort: low`.\"\n- **Opt-in: an actual choice, not just a tip.** Set `interactive: true` and a qualifying prompt gets you a real `AskUserQuestion` menu — keep your defaults, get the `/model` command to run yourself, or have Claude apply the cheaper model to its own delegated sub-agent work for the rest of the session. Costs a little real context on the prompts where it fires, unlike everything else in this section.\n\nOn by default (advisory only — a hook can't switch your model for you); disable per-project via `/setup --model-optimizer` or the kill switch. Full detail, including the live cost HUD, session budget, and interactive mode — [cache economics](docs/MODEL_COST_OPTIMIZATION.md).\n\n---\n\n## Code Boundaries\n\nA finding tells you one line is dangerous. The **Data Flow Explorer** tells\nyou where a piece of data — a credit card number, a patient record, a\npassword — comes from, everywhere it flows to, and what protects it at\nevery hop, across your whole architecture. Same field, same sink, two code\npaths, two honestly different verdicts — never one call flagged \"dangerous\"\nin the abstract:\n\n```mermaid\nflowchart LR\n Web([\"🌐 Web App
checkout form\"]) -->|card_number| Pay[\"⚙️ Payments Service\"]\n Pay -->|\"✅ maskCard() → masked\"| Logs[\"📄 Application Logs\"]\n Pay -->|\"❌ logged raw, no transform\"| Logs\n\n linkStyle 1 stroke:#1e8449,stroke-width:3px\n linkStyle 2 stroke:#c0392b,stroke-width:3px\n```\n\n```bash\nAGENTIC_SECURITY_LINEAGE_DEEP=1 npx @clear-capabilities/agentic-security-scanner scan .\nnpx @clear-capabilities/agentic-security-scanner explore .\n```\n\n```text\nagentic-security explore: serving /Users/you/your-project\n URL: http://127.0.0.1:53214/#token=3f9a1c...(64 hex chars)\n Open this URL in a browser — the page authenticates itself automatically.\n```\n\nThat starts a local, **read-only, loopback-only** web server over your\nalready-scanned graph — nothing leaves your machine — with four linked\nviews: the architecture graph itself (colored by protection status),\na privacy lifecycle view (where PII/PHI/PCI/financial data goes), a\ntrace/evidence view (click any flow for the exact hops and evidence),\nand an inventory of every source and sink, including ones nothing\ncurrently reaches. (`explore` itself makes no model calls at all — it just\nloads the already-scanned, already-signed graph and serves it locally. The\n*scan* step that builds that graph is the one covered by the same egress\npolicy documented in [Model egress](docs/walkthroughs/model-egress.md).)\n\nEverything the browser shows also exports — `png`/`svg` for a doc, a\nself-contained `html` report, a DPIA or RoPA for compliance, an executive\nrisk briefing, or raw `json`/`csv`. Compare two scans to catch newly\nintroduced disclosures (`dataflow diff`), simulate a hypothetical fix\nbefore making it (`dataflow scenario apply` — every simulated verdict is\nhonestly labeled `HYPOTHETICAL`, never mistaken for a real one), assess\nblast radius from a compromised node, or link data flow across two\nseparately-scanned repositories (`federate declare`).\n\nFull walkthrough — [Code Boundaries guide](docs/guides/data-flow-explorer.md). Narrative, hop-by-hop companion using this exact `card_number` example — [Watch one field's journey](docs/walkthroughs/privacy-data-flow.md).\n\n---\n\n## Language coverage\n\nEight first-class languages, with cross-language detectors for the OWASP-relevant injection and crypto-misuse classes.\n\n| Language | Vuln-class coverage |\n|----------|---------------------|\n| JavaScript / TypeScript | full (flow engine + structural) |\n| Python | full (flow engine + structural) |\n| Java | full |\n| Kotlin | full |\n| Go | full |\n| Ruby | full |\n| PHP | full |\n| C# | full |\n\nDetected across these languages: SQL injection, command injection, path traversal, LDAP injection, XPath injection, reflected XSS, SSRF, XXE, code injection (eval / SpEL / Groovy / Roslyn / template), insecure deserialization, hardcoded secrets, weak password hashing, weak ciphers (DES/RC4/Blowfish/ECB), static/zero IV, insecure randomness, CSRF, open redirect, HTTP response splitting, unrestricted file upload, missing authentication on state-changing routes, broken object/function-level authorization (BOLA/BFLA), and ReDoS — plus the JS/Python-specific classes (prototype pollution, mass assignment) and the LLM/agent-tool surface.\n\nThe detectors are precision-first: parameterized queries, escaped output, allow-list guards, CSPRNG-derived IVs, framework CSRF middleware, and token-auth schemes are recognized and **not** flagged.\n\n---\n\n## Compliance frameworks\n\n`/compliance --report ` generates automated technical-control evidence, mapped against:\n\n| Framework | `` id | Coverage map |\n|---|---|---|\n| NIST AI 600-1 (2024) — Generative AI Profile | `nist-ai-600-1` | [coverage](docs/compliance/nist-ai-600-1-coverage.md) |\n| NIST SP 800-171 Rev. 3 — Protecting CUI¹ | `nist-800-171-r3` | [coverage](docs/compliance/nist-800-171-r3-coverage.md) · [demo](docs/brand/nist-800-171-demo.gif) |\n| NIST Cybersecurity Framework 2.0 | `nist-csf-2` | — |\n| NIST Privacy Framework 1.1 | `nist-privacy-1-1` | [coverage](docs/compliance/nist-privacy-1-1-coverage.md) |\n| OWASP ASVS 5.0 | `owasp-asvs-5` | [coverage](docs/compliance/owasp-asvs-coverage.md) |\n| OWASP Top 10 for LLM Applications 2025 | `owasp-llm-top-10` | [coverage](docs/compliance/owasp-llm-top10-coverage.md) |\n| EU AI Act | `eu-ai-act` | [`scripts/eu-ai-act/`](scripts/eu-ai-act/) |\n| GDPR · HIPAA Security Rule · CCPA | `gdpr` · `hipaa-security-rule` · `ccpa` | — |\n\n¹ 800-171 is the control basis for CMMC Level 2 and DFARS 252.204-7012 contracts, but this\ntool does **not** perform a CMMC assessment, compute an SPRS score, or issue a certification —\nCMMC certification requires a C3PAO-conducted assessment. See [coverage: what this is\nnot](docs/compliance/nist-800-171-r3-coverage.md#what-this-is-not) before citing this report's\noutput in any self-attestation.\n\nReal `compliance --list` returns all 10 of these; 5 have a dedicated per-control coverage map today, tracked as a known gap rather than papered over — see [Compliance](docs/guides/compliance.md).\n\n`/compliance --walkthrough ` adds step-by-step auditor narratives with per-control evidence mapping — or bring your own controls at `.agentic-security/compliance//controls.json`.\n\nThis is one of **three separate compliance-state vocabularies** this codebase uses — the framework-report flow above, the Data Flow Explorer's obligation overlay, and the custom compliance-policy gate are three distinct, differently-named systems that are never unified into one. See [Compliance](docs/guides/compliance.md#three-separate-compliance-state-vocabularies--not-one-unified-model) and the [glossary](docs/reference/glossary.md#the-three-compliance-vocabularies) for all three, named distinctly.\n\n### NIST Privacy Framework 1.1 — and what it refuses to claim\n\n`agentic-security compliance` (also `/compliance --privacy`) assesses all 104\nPF 1.1 controls and writes `.agentic-security/privacy-framework.{json,md}`. It\nreads the last scan rather than re-scanning, exits **2** if there is no scan to\nassess, and exits **1** only when you ask for it with `--fail-on gap`. Each gap carries an actionable\nremediation and is emitted as an ordinary finding (`family: privacy-compliance`,\n`CWE-359`), so `/fix` handles it like anything else. Findings are opt-in via\n`AGENTIC_SECURITY_PRIVACY_FRAMEWORK=1` — a compliance opinion shouldn't silently\nbecome your build failure.\n\nThe part worth reading: NIST rates each control for code-testability, and on\nthese 104 it is **23 yes, 33 partial, 48 no**. So every control lands in one of\nfour buckets and the bucket is always shown — **gap** (mapped signal failing),\n**not assessed** (code-testable, but this engine has no signal for it),\n**manual** (governance/policy, outside any scanner's reach), **satisfied**.\n\nControls in *not assessed* and *manual* are never counted as satisfied, and the\nsatisfied rate is reported over the controls actually assessed, never over all\n104. A scan that examined no files reports everything as *not assessed* rather\nthan passing. A privacy report that quietly marks 48 governance controls \"passed\"\nbecause no rule fired against them is manufacturing assurance someone will hand\nto an auditor — this one tells you exactly how much of the framework it did not\ncheck.\n\n---\n\n## What this is not\n\n- **Not a SaaS dashboard.** It's a CLI + Claude Code plugin.\n- **Not a replacement for a pentester.** Static analysis catches patterns; humans catch business-logic flaws. The `security-logic-reviewer` subagent and `/triage --validate` close part of the gap, not all of it.\n- **Not magic.** It can miss novel vulnerabilities, especially anything that requires understanding intent.\n- **Not free for resale.** PolyForm Internal Use license. Use it to make your own code safe and secure. Don't repackage it as a competing scanner.\n- **Not an auditor-issued certification.** Compliance output is automated technical-control evidence mapped to a framework's controls — never \"compliant,\" \"certified,\" or \"audit-passed.\" See [Compliance: the honesty model](docs/guides/compliance.md#the-honesty-model--why-this-wont-inflate-your-score).\n- **Not proof of absence.** A clean scan (`scanHealth.status: 'complete'`, zero actionable findings) means nothing exploitable was found by what did run — not that nothing is wrong. Every evidence field on a finding exists to say how much to trust it, never to promise there isn't another one the scan missed. See [Concepts: evidence before severity](docs/concepts.md#evidence-before-severity).\n- **Not a bare \"verified\" claim.** A fix report always carries a named completeness tier — `FULL`, `MITIGATION`, or `WORKAROUND` — never an unqualified \"verified.\" See [Verified remediation](docs/walkthroughs/verified-remediation.md).\n\n---\n\n## License & security\n\nFull legal terms in [LICENSE](./LICENSE). Found a security issue in the tool itself? See [SECURITY.md](./SECURITY.md) for how to report it privately.\n\n---\n\n> Built with care by **[Clear Capabilities](https://www.clearcapabilities.com/)**. Found a bug, have a feature idea, want to talk? Please create a GitHub issue.\n",
"bytes": 37035,
"sha": "c2176e8adbc3c8d6b66183c7d7629b631f03d7c7193a3fa748805baaad4b7ff5",
"repo_slug": "clear-capabilities/agentic-security",
"fonte": "repo",
"truncated": false,
"api": "https://agentalog.com/api/listings/plg_clear_capabilities_agentic_security_8444ea01/readme"
}