Skip to content

fix(reputation): bind business authorization evidence - #176

Draft
seonghobae wants to merge 44 commits into
feat/site-reputation-contract-v1from
fix/reputation-business-authorization-binding-v1
Draft

fix(reputation): bind business authorization evidence#176
seonghobae wants to merge 44 commits into
feat/site-reputation-contract-v1from
fix/reputation-business-authorization-binding-v1

Conversation

@seonghobae

@seonghobae seonghobae commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Review-derived security defect

wardnet.reputation.v1 originally allowed assessment=unknown, action=allow, reason=business_authorization without sufficient authorization identity/revision, exact subject scope, approval/ticket, validity/provenance, policy identity/revision, canonicalization identity/version or protect-mode binding. This Draft child owns only that Wardnet reputation-policy/evidence repair. It does not parse or authorize URLs, resolve DNS, follow redirects, choose proxies, establish TLS, perform transport, or duplicate EgressWeave authority.

Retained causal lineage

The branch preserves the executed business-authorization REDs and their minimal fixes, including exact-scope binding, required policy_mode=protect, the inherited 32-reference decision cap, and the parent's 8 KiB ObservableUrl invariant. Ordinary integration CI later exposed three stale test fixtures that deserialized the already-required v1 schema before reaching their intended security assertions. Those failures were repaired test-only by adding the missing policy_mode to the affected shared/canonicalization/policy-scope fixtures; production validation was not weakened.

The latest movement from 0a79c8af6943ec7c5263b83be0b2d6a3b2e19b72 to current exact 5d7166da2034d450f37ab69d37fbbb9d1301e287 adds only the remaining business_authorization_policy_scope.rs fixture line. Concurrent parent/child movement is therefore adopted as valid causal repair, not treated as a race.

Current exact state — 2026-09-07 KST

PR #176 remains open/Draft and mergeable on exact parent #175@9de0ea568096a18b5c1fc9bc9fce097e08584d44; exact current head is 5d7166da2034d450f37ab69d37fbbb9d1301e287.

Current exact-head repository lanes are terminal GREEN:

  • CI 34125618252 — success;
  • Fuzz 34125618251 — success.

These results prove this Draft child against its current parent only. Root #175 is still non-integrated and has a required delegated-CodeQL failure owned by .github#1929; Draft guards also mean #176 has not materialized the complete eventual merge-gate set. Keep Draft. After #175 reaches protected truth, non-force adopt fresh protected ancestry and reacquire every then-live repository/security/CodeQL/review/thread/governance gate on one unchanged exact child head.

Dependent #178 has already non-force adopted this exact parent and must retain only its decision-freshness delta. Do not duplicate the fixture repairs in the child.

EgressWeave remains canonical for executable URL/address/DNS/peer/redirect/proxy/TLS/resource authorization. context-graph-contracts and enterprise-architecture-core remain read-only foreign-owner dependencies. No self/model approval, routine administrator bypass, force push/destructive rebase, gate weakening, mutable foreign dependency, source copy, cross-service SQL or predecessor-evidence transfer.

@coderabbitai

coderabbitai Bot commented Sep 6, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Copy link
Copy Markdown
Contributor Author

Fresh exact-head review found a fail-closed scope gap in the new business-authorization binding. DecisionEnvelopeV1 carries the exact policy_id and policy_revision, but BusinessAuthorizationBindingV1 binds only profile_id plus request/destination scope. An authorization admitted for one reviewed policy revision can therefore be replayed unchanged after the decision policy identity/revision changes, while DecisionEnvelopeV1::validate() still accepts the allow. This weakens immutable-policy provenance and lets an old grant survive policy replacement without explicit review.

Repair acceptance: add hostile tests proving a bound allow fails closed if either decision policy_id or policy_revision differs from the reviewed authorization scope, retain a positive exact-match case, then minimally bind authorization evidence to the exact policy identity/revision. Do not add transport/DNS/redirect/TLS authority and do not widen the EgressWeave boundary.

Copy link
Copy Markdown
Contributor Author

Fresh review on exact b844fb6c043faf4fbcb404995fd02bf11367806c found a separate policy-mode binding gap in the same v1 contract family.

The normative #173 design says the allow/deny table is protect-mode behavior and that monitor mode must emit a separate would_allow/would_deny, enforced=false shadow result and must not issue a protect authorization. The current code already models PolicySnapshotV1.mode = protect|monitor, but DecisionEnvelopeV1 carries no policy/evaluation mode at all. DecisionEnvelopeV1::validate() can therefore validate an action=allow, reason=business_authorization envelope without any machine-readable proof that the evaluated policy was protect rather than monitor. A downstream consumer that follows the documented rule to validate the envelope cannot distinguish a monitor shadow result from an enforceable reputation continuation grant.

This is Wardnet-owned decision/policy provenance, not EgressWeave transport authority.

TDD repair acceptance:

  1. hostile RED: a v1 DecisionEnvelopeV1 without an explicit protect-mode binding must not deserialize/validate as an enforceable decision; a monitor-mode candidate must not validate as a protect grant;
  2. keep the existing exact business-authorization allow positive case for protect mode;
  3. minimally bind the envelope to the exact policy evaluation mode, or introduce an equivalently strict separate monitor-result type, so v1 protect consumers cannot accept monitor output by construction;
  4. update TRACEABILITY/contract docs only as needed to keep the already-Proposed docs(egress): plan Wardnet outbound site reputation engine #173 invariant executable; do not add URL/DNS/redirect/proxy/TLS/resource semantics.

Do not claim RED execution until a current-head test actually runs. Current runner/control-plane queues remain separately tracked in .github#712; no source churn solely to force the provider.

Copy link
Copy Markdown
Contributor Author

TDD state for the policy-mode finding: test-only RED source is now exact eab552e2e91168267ef16dac71593832a03825ee, created non-force from predecessor b844fb6c043faf4fbcb404995fd02bf11367806c. The only new delta is the hostile contract test requiring a v1 enforceable decision to carry an explicit protect-policy-mode binding; production model.rs is unchanged.

Fresh exact-head execution has materialized but RED has not executed yet: CI 34050712436 / rust 101533703462 is queued with steps=[], runner_id=null on ubuntu-24.04; Fuzz 34050712442 and focused verifier 34050712463 are also queued. Therefore this head is recorded as test-only RED source, not as an executed failing test. Do not add the production repair until a causal RED executes, and do not churn this source merely to reacquire a runner. Runner evidence is being forwarded to .github#712.

@seonghobae seonghobae added bug Something isn't working priority: high High-priority or P1 work status: draft type: bug Defect or incorrect behavior labels Sep 6, 2026 — with ChatGPT Codex Connector
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working priority: high High-priority or P1 work status: draft type: bug Defect or incorrect behavior

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant