Privacy Threat Oracle

The governance layer of the Privacy OS spine (Projects/Privacy OS - Threat-Model Decision Engine in the source vault): a living threat model — adversary classes, identity compartments, cost-to-defend tiers — encoded as data, plus a deterministic decision layer over it. Where privacy-linter answers "does this content contain a leak," this answers "given who this identity is and who'd see it, should this disclosure happen at all."

Why this is deterministic-only, not model-based

Unlike privacy-linter's own still-unbuilt inference-cue class (privacy-linter's SKILL.md names it as deliberately out of scope, blocked on a local-model decision that hasn't been made — nothing in this repo produces it yet), this project's core design doesn't have the same wall: v1 evaluates already-structured facts about a proposed action (which compartment, which exposure, which content classes) against a fixed rule table — not raw disclosure content run past an external model. See ${CLAUDE_PLUGIN_ROOT}/references/decision-rubric.md for why the rule table is a ranked ordering rather than a weighted scoring function (the source project's own Open Question #2), and why structured-only input (not free text) is the deliberate v1 scope (Open Question #3).

How this works

python ${CLAUDE_PLUGIN_ROOT}/scripts/oracle.py \
  --source-compartment personal --target-compartment public_professional \
  --target-exposure public_internet --content-class direct_pii

1. Compartment violation check — does the target compartment fall outside what the source compartment may reference? All three compartments (public_professional, personal, sensitive_research) only reference themselves, per ${CLAUDE_PLUGIN_ROOT}/references/threat-model.json — full mutual isolation is the confirmed policy, not a v1 placeholder (see ${CLAUDE_PLUGIN_ROOT}/references/decision-rubric.md's Step 1).
2. Exposed adversaries — resolved from --target-exposure via the same file's target_exposure_map (e.g. public_internet reaches data brokers, criminals, employer, corporations, civil discovery, state actors, and autonomous adversarial AI agents — automated tools that scrape and correlate public content across compartments at machine scale, without needing a human to bother). Any exposed adversary flagged out_of_scope in threat-model.json (currently just the state actor — see ${CLAUDE_PLUGIN_ROOT}/references/decision-rubric.md's "Out-of-scope adversaries" section) still counts toward adversary_cost_tier and the recommendation like any other adversary, but is also surfaced separately in out_of_scope_adversaries_exposed and noted in reason — a flag this tool can't meaningfully help you defend against, called out rather than silently folded into the same bucket as one you can.
3. Sensitivity tier — the highest tier among --content-class values present (direct_pii/secret = high, metadata/inference_cue/stylometric = medium).
4. Recommendation — the rule table in ${CLAUDE_PLUGIN_ROOT}/references/decision-rubric.md, applied top to bottom: compartment violation + high sensitivity → decline; compartment violation alone → proceed_with_modification; high sensitivity reaching a high-cost-to-defend adversary → decline; and so on down to a clean proceed.
5. Reversibility — --reversible downgrades the recommendation one step (decline → proceed_with_modification, proceed_with_modification → proceed; never skips straight to an unqualified proceed on a compartment-violation-plus-high-sensitivity case — see ${CLAUDE_PLUGIN_ROOT}/references/decision-rubric.md's Step 4), modeling that a retractable action carries genuinely lower cost.

6. Plug in privacy-linter directly instead of naming content classes by hand:

   python ../privacy-linter/scripts/scan_diff.py --file draft_post.txt --json | \
     python ${CLAUDE_PLUGIN_ROOT}/scripts/oracle.py --source-compartment personal --target-compartment personal \
       --target-exposure public_internet --from-linter-json -

   This is the "wire oracle to Pre-Disclosure Linter for severity context" integration the source project named as a milestone — --from-linter-json reads a scan_diff.py --json payload (or any list of {"leak_class": ...} objects) and folds its finding classes into the sensitivity calculation, deduped. If the input can't be read (malformed JSON, wrong shape), the oracle fails closed, not open: it warns on stderr, sets linter_json_parse_error: true, and forces the sensitivity floor to high rather than silently falling back to "nothing sensitive found."

   Where each of the five content classes actually comes from — this only matters once, but matters precisely, since two of the five aren't what the earlier framing implied:

   • direct_pii, secret, metadata — confirmed (grep) as the only leak_class values privacy-linter's scan_diff.py ever emits. --from-linter-json genuinely plugs in directly for these three.
   • stylometric — not produced by privacy-linter. It's style-obfuscator's --emit-findings bridge that emits it (scripts/fingerprint.py), a separate skill with its own invocation. Piping privacy-linter's output alone will never produce this class.
   • inference_cue — produced by nothing in this repo yet. privacy-linter's own SKILL.md names it explicitly as out of scope, blocked on a local-model decision that hasn't been made. It's accepted as a --content-class value here so the rule table and threat-model.json's sensitivity tiers are ready for it, not because anything currently populates it automatically.
7. --json for machine-readable output; default is a short human-readable report.

This exits 0 by default — decline is the rule table's most severe label, not an automatically enforced block. --block-on {proceed_with_modification,decline} exits 1 instead, for a caller that wants the exit code to reflect the verdict (mirrors privacy-linter's own --block-on). See ${CLAUDE_PLUGIN_ROOT}/references/decision-rubric.md's closing note for why this is opt-in rather than a default-behavior change: nothing invokes oracle.py unattended today, unlike privacy-linter's git hook.

What's NOT built here

• Free-text proposed-action parsing. The original design's input was a sentence ("I want to post this to my public GitHub"); turning that into the five structured fields this script needs is a judgment call, not pattern-matching. Claude can do that translation conversationally before calling the script — a reasonable division of labor — but the script itself only accepts already-structured input. Not a silent scope cut: see ${CLAUDE_PLUGIN_ROOT}/references/decision-rubric.md's Inputs section for the reasoning.
• A calibration/validation pass against real expert judgment (source project's Open Question #5). The rule table is reasoned from the vault's existing threat-modeling concept pages, not yet tested against real proposed-action scenarios.
• Anything that actually calls oracle.py unattended. --block-on (see above) only matters once some scripted or automated context invokes this and checks its exit code — none does yet, unlike privacy-linter's git hook.
• Live editing of the vault's threat model. ${CLAUDE_PLUGIN_ROOT}/references/threat-model.json is the executable copy of the adversary/compartment schema already documented in Knowledge/AI/privacy-threat-modeling.md and the project page; keeping the two in sync by hand is the current state, the same relationship privacy-linter's references/leak-taxonomy.md has to its own scan_diff.py patterns.
• Any presence at the actual point of disclosure. This oracle, privacy-linter, and style-obfuscator all operate on something that has already touched disk — a file, a git diff, stdin. None of them have any presence at the moment content is actually composed: a GitHub PR description typed directly into the web UI, a LinkedIn post editor, a comment box. A PR description drafted in the browser and pasted straight into a gh/web submit is invisible to this entire stack, no matter how hardened any one tool is — this is a structural property of the architecture (local, file-based, explicitly user-invoked), not a gap any single tool's hardening closes. It's also, notably, not really the threat this stack was built against: the autonomous_ai_agent adversary's primary threat (above) is correlating content that's already public, not intercepting a draft pre-publish — this gap is closer to "did a human remember to run the check before hitting submit" than a detection problem. Considered and explicitly deferred rather than built: a browser extension hooking known compose boxes (real per-site DOM maintenance burden, and an extension with page-read access is itself a new privacy-sensitive surface — ironic for this toolkit) and a clipboard monitor (categorically more invasive than anything else here, which only ever acts on something the user explicitly named). A possible future direction, also not designed or scoped yet: a local LLM agent that sits closer to the point of disclosure and can actually read/flag a draft as it's composed, rather than requiring it to be staged to a file first — noted here as an idea worth revisiting, not a commitment.

Pairing

• privacy-linter — --from-linter-json consumes its --json output directly; 3 of the 5 content classes (direct_pii/secret/metadata) are genuinely its vocabulary, reused rather than reinvented — see "How this works" step 6 for the other two.
• style-obfuscator — the actual source of the stylometric content class, via its --emit-findings bridge (not privacy-linter, despite the similar-looking --json-payload shape both tools produce). Not currently wired together as a documented pipeline the way privacy-linter is — piping fingerprint.py --emit-findings output into --from-linter-json works today (the bridge targets the same {"leak_class": ...} shape), but nothing here shows that command yet.
• wiki-privacy-audit — a natural next integration (not built): running the oracle over a vault-wide audit's findings the same way it already runs over a single linter scan.

Files