docs(egress): plan Wardnet outbound site reputation engine

docs/adr/2026-09-05-outbound-site-reputation-engine.md

@@ -0,0 +1,51 @@
+# ADR-2026-09-05-OUTBOUND-REPUTATION: Wardnet owns outbound site security reputation
+
+- Date: 2026-09-05
+- Status: Proposed for architectural review; not an implemented capability.
+- Scope: Wardnet security policy, threat evidence, and SOC accountability for outbound destinations.
+- Baseline: `main@a52ccd0a24a727d9349bb32def7713882d8cad1e`.
+- Product request: prevent internal users, services, and agents from contacting external services with adverse security reputation.
+
+## Context
+
+Wardnet already owns WAF/IDS/SOC gateway decisions, threat-intelligence ingestion, and DNSBL publishing. Its current `/gateway/{path}` evaluates an incoming request before forwarding to a configured upstream. That is not a company-wide outbound website reputation enforcement system. The current `ThreatIndicator` and `SecurityEvent` models also lack the complete destination, evidence-lifecycle, tenant, and policy-version contract proposed here.
+
+The objection to using Wardnet as a generic website-reputation utility is valid when it means putting crawler rankings, extraction difficulty, or an unrelated HTTP client into the WAF. It does not exclude a distinct security responsibility: deciding whether an identified internal workload may contact an external destination under current threat intelligence and organizational policy. This decision complements ingress WAF and IDS observations rather than reinterpreting them.
+
+Current owner evidence in [Wardnet #136](https://github.com/ContextualWisdomLab/wardnet/pull/136), [#115](https://github.com/ContextualWisdomLab/wardnet/pull/115), and [EgressWeave #237](https://github.com/ContextualWisdomLab/EgressWeave/issues/237) assigns reusable outbound HTTP destination/address, DNS, redirect, proxy, TLS, and resource authorization to EgressWeave. This ADR does not reverse that boundary. The EgressWeave GitHub Releases listing returned no releases during the 2026-09-06 review; an immutable compatible Rust-consumer contract is an integration prerequisite, not a reason to defer Wardnet's domain design or offline implementation.
+
+## Decision
+
+Add **Outbound Site Reputation** as a bounded security capability owned by Wardnet. Implement its future deterministic policy and evidence core in a separate Rust workspace crate, with Wardnet application adapters and a versioned evaluation surface. Keep it independently testable without network access, an LLM, or a sibling repository checkout.
+
+Wardnet owns destination maliciousness assessment, evidence admission and lifecycle, tenant/workload/purpose policy, scoped business exceptions, explanatory decisions, and SOC records. EgressWeave owns safe transport and connection authority. A policy enforcement point composes the two; neither product's allow decision can override the other's denial. Protect-mode forwarding requires authenticated context, an explicit Wardnet allow, a valid EgressWeave authorization bound to the actual connection, a current applicable evidence state with healthy required-source state, and the required audit reservation. A no-match `unknown` destination therefore does not require a fabricated matching indicator: it may receive a Wardnet allow only through an exact-scope valid business authorization while required evidence authorities remain healthy, after which transport and audit gates still apply.
+
+A reputation verdict is not proof that traffic was intercepted or blocked. Coverage and actual enforcement outcomes must be recorded separately. Company-wide protection requires an enforced network path; a voluntary SDK integration, DNS feed, or the present reverse-proxy endpoint alone is insufficient.
+
+The normative requirements, threat cases, and delivery boundaries are in the [design](../superpowers/specs/2026-09-05-outbound-site-reputation-design.md); the [implementation plan](../superpowers/plans/2026-09-05-outbound-site-reputation.md) divides independently testable slices.
+
+## Alternatives considered
+
+| Alternative | Benefit | Rejection or consequence |
+| --- | --- | --- |
+| Extend the existing WAF score/DNSBL matcher into a universal site score | Minimal apparent code change | Conflates request payload, source IP, destination identity, and evidence lifetimes. An IP DNSBL is not a domain/URL reputation model. |
+| Put maliciousness policy inside EgressWeave, or introduce a new mandatory general reputation service | Central-looking interface | Moves SOC/security authority into the transport owner or adds a premature independent deployment. External intelligence providers remain useful inputs, not owners of Wardnet business policy. |
+| Separate Wardnet reputation core with versioned transport integration | Explicit security responsibility, deterministic testing, reusable standalone Rust boundary | Selected. Requires disciplined schemas, interception coverage, and an immutable compatible transport contract before production integration. |
+
+## Safety and non-goals
+
+Unknown is not safe. Expired, deleted, revoked, unverifiable, or out-of-scope evidence cannot silently authorize traffic. Freshness and source health remain distinct from maliciousness. Correlated feeds are not independent votes; provider confidence is not a calibrated probability. Do not inherit `BLOCK_SCORE` or invent a weighted machine-learning score for this feature.
+
+Business exceptions are authenticated, exact-scope, expiring, audited grants for unknown destinations; they do not erase evidence or override hard threat or transport denials. No raw URLs containing credentials, request bodies, or tokens are exported to providers or ordinary logs.
+
+This capability does not own crawling, stealth, CAPTCHA solving, website popularity, content credibility, general HTTP transport, malware detonation, LLM routing, DLP, or a full secure-web-gateway product. CAPTCHA, robots rules, HTTP 403/429, domain novelty, and geography alone are not maliciousness evidence. Optional future analysis must use its canonical owner and cannot automatically widen enforcement authority.
+
+## Consequences and adoption
+
+The design adds a deliberate security bounded context without duplicating EgressWeave. It creates operating costs: feed licensing and freshness, false-positive handling, policy rollout, audit durability, and deployment coverage. Opaque HTTPS supports only the identities actually observed; full URL protection cannot be advertised without URL visibility.
+
+This documentation PR changes no runtime, deployment, dependency, or workflow. Its ADR remains Proposed until reviewed. Offline domain work can proceed independently; live enforcement is gated on the versioned owner contract and the plan's security acceptance. Existing preservation PRs are neither merged nor superseded by this record. PR #130 remains the sole writer of `docs/product-technical-gap-baseline.md`; this change does not create a competing ledger.
+
+## Evidence
+
+See [research and source traceability](../papers/outbound-site-reputation-sources.md). Protective DNS practice supports the security use case; DNS reputation research motivates evidence and temporal evaluation, not a claim that Wardnet already reproduces a published detector. Repository observations above describe the pinned baseline and inspected open work, not shipped future features.

docs/papers/outbound-site-reputation-sources.md

@@ -0,0 +1,68 @@
+# Outbound site reputation: research and source traceability
+
+Reviewed 2026-09-06. This register supports the [ADR](../adr/2026-09-05-outbound-site-reputation-engine.md) and [design](../superpowers/specs/2026-09-05-outbound-site-reputation-design.md). Engineering requirements and benchmark targets are Wardnet proposals, not claims that the cited systems or this repository already implement them.
+
+## R1. DNS reputation research
+
+Antonakakis, M., Perdisci, R., Dagon, D., Lee, W., & Feamster, N. (2010). Building a dynamic reputation system for DNS. In *19th USENIX Security Symposium*. USENIX Association. https://www.usenix.org/conference/usenixsecurity10/building-dynamic-reputation-system-dns
+
+Author-group overview: https://astrolavos.gatech.edu/2010/08/11/Building_a_Dynamic_Reputation_System_for_DNS/
+
+**Application:** Notos is relevant evidence that DNS reputation is a security-analysis problem, not a crawler-quality metric. Wardnet therefore keeps temporal evidence and separates address observations from domain assessment. **Limit:** This proposal does not reproduce Notos, adopt its trained model, or transfer its reported accuracy to Wardnet. Source-family and time-separated evaluation are project safeguards, not assertions that a feed match achieves those research results.
+
+## R2. Passive DNS analysis
+
+Bilge, L., Kirda, E., Kruegel, C., & Balduzzi, M. (2011). EXPOSURE: Finding malicious domains using passive DNS analysis. In *Network and Distributed System Security Symposium*. Internet Society. https://www.ndss-symposium.org/ndss2011/exposure-finding-malicious-domains-using-passive-dns-analysis/
+
+Author-institution record: https://www.eurecom.fr/en/publication/3281
+
+**Application:** The work concerns malicious-domain identification from passive DNS behavior. It motivates retaining observation provenance and evaluating detection over time rather than declaring every unseen domain benign. **Limit:** Passive-DNS analytics and a learned detector are not required for the first deterministic, proven-feed-based Wardnet implementation. No published detection rate is a product acceptance result.
+
+## R3. Threat-intelligence semantics
+
+Jordan, B., Piazza, R., & Darley, T. (Eds.). (2021, June 10). *STIX version 2.1* (OASIS Standard). OASIS Open. https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html
+
+**Application:** Sections on common properties, versioning, indicators, and markings distinguish creator confidence, validity, revocation, and distribution restrictions. Wardnet must preserve these dimensions instead of reducing all imported data to a permanent numeric score. Missing confidence is not a safety statement. **Limit:** A STIX-shaped payload is not automatically authentic, current, trustworthy, or authorized for a particular tenant; source admission remains necessary. Only supported patterns become enforcement material.
+
+## R4. Protective DNS operational guidance
+
+National Cyber Security Centre. (n.d.). *Protective DNS for the private sector*. Retrieved September 5, 2026, from https://www.ncsc.gov.uk/guidance/protective-dns-for-private-sector
+
+**Application:** Protective DNS addresses access to malicious destinations and provides operational security evidence. This supports Wardnet's outbound-security use case and the need to connect enforcement with monitoring and false-positive handling. **Limit:** DNS filtering is one control, not proof of complete traffic interception or visibility into encrypted URL paths. The proposed PEP and deployment acceptance must establish their own coverage.
+
+## R5. Malware URL intelligence
+
+abuse.ch. (n.d.). *URLhaus API*. Retrieved September 5, 2026, from https://urlhaus.abuse.ch/api/
+
+**Application:** A proven malware-URL source is a candidate input. A URL observation and a derived hostname block have different scopes; the adapter must retain that distinction and source notices. **Limit:** Eligibility, current API authentication, polling bounds and commercial use must be checked before enabling a provider. Community access is not an unlimited commercial redistribution grant. Do not send private per-request URLs to an external provider in v1.
+
+## R6. IOC lifecycle and provider access
+
+abuse.ch. (n.d.). *ThreatFox API*. Retrieved September 5, 2026, from https://threatfox.abuse.ch/api/
+
+**Application:** ThreatFox documents authenticated access and expiration of older indicators, illustrating why an imported IP must not remain a timeless verdict. Preserve source status and provenance rather than extending validity at every refresh. **Limit:** Provider-specific expiration is not a universal TTL for every source. Use the current access/usage contract, maintain TLS verification, and obtain any required commercial entitlement before production ingestion.
+
+## R7. Credential-bearing transport confidentiality
+
+MITRE. (2026). *CWE-319: Cleartext transmission of sensitive information* (CWE Version 4.20). https://cwe.mitre.org/data/definitions/319.html
+
+**Application:** CWE-319 identifies transmission of sensitive/security-critical data over cleartext channels as a confidentiality/integrity weakness and recommends reliable confidentiality-protecting cryptographic protocols for transmission. Wardnet therefore requires the released EgressWeave/PEP composition to prove authenticated encrypted transport before a credential-bearing hop; an initial HTTP request, HTTPS-to-HTTP downgrade, redirect, or retry must strip credentials before the unsafe hop or be rejected. **Limit:** Wardnet does not implement a second TLS stack or infer transport security from scheme text alone. The transport owner must supply the executable peer-bound proof, and deployment tests must observe zero credential bytes on cleartext paths.
+
+## Repository evidence and ownership
+
+Inspected protected Wardnet commit: `a52ccd0a24a727d9349bb32def7713882d8cad1e`.
+
+- [AGENTS.md](https://github.com/ContextualWisdomLab/wardnet/blob/a52ccd0a24a727d9349bb32def7713882d8cad1e/AGENTS.md): Rust-first, proven engines, configuration, research and governance constraints.
+- [Architecture](https://github.com/ContextualWisdomLab/wardnet/blob/a52ccd0a24a727d9349bb32def7713882d8cad1e/docs/architecture.md) and [core models](https://github.com/ContextualWisdomLab/wardnet/blob/a52ccd0a24a727d9349bb32def7713882d8cad1e/crates/waf-ids-core/src/lib.rs): actual gateway, ingestion, DNSBL and event baseline.
+- [Wardnet #136](https://github.com/ContextualWisdomLab/wardnet/pull/136) and [#115](https://github.com/ContextualWisdomLab/wardnet/pull/115): preserve consumer/feed evidence without a duplicate transport-policy owner.
+- [EgressWeave #237](https://github.com/ContextualWisdomLab/EgressWeave/issues/237): immutable Rust-compatible transport authorization contract. The [GitHub Releases listing](https://api.github.com/repos/ContextualWisdomLab/EgressWeave/releases?per_page=1) returned an empty array at review time; this observation is not a claim about every possible package registry.
+- [Wardnet #167](https://github.com/ContextualWisdomLab/wardnet/pull/167) and [#170](https://github.com/ContextualWisdomLab/wardnet/pull/170): ongoing MISP lifecycle and source-severity repairs, not presumed protected behavior.
+- [Wardnet #130](https://github.com/ContextualWisdomLab/wardnet/pull/130): sole product-gap ledger writer. The design PR adds separate documents and does not edit that ledger.
+
+Open PR/issue descriptions are dependency and ownership evidence as inspected on 2026-09-06, not immutable API releases or proof of shipped implementation. Re-read them before implementation.
+
+## Research artifact and redistribution decision
+
+No third-party PDF is committed in this documentation slice. USENIX makes the Notos paper openly accessible, but the reviewed page did not establish an explicit public-repository redistribution grant. The EXPOSURE institutional [copyright notice](https://www.eurecom.fr/en/publication/3281/copyright) permits personal use; that is not treated as permission to redistribute the full paper in this repository. Follow AGENTS.md's cite/link/original-summary fallback rather than infer rights from download availability.
+
+The STIX standard and CWE entry are cited in their normative/authoritative web forms; they are standards/weakness taxonomies, not academic-paper substitutes. Provider datasets, API examples and malicious samples are not vendored. Source-specific licensing, attribution, access controls and distribution markings must be recorded by any future adapter. This register contains original summaries and bibliographic references, not copied papers or datasets.