docs(egress): plan Wardnet outbound site reputation engine - #173
docs(egress): plan Wardnet outbound site reputation engine#173seonghobae wants to merge 1 commit into
Conversation
Add a proposed ADR, product/technical design, six-slice implementation plan, and primary-source research register for Wardnet-owned outbound site security reputation. Preserve EgressWeave transport authority and make interception, evidence lifecycle, policy, and rollout gates explicit. Documentation only; no runtime or workflow changes.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reachedNext included review available in 56 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Product request
Plan and design a Wardnet-owned outbound site reputation engine so internal users, services, and agents do not contact destinations with adverse security reputation.
This remains a documentation-only architecture/design PR. It does not implement an engine, enable a proxy, change production traffic, or claim company-wide interception. The ADR remains Proposed rather than shipped architecture truth.
Architecture boundary
Outbound destination maliciousness, evidence lifecycle, organizational admission policy, and SOC accountability belong to Wardnet. EgressWeave remains the canonical owner of executable URL/address/DNS/peer, redirect, proxy, TLS/trust and resource authorization. A controlled enforcement point must compose both authorities before protected connect/send; neither allow can override the other's deny. A policy decision is not evidence that traffic was actually blocked.
The pure Rust reputation core and offline evidence/policy work may develop independently. Production transport integration requires an immutable compatible Rust-consumer boundary from
ContextualWisdomLab/EgressWeave#237or its verified successor. EgressWeave still exposes no immutable GitHub Release, so this PR cannot imply runtime enforcement or consume mutable owner source.Documents and security contract
The protected-main-relative delta remains exactly four Markdown files:
docs/adr/2026-09-05-outbound-site-reputation-engine.mddocs/superpowers/specs/2026-09-05-outbound-site-reputation-design.mddocs/superpowers/plans/2026-09-05-outbound-site-reputation.mddocs/papers/outbound-site-reputation-sources.mdThe design separates malicious/suspicious/unknown assessment, evidence health, policy action and actual enforcement outcome; binds decisions/cache entries to authenticated tenant/workload/purpose/canonical destination/revisions/observation scope/actual peer; preserves source confidence/lineage/validity/deletion/markings/licensing; requires every redirected/coalesced/new authority to be rechecked; fails protected traffic closed when required authority/evidence/audit is unavailable; and retains explicit CONNECT/opaque-HTTPS/direct-egress/encrypted-DNS/QUIC/proxy limitations and hostile zero-upstream-hit/rollback/replay/cross-tenant/false-positive tests.
#130 remains the sole product-gap ledger writer. #136/#115 preserve Wardnet consumer/feed evidence but their local reusable transport policy is not adopted. Merged #171 now establishes the complementary protected-main boundary: anti-bot browser acquisition/challenge handling stays outside Wardnet while destination maliciousness/reputation policy and evidence remain Wardnet-owned.
Exact state — 2026-09-06 KST
Protected
mainadvanced through #171 from5829a0f08d78de464dd24393ce5d0f25fba9d126to verified squasha52ccd0a24a727d9349bb32def7713882d8cad1e. This PR's source head is unchanged ata14b28a10ea87dbcc1939fe0fdca6ce5b02259ed; a fresh GitHub mergeability computation after the base advance ismergeable=true, and the four-file delta does not overlap #171's two-file anti-bot ADR/index delta. The prior repository-owned workflows remain exact-source-head evidence from before the base advance and therefore are not treated as final candidate-base admission evidence:33949463493— SUCCESS;33949463487— SUCCESS;33949463505— SUCCESS;33949463499— SUCCESS;33949463529— SUCCESS.Required central OpenCode workflow
33949463777is terminal FAILURE, but the earlierrunner_id=0diagnosis is superseded.opencode-reviewjob101340969657acquired Ubuntu 24.04, completed bootstrap/exact-head admission and coverage evidence, obtained OIDC, exchanged a repository-scoped app token, and successfully dispatchedopencode-reviewtoContextualWisdomLab/.github. It then failed closed because no authenticated exact-headAPPROVEDorCHANGES_REQUESTEDverdict fromopencode-agenthad been published for#173@a14b28a10ea87dbcc1939fe0fdca6ce5b02259edwhen the admission check ran. The current causal boundary is delegated review execution/verdict publication or its wake/rerun path, not hosted-runner acquisition or Wardnet source. Fresh exact evidence and GREEN acceptance are already on.github#712; do not create a no-op redispatch commit.Live ruleset
18156473still requires one unnamed generic approval and gives OrganizationAdmin an always-on bypass. #171 demonstrated that the currently authorized principal can make an ordinary expected-head merge call succeed despite no human APPROVED review, so such a call cannot safely be used as a governance probe..github#772now carries this exact specimen and acceptance criteria. Wardnet will not use further merge calls until central policy makes ordinary protected admission distinguishable from explicit emergency bypass and the solo-maintainer review rule is compatible with the declared operating model.Merge only after the unchanged/current successor head has an authenticated current-head OpenCode verdict, the required workflow is terminal-valid, central governance is repaired, every then-live workflow/review/thread gate is valid, and candidate-base compatibility is freshly verified. No force push/destructive rebase, gate weakening, predecessor-evidence reuse, implicit routine bypass, or runtime-enforcement claim.