optional safety metadata on wp_register_ability (snapshot + audit + rollback)

[ibrahimhajjaj]

Hi, I shipped AbilityGuard last weekend, a plugin that sits on wp_before_execute_ability / wp_after_execute_ability and adds snapshot, audit, approval, and rollback on a per-invocation basis: https://github.com/ibrahimhajjaj/abilityguard

Posting here because I want to flag one specific gap I noticed reading mcp-adapter, wordpress-mcp, and the Abilities API side by side, and to ask the team a couple of focused questions before I keep building.

What AbilityGuard does today

• Pre + post snapshots for destructive abilities. Five built-in collectors (post_meta, options, taxonomy, user_role, files), compressed storage, retention policy by status (pending: 7d, ok:
  90d, error: 180d), custom-collector extension point.
• Audit log with caller attribution: REST, MCP (with the MCP client name when it comes through the official adapter), CLI, internal PHP. Parent / child invocation correlation.
• Approval queue with multi-stage capability-gated chains, sequential or parallel ("N of M"). Role-based routing per stage (approval_roles: ['editor', 'admin']) and separation-of-duties
  enforcement (rejects if the same user or role decided the prior stage).
• One-click rollback via wp-admin, REST, and WP-CLI, with drift detection.
• Dry-run mode per-call (safety.dry_run: true): execute, capture post-state, diff, auto-rollback, return {result, diff, rolled_back: true}. Useful for previewing destructive abilities
  without committing.
• Rate limiter per (user_id, ability_name), transient-backed.
• Encrypted redaction (AES-256-GCM) for secrets in args, results, snapshots.
• Concurrency lock per snapshot surface set, MySQL GET_LOCK based.
• /abilityguard/stats REST endpoint feeding a small admin widget: pending / approved / rejected / error counts, p50 and p95 timings, top abilities by invocation count.

Reads meta.annotations.{readonly, destructive, idempotent} from core directly. No parallel metadata. Currently in the wp.org review queue.

What I am not asking for

I am not proposing new safety metadata in core. meta.annotations already covers the hint surface, and per the March 2026 MCP spec post those hints are advisory by design, not enforcement. AbilityGuard is the enforcement layer that reads them and applies policy: approval gates, snapshot-before-execute, rollback. That stays plugin-side.

The actual gap

Automattic's wordpress-mcp shipped a real approval workflow: user_confirmed, confirm_permanent_delete, soft-trash, draft-default. It is being deprecated in favor of mcp-adapter. mcp-adapter has zero approval code today.

If a plugin shipped abilities gated on the old approval flow, the migration path is broken. There is no obvious continuity story.

I opened WordPress/mcp-adapter#176 to track this in the right repo, proposing a minimal approval interface (filter + capability + state enum). Whichever way that goes, it tells me where AbilityGuard's scope sits.

Questions

• Is there appetite for an approval interface in mcp-adapter, or is approval considered plugin-territory permanently? Either answer is useful. The first one means I work upstream, the
  second one tells me AbilityGuard's scope is legit and I keep going where I am.
• Where should rollback semantics live? Per-ability execute_callback author concern, or does it make sense to standardise the snapshot-surface contract (the shape of what gets captured, not
  the implementation) so future first-party tools can interoperate with third-party rollback layers?
• WordPress/ai PR [Feature]: AI Request Logging #437 (Observability Dashboard): my read after looking at the diff is that it is provider-HTTP scope, not ability-execution scope, and AbilityGuard's audit log sits at a
  different layer. Is that the right read?

Happy to demo on a call, or to draft the approval-interface PR for mcp-adapter directly if there is interest.

[jeffpaul]

@galatanovidiu @jorgefilipecosta @gziolo FYI ^

[gziolo]

Worth a look at #11731 (open for feedback, targeted at WP 7.1): adds wp_pre_execute_ability and three other lifecycle filters to WP_Ability. The pre-execute filter is a short-circuit seam allowing return an "approval pending" envelope to queue the call and resume later. Living at the Abilities API layer means mcp-adapter, REST, and direct PHP callers all inherit it without needing their own approval interface.

[gziolo]

wp_pre_execute_ability fires before wp_before_execute_ability, so any observer that built up state in the before-hook (audit row, snapshot capture) has to do that inline in the pre-execute handler instead

I need to study code again later to remember better why I swapped the order. However, it seems like we should run the action before anything else.

[gziolo]

Re-read the code. wp_before_execute_ability fires after input normalization, validation, and the permission check — i.e., at the point where we know the call is actually going to execute. That contract is right, and reordering it would break it for any observer that relies on "this will execute" (cached responses, rate-limited calls, approval-pending envelopes, and dry-runs would all spuriously trip it).

Your audit/snapshot case is a different need: an "invocation entry" signal that fires for every call regardless of outcome. We could cover that with a new action at the top of execute() (before wp_pre_execute_ability runs), so audit and snapshot observers attach there and wp_before_execute_ability keeps its current "execution imminent" meaning. Would that work for AbilityGuard?

[ibrahimhajjaj]

@gziolo

Yes, that contract split is the right call and it works for AbilityGuard cleanly.

You're right that wp_before_execute_ability shouldn't move. Its "execution imminent" semantics are what make it useful for rate-limiter, cached-response, and dry-run observers, and co-opting it for the audit/snapshot case would have been the wrong fix.

What audit and snapshot actually need is a different signal: "the pipeline received this invocation, regardless of outcome." That fires for every call (approval-pending, rate-limited, cached, dry-run, normal) so the audit row exists no matter how the call exits. A new action at the top of execute() before wp_pre_execute_ability is exactly that signal.

On naming + signature, what we'd want:
do_action( 'wp_ability_invoked', $this->name, $input, $this );

Mirrors wp_before_execute_ability in arg shape so observers can attach to both with the same callback signature. Past-tense verb communicates "this has entered the pipeline" without suggesting it'll necessarily execute. Fires before normalization so the input is raw, which is what observers want for audit.

Concrete impact on the AbilityGuard bridge: CoreFilterBridge::on_pre_execute currently writes the audit row inline because nothing earlier exists. With wp_ability_invoked landed, that work moves to an observer listener, and the pre_execute handler shrinks to just "build the approval envelope and return."

[gziolo]

I'll tackle that seperately. Thank you for further clarifying the requirements. It fits nicely in the execution lifecycle 👍🏻

[gziolo]

Now tracked in https://core.trac.wordpress.org/ticket/65248.