consumer: publish a Rust-compatible versioned egress authorization boundary for Wardnet

[seonghobae]

Consumer defect

Wardnet currently needs outbound HTTP authority for feed/TAXII/KEV/proxy/security-evidence paths, but the live EgressWeave owner surface cannot yet be consumed by a Rust-first service without either recreating EgressWeave's destination/DNS/redirect/proxy/TLS/resource policy or depending on mutable sibling source.

Exact consumer evidence: ContextualWisdomLab/wardnet#136 is Draft at 3cb1047416c3aa7fa8eb352b842cc55ad8c21b19 on protected main@cc15cc2c34daf8c104eeb83d52a6a66f3cd6e128. Its current local implementation performs hostname/IP validation, manual DNS resolution and address pinning, no-proxy/no-redirect policy and bounded client lifecycle. It also carries an unresolved causal RED showing manual DNS can outlive the intended end-to-end feed/TAXII/KEV request budget. Under the current CWL bounded-context contract, that semantic outbound-policy authority belongs here rather than becoming a second Wardnet implementation.

Fresh EgressWeave state has default_branch=main and no GitHub Release. Current owner work includes substantial security/policy hardening, while ADR/consumer work in #233 documents that the older released Python surface is insufficient even for some same-language CI consumers. A transient PR head, source checkout or commit-vendored implementation is not an acceptable production contract for Wardnet.

RED acceptance

A Wardnet/Rust consumer must be able to prove all of the following without copying EgressWeave policy implementation:

• no direct reuse of mutable EgressWeave PR/source internals and no cross-service SQL;
• destination authority, special-purpose-address handling, DNS rebinding resistance, redirect/proxy/TLS/resource policy and stable denial semantics remain EgressWeave-owned;
• unavailable, incompatible or unverifiable owner evidence fails closed;
• one operation budget cannot be bypassed by spending unbounded time in a pre-request DNS phase;
• decision/evidence identity is bound to an immutable released EgressWeave contract/version rather than a prose or commit-only assertion.

GREEN acceptance

Publish an immutable, versioned consumer boundary that a Rust service can consume through an explicit ACL/port. The owner implementation may choose the appropriate transport/API shape; the contract should expose only provider-neutral authorization inputs, decision/denial output and minimized evidence needed by a consumer. It must include:

• stable versioned schema/API and compatibility rules;
• exact release/package identity with SBOM/provenance/reproducibility evidence;
• bounded end-to-end timing semantics covering any owner-required DNS work plus HTTP authority decision, or an equivalently strong documented execution contract;
• hostile conformance vectors for SSRF, DNS rebinding, special-purpose/private/link-local targets, redirects, ambient proxies, TLS/trust substitution and resource exhaustion;
• deterministic fail-closed behavior for unsupported contract versions or unavailable authority;
• a consumer example or conformance fixture sufficient for Wardnet to replace its local semantic policy with a thin Rust ACL/adapter while retaining Wardnet-owned SOC/admission evidence semantics.

Wardnet #136 should remain a Draft evidence/consumer lane until this owner contract is released. Its hostile tests and current DNS-deadline RED are useful acceptance evidence, but the semantic policy implementation should not become protected Wardnet truth if doing so duplicates this bounded context.

[seonghobae]

@jules Please advance this canonical owner lane from fresh protected main; Wardnet must not implement or ship a second outbound-policy engine. Re-read the live EgressWeave policy/DNS/TLS/resource stack and reuse/adapt existing owner semantics rather than copying Wardnet #136 source.

Start contract-first/TDD with the exact Rust-consumer RED in this issue: an external Rust service needs a stable provider-neutral authorization/evidence boundary whose operation budget includes owner-required DNS work; unsupported/unavailable/unverifiable versions fail closed; no mutable source/submodule/PR-head dependency is acceptable for Wardnet production. Preserve EgressWeave's existing destination, special-purpose-address, DNS-rebinding, redirect/proxy, TLS/trust, framing and resource-exhaustion authority.

GREEN is not source-only: publish an immutable versioned boundary and conformance fixture that Wardnet can consume through a thin ACL/port, with exact package/release identity, compatibility rules, hostile SSRF/DNS-rebinding/private/link-local/redirect/proxy/TLS/resource vectors, SBOM, provenance, reproducibility/rollback evidence, and bounded end-to-end timing semantics. Normal protected integration only; no self/model approval, gate weakening, force-push or routine admin bypass. Once the immutable owner release exists, Wardnet #136 can non-destructively discard its duplicate semantic implementation while retaining consumer/security evidence tests.

[seonghobae]

Fresh Wardnet consumer evidence supersedes the issue body's older #136@3cb1047... snapshot.

• protected Wardnet base remains main@cc15cc2c34daf8c104eeb83d52a6a66f3cd6e128;
• Draft security: require exact HTTPCore network-backend authority values #136 is now exact 28e5776388b2fc31e1d0567382871a1f599aa3ed;
• the branch's RED/GREEN lineage proves a real end-to-end budget requirement: RED f408500d8aeb4beb386caa48a7525508d59da193, runnable RED 3cb1047416c3aa7fa8eb352b842cc55ad8c21b19, then local repair by 9978f8c643433b5df0398e3d9f3608546fdadecd and current deterministic pending-resolver acceptance at 28e5776...;
• however, that branch also implements destination/address classification, manual DNS resolution/pinning, redirect/proxy behavior and outbound-client policy locally. Under the current CWL ownership contract, those production semantics are EgressWeave authority and must not become protected Wardnet truth merely because the local RED can be made GREEN.

Owner GREEN therefore remains contract-first and release-bound: a Rust-consumable provider-neutral EgressWeave authorization/evidence port must carry one bounded operation budget across owner-required DNS plus HTTP authority/execution semantics (or an equivalently strong owner contract), exact version/digest/provenance identity, and hostile conformance vectors. Until that immutable owner release exists, Wardnet #136 is being kept as Draft evidence/consumer material rather than an integration candidate. Once released, Wardnet can retain its hostile consumer/deadline tests while replacing local policy implementation with a thin ACL/adapter. No mutable source/PR head is acceptable.

[seonghobae]

Additional Wardnet consumer evidence from open Draft #115 (feat(feeds): refresh official threat sources) broadens the concrete Rust-consumer acceptance without changing owner boundaries.

Fresh #115 exact head is aad8224ab664861b540bdf818e9580470cbe89fb on a stale pre-#159 Wardnet base. Its unique useful Wardnet-owned delta includes the closed official-source registry, feed-specific response parsers, conditional validator state, content SHA-256, last-known-good atomic replacement semantics, refresh/freshness evidence, audit records, and source attribution/terms for Spamhaus DROP, URLhaus and ThreatFox.

The same branch also directly constructs and sends reqwest requests, enforces HTTPS only in one auth-bearing branch, sets redirect/timeout behavior through the local HTTP client, and therefore necessarily owns destination/DNS/redirect/proxy/TLS/resource semantics if merged as-is. Under the current CWL boundary, those semantics must not become a second Wardnet authority.

Please include #115 as another conformance consumer for the versioned Rust-compatible owner boundary. In addition to #136's SSRF/DNS-rebinding/deadline vectors, GREEN must let Wardnet express a fixed official-source destination/purpose and conditional request metadata while EgressWeave remains authoritative for resolved-address/DNS-rebinding, redirect, ambient-proxy, TLS/trust, connection/resource and end-to-end outbound-policy evidence. The contract must allow Wardnet to keep feed credentials/request payload construction, content parsing, source registry, validators/LKG state and SOC audit/provenance local without copying egress policy implementation.

No immutable EgressWeave GitHub Release exists at this fresh read, so Wardnet #115 will remain a Draft preservation/repair lane rather than consuming a mutable owner PR/source head.

[seonghobae]

Fresh Wardnet consumer evidence from proposed outbound site-reputation lane #173 adds one composition requirement without moving reputation authority into EgressWeave.

Current Wardnet state: protected/default main@5829a0f08d78de464dd24393ce5d0f25fba9d126; PR #173 exact a14b28a10ea87dbcc1939fe0fdca6ce5b02259ed, Ready/open, documentation-only. Its security bounded context assigns destination maliciousness/evidence lifecycle/organizational admission policy/SOC accountability to Wardnet and explicitly keeps URL/address/DNS/peer, redirect, proxy, TLS/trust and resource authorization with EgressWeave. Current #173 CI/Security/CodeQL/Semgrep runs are queued, so this is proposal evidence only, not released producer authority.

Please preserve this as another Rust-consumer conformance case for the #237 owner boundary. GREEN does not require EgressWeave to implement or ingest Wardnet reputation scoring. It requires a composition-safe authorization/execution contract so a consumer can prove: (1) a Wardnet hard-deny prevents connect/send with zero upstream hit; (2) a Wardnet allow/unknown cannot override an EgressWeave deny or unavailable required transport authority; (3) redirect/new-authority/DNS-peer changes remain re-authorized by EgressWeave; (4) decision evidence distinguishes Wardnet security assessment, EgressWeave transport authorization, and actual execution/enforcement outcome; (5) replay/idempotency/version identity cannot turn an old reputation allow or old transport allow into current permission; and (6) no caller must copy EgressWeave DNS/redirect/proxy/TLS/resource policy to compose the two denies.

Hostile fixture: Wardnet reputation returns allow for the original host, then EgressWeave resolves/redirects to a denied private/link-local/new authority. Expected result is fail-closed with no protected network send and receipts that do not claim the Wardnet reputation decision itself blocked traffic. The inverse fixture (Wardnet hard-deny while EgressWeave would allow) must also produce zero upstream hit without requiring EgressWeave to understand the reputation model.

This extends #237's consumer acceptance only. Wardnet #173 must still wait for an immutable released owner boundary before any production transport integration; no mutable EgressWeave PR/source head is acceptable.

[seonghobae]

Fresh Wardnet consumer evidence for this owner boundary: protected/default Wardnet remains main@5829a0f08d78de464dd24393ce5d0f25fba9d126. New Wardnet site-reputation design #173 is unchanged at exact a14b28a10ea87dbcc1939fe0fdca6ce5b02259ed, Ready/mergeable, docs-only; all 9 exact-head workflow runs are now terminal and the formerly queued CodeQL PR 33949463499 is SUCCESS. That design explicitly keeps executable URL/address/DNS/peer, redirect, proxy, TLS/trust and resource authorization here in EgressWeave and treats Wardnet reputation as a separate maliciousness/evidence/policy authority.

Fresh EgressWeave release inventory is still empty. Therefore the consumer RED remains real: Wardnet cannot implement production outbound interception by copying local reqwest/DNS/redirect/proxy/TLS semantics or by pinning a mutable EgressWeave branch/PR. GREEN remains an immutable Rust-consumable EgressWeave release/contract with exact package/source/SBOM/provenance identity, bounded end-to-end DNS+request timing, hostile SSRF/rebinding/special-address/redirect/proxy/TLS/resource vectors, fail-closed version/unavailability behavior, and a thin-consumer conformance fixture. #173's now-clean documentation evidence does not relax that prerequisite.

[seonghobae]

Fresh Wardnet consumer revalidation after the protected-main movement: Wardnet is now protected/default main@a52ccd0a24a727d9349bb32def7713882d8cad1e after #171. Site-reputation PR #173 is unchanged at exact a14b28a10ea87dbcc1939fe0fdca6ce5b02259ed; GitHub recomputes it mergeable against the advanced main and its four-file documentation delta does not overlap #171. Its earlier repository runs remain source-head evidence, while final candidate-base admission must be reacquired after any restack. Required OpenCode remains non-passing on delegated verdict publication and is already owned by .github#712.

Fresh EgressWeave Releases is still empty. The owner acceptance therefore does not change: Wardnet must not copy/recreate executable URL/address/DNS/peer, redirect, proxy, TLS/trust or resource-authorization semantics. Production integration remains gated on an immutable Rust-consumable EgressWeave contract/release with exact source/package/SBOM/provenance identity and bounded hostile conformance. Wardnet can continue its independent reputation evidence/policy core, but no mutable EgressWeave PR/head becomes transport authority.

[seonghobae]

Fresh Wardnet consumer evidence, 2026-09-06 KST: protected Wardnet remains main@a52ccd0a24a727d9349bb32def7713882d8cad1e; reputation-contract candidate #175 is now exact 45f2aecd40983b785c1e37489596af641dedcc84 after a format-only causal CI repair. Its implemented boundary is intentionally transport-neutral: authenticated tenant/workload/purpose context, canonical destination subject identity supplied by the owning canonicalization boundary, evidence/source policy, assessment/evidence-health/action/reason, and explainable SOC decision envelope. It does not parse/authorize URLs, resolve DNS, bind actual peers, follow redirects, select proxies, establish TLS, perform HTTP I/O, or claim that a reputation allow/deny is an executed transport outcome.

Fresh EgressWeave protected/default main is bd0339bf43cf5041e861bac86a84cb6e7e32637e; GitHub Release inventory remains empty. Wardnet therefore still consumes no mutable EgressWeave source/head and keeps runtime composition fail closed. #237's GREEN remains necessary: an immutable versioned Rust-consumable owner boundary covering destination/address/DNS-rebinding/redirect/proxy/TLS/resource authorization, bounded end-to-end timing, stable denial/evidence identity, hostile conformance vectors, package/SBOM/provenance/reproducibility and rollback. Wardnet's current pure-core work does not duplicate or weaken that requirement.

[seonghobae]

Fresh Wardnet consumer evidence adds one bounded released-contract requirement; no EgressWeave source/PR head is being consumed.

Wardnet #176 found that an authorization can be safely bound to an opaque canonical destination only if the external canonicalization identity is immutable and carried with that evidence. The evaluated Wardnet context already has canonicalization_profile and canonicalization_version; RED wardnet#176@3af071dd108ae5384a6985d10d9d661bdc2d1b5a demonstrates that a business grant must not survive profile/version drift merely because the resulting subject string remains equal. Current Wardnet repair f6193c094c0662a40fe3b100f483c3b065e77ed5 only binds those owner-supplied identities; it does not interpret them or copy canonicalization semantics.

Please preserve this in the immutable Rust-consumer boundary/release acceptance: EgressWeave-owned canonical destination/authorization evidence must expose a stable, versioned canonicalization profile identity sufficient for consumers to bind decisions and grants to the exact interpretation rules used. A profile/version change must be distinguishable from the prior one. Wardnet must not need EgressWeave source, cross-service SQL, URL/DNS parsing, or duplicated normalization code to validate that identity. Existing destination/DNS/redirect/proxy/TLS/resource authority remains wholly EgressWeave-owned; unavailable/incompatible/unverifiable released evidence remains fail closed.