# Early Observability Hooks Trade Completeness for Exposure Risk ## Claim Placing an observation hook as early as possible in a request lifecycle maximizes what it captures — including invalid and rejected attempts — but that same placement, before validation or permission checks run, means the hook also receives raw, unfiltered input that later stages would have sanitized or rejected. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies to any system that fires a lifecycle event for auditing, tracing, or analytics before normalizing, validating, or authorizing the triggering request. - The tradeoff is inherent to the ordering choice, not a bug: moving the hook later (after validation) loses coverage of invalid attempts; keeping it early gains that coverage at the cost of raw-input exposure. - Doesn't argue against early hooks — argues that whoever implements one must treat the raw payload as sensitive by default, logging metadata (counts, timing, identifiers) rather than the payload itself. ## Evidence WordPress 7.1's `wp_ability_invoked` action fires at the very start of `WP_Ability::execute()` — before normalization, validation, permission checks, short-circuiting, approval, or caching. That placement gives it complete coverage of every invocation attempt, including ones that will later be rejected. The dev note flags this explicitly as a privacy hazard: the action "receives raw, unnormalized input," and implementers are cautioned to audit the event rather than collect its payload. ## Links - [[3. Resources/Permanent Notes/Client Contracts Are Prepared at Output Boundaries]] — because contrasts; that claim is about transforming data safely at an *output* boundary, this one is about a hazard created at an *input* boundary — together they sketch a general "boundary discipline" pattern in the same WordPress 7.1 release - [[3. Resources/MOCs/Open Source Governance MOC]] — because applies-in; Core choosing to ship the hazard with an explicit warning rather than either omitting the hook or silently sanitizing (and thereby losing coverage) ## Tests / falsifiers - Find a plugin that logs `wp_ability_invoked` payloads verbatim into a persistent store — if credentials or personal data show up in that store, the exposure risk is confirmed in practice, not just in the dev note's warning. - Compare an equivalent hook placed *after* validation: if it turns out to still capture most of the operationally useful signal (counts, timing) without the raw-input risk, that would weaken the claim that earliness is worth the tradeoff in most cases. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Articles/Abilities API Improvements in WordPress 7.1]] — Milana Cap, Make WordPress Core dev note, 2026-07-31.