From a34a3e3455420cc5a4c7f6d9f1288840ca536bd5 Mon Sep 17 00:00:00 2001 From: Seongho Bae Date: Sat, 5 Sep 2026 15:14:02 +0900 Subject: [PATCH 1/5] docs(adr): keep anti-bot and site reputation engines outside Wardnet --- ...dependent-access-and-reputation-engines.md | 88 +++++++++++++++++++ docs/adr/README.md | 10 +++ 2 files changed, 98 insertions(+) create mode 100644 docs/adr/2026-09-05-independent-access-and-reputation-engines.md create mode 100644 docs/adr/README.md diff --git a/docs/adr/2026-09-05-independent-access-and-reputation-engines.md b/docs/adr/2026-09-05-independent-access-and-reputation-engines.md new file mode 100644 index 0000000..fae01ea --- /dev/null +++ b/docs/adr/2026-09-05-independent-access-and-reputation-engines.md @@ -0,0 +1,88 @@ +# ADR 2026-09-05: Keep outbound anti-bot and site reputation engines outside Wardnet + +- Status: Proposed; documentation-only, pending PR review +- Date: 2026-09-05 +- Inspected Wardnet base: `5829a0f08d78de464dd24393ce5d0f25fba9d126` +- Consumer proposal: [Veilpick PR #3](https://github.com/ContextualWisdomLab/Veilpick/pull/3), stacked on its product ADR PR #1 +- Detailed contracts: [Veilpick design at the proposal commit](https://github.com/ContextualWisdomLab/Veilpick/blob/4d0f1e55d7e88d88d29fd6279467cefde3fde1b3/docs/design/access-and-reputation-engines.md) + +## Context + +Wardnet is the Rust-first WAF/IDS/AI SOC/gateway owner described in [AGENTS](../../AGENTS.md), [CLAUDE](../../CLAUDE.md) and the [architecture](../architecture.md). Its core contains route enforcement, request scoring, threat indicators, DNSBL entries, event retention and feed-related state. Rust implementation language does not make these concepts equivalent to an outbound acquisition engine or a general source-reputation model. + +At the inspected revision, `ThreatIndicator` in [the core](../../crates/waf-ids-core/src/lib.rs) contains `value`, `indicator_type`, `severity`, `source` and `ttl_seconds`; `DnsblEntry` identifies an address or prefix. The row alone does not establish a destination URL, original observation time, producer confidence, revocation/version lineage or source credibility. Other feed state must be evaluated explicitly where available, not assumed from these fields. + +Veilpick's product contract requires ontology-guided, autonomous acquisition, first-class stealth and functioning automatic challenge resolution for supported classes. Importing gateway enforcement or SOC approval workflows into that execution path would assign the wrong owner and could introduce hidden human dependencies. + +## Decision + +### 1. Preserve the owner boundary + +| Capability | Proposed owner | Wardnet responsibility | +| --- | --- | --- | +| Inbound request inspection and gateway enforcement | Wardnet plus proven security-engine integrations | Retain WAF/IDS/SOC/APIM behavior and existing governance | +| Outbound anti-bot access and challenge handling | Independent `anti-bot-core` / `anti-bot-engine`, initially incubated in Veilpick | Do not own browser sessions, stealth strategies, CAPTCHA solving or acquisition completion | +| Evidence-based site reputation | Independent `site-reputation-core` / `site-reputation-engine`, initially incubated in Veilpick | Optional source of correctly scoped threat observations, not the assessment authority | +| Governed destination/TLS/HTTP/browser/presentation and runtime evidence | OriginWeave through verified integration adapters | Do not fork these capabilities into the new engines | +| Ontology planning and extracted-result acceptance | Veilpick | Do not turn a gateway allow/block decision into goal completion or source truth | + +Here, anti-bot is explicitly the **outbound access and challenge** meaning from the acquisition product. This decision does not prohibit Wardnet from legitimately using inbound bot-risk signals in its own gateway protection. Those signals still cannot be relabeled as a destination's reputation or an outbound solver decision. + +The two new cores must not depend on `waf-ids-core` or each other. Initial repository co-location in Veilpick does not merge their domain ownership: independent schemas, release versions, standalone entry points and consumer compatibility tests are required. No existing Wardnet code is moved or copied by this proposal. + +### 2. Permit evidence reuse, not decision laundering + +The consumer-owned optional provider adapter may accept an authenticated, versioned `ThreatObservationV1` envelope only when its provenance and subject are sufficient. That proposed contract is not a shipped Wardnet endpoint or a claim that existing APIs already supply every field. + +The envelope distinguishes typed URL/origin/host/IP subject and exact scope; original producer/record/version; genuine observation time versus collection time; validity and separately labeled consumer freshness; source severity versus optional confidence; revocation; derivation; tenant/visibility and distribution restrictions. Complete details live in the linked consumer specification, not a competing Wardnet schema definition. + +| Existing input or condition | Required adapter behavior | +| --- | --- | +| Generic SQL-injection signature or gateway client-IP incident | Not a destination-site observation; reject that mapping | +| IP or CIDR DNSBL record | Preserve IP/prefix scope; do not infer every co-hosted publisher is malicious | +| TTL without an authoritative observation/validity anchor | Return `InsufficientProvenance` or retain explicitly incomplete evidence; do not manufacture a fresh observation time | +| Threat severity | Preserve as source severity, never a calibrated probability or global site score | +| Missing producer confidence | Keep unspecified, not zero and not a guessed value | +| Revoked or superseded source record | Preserve lifecycle/version semantics; no old-record replay may restore it | +| Wardnet unavailable or missing coverage | Report unavailable/unknown coverage; consumer standalone operation must remain possible | + +An adapter that needs original source metadata may use a separately governed original-provider contract. It must not silently fetch arbitrary URLs or private addresses, access Wardnet's database, or recover secrets from telemetry. Unknown or unsupported mappings must be visible to the consumer. Optional sanitized exports remain subject to source sharing restrictions and tenant isolation. + +STIX 2.1 distinguishes producer confidence, object versioning/revocation and indicator validity [1]. Our consumer requires explicit freshness/coverage handling and tombstones, but does not claim that STIX specifies the reputation algorithm. Provenance vocabulary is useful for attribution and derivation, not proof of truth [2]. Model confidence also needs independent calibration before being represented as a probability [3]. + +### 3. Keep independent policy and failure semantics + +A reputable or easily accessible site is not a network permission grant. A site presenting CAPTCHA, 403 or 429 is not thereby malicious or unreliable. The anti-bot engine honors task/origin/account quotas and independently verifies challenge resolution. Its successful automated path has zero human interventions; an error or unattended stop is not successful collection. + +Site reputation separates security, source reliability, access friction and coverage/freshness. Wardnet's `BLOCK_SCORE`, route block thresholds and monitor/block disposition must not become that engine's model, probability threshold or authorization result. Neither engine requires a synchronous Wardnet call on its critical path. + +No new Wardnet human approval gate is exported into Veilpick. Conversely, Veilpick autonomy cannot bypass Wardnet's own security or review controls. Component policies are composed without treating one owner's metadata as another owner's authority. + +## Alternatives considered + +1. **Use `waf-ids-core` as the shared engine:** rejected because threat/request/enforcement models have different subjects, state and acceptance semantics. +2. **Add an all-purpose anti-bot/reputation module to Wardnet:** rejected because it expands WAF/IDS/SOC responsibility and couples unrelated releases and availability. +3. **Discard all Wardnet reuse:** rejected; properly scoped, provenance-preserving observations can be useful through an optional adapter. +4. **Independent engines with evidence-only integration:** proposed because it preserves ownership, standalone operability and explicit compatibility requirements. + +## Delivery, compatibility and acceptance + +Veilpick PR #3 contains ADR 0004/0005, product/technical design, separate implementation plans, proposed contracts and acceptance scenarios. It is a design-only, parent-dependent proposal, not an integrated or functioning engine. Its package/service names are proposed, not current releases. This Wardnet ADR introduces no executable, endpoint, dependency or new security detection. + +A future adapter PR must show source-record fixtures, exact producer/consumer schema versions, omitted-field behavior, lifecycle replay/expiry tests, scope isolation, no secret leakage, and outage independence. It must demonstrate that a CAPTCHA-only observation cannot lower source reliability and that an ingress finding cannot masquerade as a destination finding. Run normal Wardnet Cargo/security gates if Wardnet code changes; documentation validation alone is not runtime acceptance. + +Keep existing runtime/feed/security work and the sole product-gap-baseline writer in PR #130 independent. Do not edit `docs/product-technical-gap-baseline.md` or change workflows, branch protection, required checks, code-owner policy or credentials as part of this proposal. No merge, self-approval or release is performed. + +## Consequences + +Wardnet stays focused and can evolve security adapters without owning browser automation or editorial reliability. Consumers gain explicit evidence limitations rather than a misleading repurposed score. The cost is adapter/schema compatibility work and potentially unavailable observations until source metadata is sufficient. A missing optional provider is recorded honestly, never silently converted into a safe-site result. + +## References + +[1] OASIS Open. (2021). *STIX Version 2.1*, sections 3.2, 3.6 and 4.7. [Official standard](https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html). + +[2] Lebo, T., Sahoo, S., & McGuinness, D. (Eds.). (2013, April 30). *PROV-O: The PROV ontology*. W3C. [Dated recommendation](https://www.w3.org/TR/2013/REC-prov-o-20130430/). + +[3] Guo, C., Pleiss, G., Sun, Y., & Weinberger, K. Q. (2017). On calibration of modern neural networks. *PMLR, 70*, 1321-1330. [Publisher record](https://proceedings.mlr.press/v70/guo17a.html); [arXiv:1706.04599](https://arxiv.org/abs/1706.04599). + +The [consumer research record](https://github.com/ContextualWisdomLab/Veilpick/blob/4d0f1e55d7e88d88d29fd6279467cefde3fde1b3/docs/research/access-and-reputation-evidence.md) supplies eight numbered standard/academic sources and exact repository observations. These references justify semantic distinctions, not measured engine effectiveness. Paper PDFs are not redistributed: edition-specific permission has not been established, so this change cites and summarizes instead. diff --git a/docs/adr/README.md b/docs/adr/README.md new file mode 100644 index 0000000..889f5f4 --- /dev/null +++ b/docs/adr/README.md @@ -0,0 +1,10 @@ +# Architecture decision records + +ADR status records a decision or proposal, not proof of implementation, passing checks, integration or release. Repository review and existing security gates remain separate. + +| Record | Relationship | +| --- | --- | +| [0010](0010-adaptive-contextual-orchestrator-default.md) | Existing record, unchanged by the access/reputation proposal | +| [2026-09-05](2026-09-05-independent-access-and-reputation-engines.md) | Proposed boundary: independent outbound anti-bot and site reputation engines; Wardnet supplies optional scoped observations only | + +The dated identifier avoids allocating a sequential number over independently developed ADR work. The companion [Veilpick PR #3](https://github.com/ContextualWisdomLab/Veilpick/pull/3) owns the detailed proposed engine designs. Neither proposal introduces a working engine or changes Wardnet runtime behavior. From d836b5f6a12b4bac1c45feccd0b93728f26d26ee Mon Sep 17 00:00:00 2001 From: Seongho Bae Date: Sat, 5 Sep 2026 15:34:27 +0900 Subject: [PATCH 2/5] docs(adr): narrow anti-bot ownership boundary --- ...026-09-05-anti-bot-acquisition-boundary.md | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 docs/adr/2026-09-05-anti-bot-acquisition-boundary.md diff --git a/docs/adr/2026-09-05-anti-bot-acquisition-boundary.md b/docs/adr/2026-09-05-anti-bot-acquisition-boundary.md new file mode 100644 index 0000000..b9c6c3b --- /dev/null +++ b/docs/adr/2026-09-05-anti-bot-acquisition-boundary.md @@ -0,0 +1,80 @@ +# ADR 2026-09-05: Keep outbound anti-bot acquisition outside Wardnet + +- Status: Proposed; documentation-only, pending PR review +- Date: 2026-09-05 +- Inspected Wardnet base: `5829a0f08d78de464dd24393ce5d0f25fba9d126` +- Detailed Wardnet site-reputation proposal: [Wardnet PR #173](https://github.com/ContextualWisdomLab/wardnet/pull/173) +- Anti-bot incubation proposal: [Veilpick PR #3](https://github.com/ContextualWisdomLab/Veilpick/pull/3), stacked on Veilpick PR #1 + +## Context + +Wardnet is the Rust-first gateway/WAF/IDS/SOC control-plane owner described by [AGENTS](../../AGENTS.md), [CLAUDE](../../CLAUDE.md), and the [architecture](../architecture.md). It owns gateway admission and enforcement, security evidence and policy, Agent Artifact Admission, and the lifecycle of Wardnet security decisions. Implementation language does not make browser acquisition, challenge solving, session camouflage, or anti-bot navigation part of that bounded context. + +The first version of this proposal also placed destination site reputation outside Wardnet. A later explicit product request, represented by Wardnet PR #173, assigns destination maliciousness, evidence lifecycle, organizational admission policy, and SOC accountability to Wardnet while retaining EgressWeave as the reusable outbound URL/address/DNS/peer/redirect/proxy/TLS/resource-policy owner. This ADR therefore narrows its decision to anti-bot acquisition only instead of creating a competing site-reputation authority. + +## Decision + +### 1. Keep browser acquisition and challenge handling outside Wardnet + +| Capability | Canonical responsibility | Wardnet boundary | +| --- | --- | --- | +| Inbound request inspection and gateway enforcement | Wardnet plus reviewed security-engine integrations | Own and enforce | +| Agent artifact/workload admission and security evidence | Wardnet | Own and enforce | +| Destination maliciousness/reputation policy and SOC evidence | Wardnet, through the bounded design in PR #173 or its verified successor | Own the security assessment; do not treat it as transport authorization | +| Outbound URL/address/DNS/peer/redirect/proxy/TLS/resource authorization | EgressWeave released/versioned port or ACL | Consume; do not reimplement | +| Browser acquisition, anti-bot challenge handling, session strategy, CAPTCHA/challenge completion | Independent anti-bot owner, currently incubated by the Veilpick proposal | Do not own or source-copy | +| Ontology-guided acquisition planning and extracted-result acceptance | Veilpick | Do not turn a Wardnet allow/deny into goal completion or source truth | + +Inbound bot-risk detection remains legitimate Wardnet security work. It is not an outbound challenge-solving implementation and must not be relabeled as one. + +The anti-bot owner must remain independently versioned and releasable. Wardnet must not depend on mutable sibling source, a PR head, a shared database, or cross-service SQL. If Wardnet consumes anti-bot evidence, it does so through a released/versioned contract and an anti-corruption layer that preserves the producer's subject, scope, lifecycle, and provenance. + +### 2. Security evidence does not become another owner's authority + +Wardnet may publish or consume narrowly scoped evidence, but a consumer must not infer stronger meaning than the record proves. In particular: + +- an ingress SQL-injection finding or abusive client-IP event is not evidence that a destination website is malicious; +- an IP/CIDR observation remains IP/prefix-scoped and does not establish the reputation of every virtual host on that address; +- source severity remains source severity rather than a calibrated probability; +- missing confidence remains unspecified rather than guessed; +- TTL without an authoritative observation or validity anchor is `InsufficientProvenance`; if retained for audit, the record is explicitly non-decision-bearing and cannot be treated as a current observation; +- revocation, deletion, supersession, validity, producer/version identity, tenant scope, and distribution restrictions must survive translation. + +Any provider-adapter hop carrying tenant-scoped or security-sensitive evidence requires authenticated encrypted transport. Authentication and transport confidentiality are separate requirements; neither substitutes for the other. No secret, raw credential, or unnecessary tenant identifier may be copied into evidence solely for transport convenience. + +Wardnet-side evidence adapters must not fetch arbitrary producer URLs to fill missing metadata. If an owning integration genuinely requires network retrieval, it must use the released EgressWeave authorization boundary, including destination policy, resolved IPv4/IPv6 validation, redirect and DNS re-resolution checks, proxy/TLS controls, and resource limits. If that owner contract is unavailable or cannot prove those controls, retrieval fails closed rather than falling back to a local HTTP implementation. + +### 3. Compose policy without decision laundering + +A successful anti-bot acquisition is not a security allow. A CAPTCHA, 403, or 429 is not proof that a destination is malicious. Likewise, a Wardnet reputation decision is not proof that an HTTP connection was actually blocked. The protected outbound path composes the responsible authorities without allowing one owner's `allow` to override another owner's `deny`. + +Wardnet does not export a human-approval requirement into the anti-bot critical path. Conversely, autonomous browser acquisition cannot bypass Wardnet admission/security policy or EgressWeave transport authorization. Unsupported, unavailable, expired, or unverifiable required evidence is handled according to the owning fail-closed policy instead of being silently promoted to success. + +## Alternatives considered + +1. **Put anti-bot acquisition inside Wardnet.** Rejected because browser/session/challenge state has different invariants, failure modes, release cadence, and operational risk from gateway/SOC security policy. +2. **Make Wardnet a shared implementation library for anti-bot.** Rejected because that would couple releases and encourage ownership leakage through `waf-ids-core`. +3. **Move site reputation out with anti-bot.** Superseded by the later Wardnet product decision in PR #173: site maliciousness and SOC reputation evidence are Wardnet security responsibilities, while transport authorization stays with EgressWeave. +4. **Independent anti-bot owner with versioned evidence integration.** Selected because it preserves autonomous acquisition while keeping Wardnet and EgressWeave security authorities explicit. + +## Delivery and acceptance + +This ADR changes no runtime behavior. A future Wardnet integration with the anti-bot owner must demonstrate exact released producer/consumer versions, authenticated encrypted transport, provenance-preserving fixtures, lifecycle replay/expiry tests, tenant isolation, secret minimization, outage behavior, and a zero-network-fallback test proving that missing EgressWeave authority cannot trigger ad hoc HTTP retrieval. + +The detailed site-reputation design, threat-evidence semantics, deployment coverage, and false-positive evaluation belong to PR #173 or its verified successor. This PR does not edit `docs/product-technical-gap-baseline.md`, which remains single-writer work in PR #130, and it does not modify workflows, branch protection, credentials, runtime source, or foreign-owner repositories. + +## Consequences + +Wardnet remains accountable for security admission, site maliciousness/reputation policy, and SOC evidence without absorbing browser automation. The anti-bot owner can evolve browser/challenge mechanics independently. EgressWeave remains the transport-authorization authority. The cost is explicit versioned integration and honest unavailable/unknown states instead of convenient in-process coupling. + +## References + +OASIS Open. (2021). *STIX Version 2.1*. https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html — Used for producer/version, validity, revocation, marking, and confidence semantics; it does not define Wardnet's reputation algorithm. + +Lebo, T., Sahoo, S., & McGuinness, D. (Eds.). (2013, April 30). *PROV-O: The PROV ontology*. W3C. https://www.w3.org/TR/2013/REC-prov-o-20130430/ — Used to distinguish attribution/derivation from truth or authorization. + +Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. *Communications of the ACM, 15*(12), 1053–1058. https://doi.org/10.1145/361598.361623 — Supports decomposing around information-hiding decisions rather than implementation language; here the browser/challenge mechanism and gateway/SOC security authority change for different reasons. + +Guo, C., Pleiss, G., Sun, Y., & Weinberger, K. Q. (2017). On calibration of modern neural networks. *Proceedings of Machine Learning Research, 70*, 1321–1330. https://proceedings.mlr.press/v70/guo17a.html — Supports keeping source severity/confidence distinct from calibrated probability claims. + +No third-party paper PDF is redistributed by this ADR because edition-specific redistribution permission was not established. Citation and summary are sufficient for this documentation-only boundary. \ No newline at end of file From ba1668441a622243e9fae7d5400baa7274525fcf Mon Sep 17 00:00:00 2001 From: Seongho Bae Date: Sat, 5 Sep 2026 15:34:39 +0900 Subject: [PATCH 3/5] docs(adr): align ownership index with site reputation owner --- docs/adr/README.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/adr/README.md b/docs/adr/README.md index 889f5f4..af70110 100644 --- a/docs/adr/README.md +++ b/docs/adr/README.md @@ -1,10 +1,11 @@ # Architecture decision records -ADR status records a decision or proposal, not proof of implementation, passing checks, integration or release. Repository review and existing security gates remain separate. +ADR status records a decision or proposal, not proof of implementation, passing checks, integration, or release. Repository review and existing security gates remain separate. | Record | Relationship | | --- | --- | -| [0010](0010-adaptive-contextual-orchestrator-default.md) | Existing record, unchanged by the access/reputation proposal | -| [2026-09-05](2026-09-05-independent-access-and-reputation-engines.md) | Proposed boundary: independent outbound anti-bot and site reputation engines; Wardnet supplies optional scoped observations only | +| [0010](0010-adaptive-contextual-orchestrator-default.md) | Existing record, unchanged by the anti-bot ownership proposal | +| [2026-09-05 anti-bot acquisition boundary](2026-09-05-anti-bot-acquisition-boundary.md) | Proposed boundary: outbound browser acquisition/challenge handling stays outside Wardnet; Wardnet retains security admission and site-reputation/SOC policy ownership | +| [2026-09-05 outbound site reputation](2026-09-05-outbound-site-reputation-engine.md) | Separate proposed Wardnet-owned site-reputation design in PR #173; not present on this branch until that PR or a verified successor is integrated | -The dated identifier avoids allocating a sequential number over independently developed ADR work. The companion [Veilpick PR #3](https://github.com/ContextualWisdomLab/Veilpick/pull/3) owns the detailed proposed engine designs. Neither proposal introduces a working engine or changes Wardnet runtime behavior. +The dated identifier avoids allocating a sequential number over independently developed ADR work. The anti-bot proposal does not introduce a working engine or change Wardnet runtime behavior. Site-reputation implementation details remain in [Wardnet PR #173](https://github.com/ContextualWisdomLab/wardnet/pull/173) or its verified successor; the independent anti-bot design is currently incubated in [Veilpick PR #3](https://github.com/ContextualWisdomLab/Veilpick/pull/3). \ No newline at end of file From a68b41954e51d5231b732eb3bc200f38bae11871 Mon Sep 17 00:00:00 2001 From: Seongho Bae Date: Sat, 5 Sep 2026 15:34:47 +0900 Subject: [PATCH 4/5] docs(adr): retire superseded site reputation boundary --- ...dependent-access-and-reputation-engines.md | 88 ------------------- 1 file changed, 88 deletions(-) delete mode 100644 docs/adr/2026-09-05-independent-access-and-reputation-engines.md diff --git a/docs/adr/2026-09-05-independent-access-and-reputation-engines.md b/docs/adr/2026-09-05-independent-access-and-reputation-engines.md deleted file mode 100644 index fae01ea..0000000 --- a/docs/adr/2026-09-05-independent-access-and-reputation-engines.md +++ /dev/null @@ -1,88 +0,0 @@ -# ADR 2026-09-05: Keep outbound anti-bot and site reputation engines outside Wardnet - -- Status: Proposed; documentation-only, pending PR review -- Date: 2026-09-05 -- Inspected Wardnet base: `5829a0f08d78de464dd24393ce5d0f25fba9d126` -- Consumer proposal: [Veilpick PR #3](https://github.com/ContextualWisdomLab/Veilpick/pull/3), stacked on its product ADR PR #1 -- Detailed contracts: [Veilpick design at the proposal commit](https://github.com/ContextualWisdomLab/Veilpick/blob/4d0f1e55d7e88d88d29fd6279467cefde3fde1b3/docs/design/access-and-reputation-engines.md) - -## Context - -Wardnet is the Rust-first WAF/IDS/AI SOC/gateway owner described in [AGENTS](../../AGENTS.md), [CLAUDE](../../CLAUDE.md) and the [architecture](../architecture.md). Its core contains route enforcement, request scoring, threat indicators, DNSBL entries, event retention and feed-related state. Rust implementation language does not make these concepts equivalent to an outbound acquisition engine or a general source-reputation model. - -At the inspected revision, `ThreatIndicator` in [the core](../../crates/waf-ids-core/src/lib.rs) contains `value`, `indicator_type`, `severity`, `source` and `ttl_seconds`; `DnsblEntry` identifies an address or prefix. The row alone does not establish a destination URL, original observation time, producer confidence, revocation/version lineage or source credibility. Other feed state must be evaluated explicitly where available, not assumed from these fields. - -Veilpick's product contract requires ontology-guided, autonomous acquisition, first-class stealth and functioning automatic challenge resolution for supported classes. Importing gateway enforcement or SOC approval workflows into that execution path would assign the wrong owner and could introduce hidden human dependencies. - -## Decision - -### 1. Preserve the owner boundary - -| Capability | Proposed owner | Wardnet responsibility | -| --- | --- | --- | -| Inbound request inspection and gateway enforcement | Wardnet plus proven security-engine integrations | Retain WAF/IDS/SOC/APIM behavior and existing governance | -| Outbound anti-bot access and challenge handling | Independent `anti-bot-core` / `anti-bot-engine`, initially incubated in Veilpick | Do not own browser sessions, stealth strategies, CAPTCHA solving or acquisition completion | -| Evidence-based site reputation | Independent `site-reputation-core` / `site-reputation-engine`, initially incubated in Veilpick | Optional source of correctly scoped threat observations, not the assessment authority | -| Governed destination/TLS/HTTP/browser/presentation and runtime evidence | OriginWeave through verified integration adapters | Do not fork these capabilities into the new engines | -| Ontology planning and extracted-result acceptance | Veilpick | Do not turn a gateway allow/block decision into goal completion or source truth | - -Here, anti-bot is explicitly the **outbound access and challenge** meaning from the acquisition product. This decision does not prohibit Wardnet from legitimately using inbound bot-risk signals in its own gateway protection. Those signals still cannot be relabeled as a destination's reputation or an outbound solver decision. - -The two new cores must not depend on `waf-ids-core` or each other. Initial repository co-location in Veilpick does not merge their domain ownership: independent schemas, release versions, standalone entry points and consumer compatibility tests are required. No existing Wardnet code is moved or copied by this proposal. - -### 2. Permit evidence reuse, not decision laundering - -The consumer-owned optional provider adapter may accept an authenticated, versioned `ThreatObservationV1` envelope only when its provenance and subject are sufficient. That proposed contract is not a shipped Wardnet endpoint or a claim that existing APIs already supply every field. - -The envelope distinguishes typed URL/origin/host/IP subject and exact scope; original producer/record/version; genuine observation time versus collection time; validity and separately labeled consumer freshness; source severity versus optional confidence; revocation; derivation; tenant/visibility and distribution restrictions. Complete details live in the linked consumer specification, not a competing Wardnet schema definition. - -| Existing input or condition | Required adapter behavior | -| --- | --- | -| Generic SQL-injection signature or gateway client-IP incident | Not a destination-site observation; reject that mapping | -| IP or CIDR DNSBL record | Preserve IP/prefix scope; do not infer every co-hosted publisher is malicious | -| TTL without an authoritative observation/validity anchor | Return `InsufficientProvenance` or retain explicitly incomplete evidence; do not manufacture a fresh observation time | -| Threat severity | Preserve as source severity, never a calibrated probability or global site score | -| Missing producer confidence | Keep unspecified, not zero and not a guessed value | -| Revoked or superseded source record | Preserve lifecycle/version semantics; no old-record replay may restore it | -| Wardnet unavailable or missing coverage | Report unavailable/unknown coverage; consumer standalone operation must remain possible | - -An adapter that needs original source metadata may use a separately governed original-provider contract. It must not silently fetch arbitrary URLs or private addresses, access Wardnet's database, or recover secrets from telemetry. Unknown or unsupported mappings must be visible to the consumer. Optional sanitized exports remain subject to source sharing restrictions and tenant isolation. - -STIX 2.1 distinguishes producer confidence, object versioning/revocation and indicator validity [1]. Our consumer requires explicit freshness/coverage handling and tombstones, but does not claim that STIX specifies the reputation algorithm. Provenance vocabulary is useful for attribution and derivation, not proof of truth [2]. Model confidence also needs independent calibration before being represented as a probability [3]. - -### 3. Keep independent policy and failure semantics - -A reputable or easily accessible site is not a network permission grant. A site presenting CAPTCHA, 403 or 429 is not thereby malicious or unreliable. The anti-bot engine honors task/origin/account quotas and independently verifies challenge resolution. Its successful automated path has zero human interventions; an error or unattended stop is not successful collection. - -Site reputation separates security, source reliability, access friction and coverage/freshness. Wardnet's `BLOCK_SCORE`, route block thresholds and monitor/block disposition must not become that engine's model, probability threshold or authorization result. Neither engine requires a synchronous Wardnet call on its critical path. - -No new Wardnet human approval gate is exported into Veilpick. Conversely, Veilpick autonomy cannot bypass Wardnet's own security or review controls. Component policies are composed without treating one owner's metadata as another owner's authority. - -## Alternatives considered - -1. **Use `waf-ids-core` as the shared engine:** rejected because threat/request/enforcement models have different subjects, state and acceptance semantics. -2. **Add an all-purpose anti-bot/reputation module to Wardnet:** rejected because it expands WAF/IDS/SOC responsibility and couples unrelated releases and availability. -3. **Discard all Wardnet reuse:** rejected; properly scoped, provenance-preserving observations can be useful through an optional adapter. -4. **Independent engines with evidence-only integration:** proposed because it preserves ownership, standalone operability and explicit compatibility requirements. - -## Delivery, compatibility and acceptance - -Veilpick PR #3 contains ADR 0004/0005, product/technical design, separate implementation plans, proposed contracts and acceptance scenarios. It is a design-only, parent-dependent proposal, not an integrated or functioning engine. Its package/service names are proposed, not current releases. This Wardnet ADR introduces no executable, endpoint, dependency or new security detection. - -A future adapter PR must show source-record fixtures, exact producer/consumer schema versions, omitted-field behavior, lifecycle replay/expiry tests, scope isolation, no secret leakage, and outage independence. It must demonstrate that a CAPTCHA-only observation cannot lower source reliability and that an ingress finding cannot masquerade as a destination finding. Run normal Wardnet Cargo/security gates if Wardnet code changes; documentation validation alone is not runtime acceptance. - -Keep existing runtime/feed/security work and the sole product-gap-baseline writer in PR #130 independent. Do not edit `docs/product-technical-gap-baseline.md` or change workflows, branch protection, required checks, code-owner policy or credentials as part of this proposal. No merge, self-approval or release is performed. - -## Consequences - -Wardnet stays focused and can evolve security adapters without owning browser automation or editorial reliability. Consumers gain explicit evidence limitations rather than a misleading repurposed score. The cost is adapter/schema compatibility work and potentially unavailable observations until source metadata is sufficient. A missing optional provider is recorded honestly, never silently converted into a safe-site result. - -## References - -[1] OASIS Open. (2021). *STIX Version 2.1*, sections 3.2, 3.6 and 4.7. [Official standard](https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html). - -[2] Lebo, T., Sahoo, S., & McGuinness, D. (Eds.). (2013, April 30). *PROV-O: The PROV ontology*. W3C. [Dated recommendation](https://www.w3.org/TR/2013/REC-prov-o-20130430/). - -[3] Guo, C., Pleiss, G., Sun, Y., & Weinberger, K. Q. (2017). On calibration of modern neural networks. *PMLR, 70*, 1321-1330. [Publisher record](https://proceedings.mlr.press/v70/guo17a.html); [arXiv:1706.04599](https://arxiv.org/abs/1706.04599). - -The [consumer research record](https://github.com/ContextualWisdomLab/Veilpick/blob/4d0f1e55d7e88d88d29fd6279467cefde3fde1b3/docs/research/access-and-reputation-evidence.md) supplies eight numbered standard/academic sources and exact repository observations. These references justify semantic distinctions, not measured engine effectiveness. Paper PDFs are not redistributed: edition-specific permission has not been established, so this change cites and summarizes instead. From d94a4a6207a0d3ea79547a57fb0a7c5f6b2b30d5 Mon Sep 17 00:00:00 2001 From: Seongho Bae Date: Sat, 5 Sep 2026 15:35:05 +0900 Subject: [PATCH 5/5] docs(adr): avoid unresolved sibling PR link --- docs/adr/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/adr/README.md b/docs/adr/README.md index af70110..37576e0 100644 --- a/docs/adr/README.md +++ b/docs/adr/README.md @@ -6,6 +6,6 @@ ADR status records a decision or proposal, not proof of implementation, passing | --- | --- | | [0010](0010-adaptive-contextual-orchestrator-default.md) | Existing record, unchanged by the anti-bot ownership proposal | | [2026-09-05 anti-bot acquisition boundary](2026-09-05-anti-bot-acquisition-boundary.md) | Proposed boundary: outbound browser acquisition/challenge handling stays outside Wardnet; Wardnet retains security admission and site-reputation/SOC policy ownership | -| [2026-09-05 outbound site reputation](2026-09-05-outbound-site-reputation-engine.md) | Separate proposed Wardnet-owned site-reputation design in PR #173; not present on this branch until that PR or a verified successor is integrated | +| 2026-09-05 outbound site reputation | Separate proposed Wardnet-owned site-reputation design in [PR #173](https://github.com/ContextualWisdomLab/wardnet/pull/173); no relative file link is published until that PR or a verified successor is integrated | The dated identifier avoids allocating a sequential number over independently developed ADR work. The anti-bot proposal does not introduce a working engine or change Wardnet runtime behavior. Site-reputation implementation details remain in [Wardnet PR #173](https://github.com/ContextualWisdomLab/wardnet/pull/173) or its verified successor; the independent anti-bot design is currently incubated in [Veilpick PR #3](https://github.com/ContextualWisdomLab/Veilpick/pull/3). \ No newline at end of file