feat(rules): forward wd_clearance on tripwire violations (#136 SDK half)#7
Merged
Conversation
Makes tripwires drive enforcement. When a tripwire (honeypot path — intent a real user can't fake) fires, the violation now carries the request's wd_clearance token so the backend can deny the actor's device fingerprint — the same durable, rotation-proof lockout a decoy hit produces. - ViolationEvent gains clearance?: string. - rule-engine extracts wd_clearance from the request Cookie header and attaches it ONLY to tripwire violations — heuristic rules (filter, rate-limit) never carry it, so only the deception signal drives the deny-list. - Tests cover the extract + the tripwire-only gating.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The SDK half of #136 (pairs with the app PR). Makes tripwires drive enforcement — the deception primitive, not the behavioral mint gate, feeds the deny-list.
What changes
When a tripwire fires (a honeypot path a real user can't reach — intent, unspoofable by a better fingerprint), the violation now carries the request's
wd_clearancetoken. The backend uses it to deny the actor's device fingerprint: the same durable, rotation-proof lockout a decoy hit produces (#124).ViolationEventgainsclearance?: string.rule-engineextractswd_clearancefrom the request Cookie header and attaches it only to tripwire violations. Heuristic rules (filter, rate-limit) never carry it, so only the ground-truth deception signal drives the deny-list — the behavioral/heuristic layers stay observability, not enforcement.Tests
rule-engine.test.ts(4): token extracted for a tripwire; not attached for a non-tripwire DENY; undefined when there's no cookie or nowd_clearance. Fullsrc/rulessuite green (20).