You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`src/lib/yara-hooks.ts` currently has a wizard-side suppression block (`WIZARD_DOC_BASENAMES`, `WIZARD_DOC_PATTERNS`, `isWizardDocumentationPath`) that drops `posthog_pii` matches when the file being written has one of a hardcoded set of basenames.
This was added by Edwin as a band-aid because the original `posthog_pii_in_capture_call` rule was too noisy — it fired on the agent verbatim-copying the user's existing capture calls into inventories or reports.
PostHog/warlock#33 replaces that single noisy rule with two new precision-tuned rules (`posthog_pii_in_person_properties`, `posthog_pii_value_in_tracking_call`). Once the wizard consumes those, the band-aid should go.
Re-run the events-audit, audit (doctor), and posthog-integration programs against representative test apps to verify the new rules don't fire on the wizard's own report/inventory writes.
If clean, delete `WIZARD_DOC_BASENAMES`, `WIZARD_DOC_PATTERNS`, `isWizardDocumentationPath`, and the suppression block in the Write/Edit hook. Remove the matching imports from `@lib/programs/events-audit/constants` and `@lib/programs/posthog-integration/constants` if no other consumer remains.
If the new rules still fire spuriously on wizard docs, don't restore the wizard-side band-aid — file a warlock issue describing the false positive instead. Detection layering belongs in warlock.
Related security finding (deferred, not lost)
The current basename-only check is spoofable: an agent under prompt-injection influence that's steered into writing real PII to a file named `.posthog-events.json` bypasses the PII detector. Removing the band-aid removes the bypass too.
Anchor in code
`src/lib/yara-hooks.ts:307` (basename set), `:317` (patterns), `:322` (predicate). There's a `TODO(warlock-npm):` comment at the suppression site flagging this cleanup.
Why
`src/lib/yara-hooks.ts` currently has a wizard-side suppression block (`WIZARD_DOC_BASENAMES`, `WIZARD_DOC_PATTERNS`, `isWizardDocumentationPath`) that drops `posthog_pii` matches when the file being written has one of a hardcoded set of basenames.
This was added by Edwin as a band-aid because the original `posthog_pii_in_capture_call` rule was too noisy — it fired on the agent verbatim-copying the user's existing capture calls into inventories or reports.
PostHog/warlock#33 replaces that single noisy rule with two new precision-tuned rules (`posthog_pii_in_person_properties`, `posthog_pii_value_in_tracking_call`). Once the wizard consumes those, the band-aid should go.
What needs to happen
Related security finding (deferred, not lost)
The current basename-only check is spoofable: an agent under prompt-injection influence that's steered into writing real PII to a file named `.posthog-events.json` bypasses the PII detector. Removing the band-aid removes the bypass too.
Anchor in code
`src/lib/yara-hooks.ts:307` (basename set), `:317` (patterns), `:322` (predicate). There's a `TODO(warlock-npm):` comment at the suppression site flagging this cleanup.
🤖 Generated with Claude Code