A governance product earns trust by holding itself to the same standard it sells: verify the claim against the code. Version 1.6.2 is a large hardening release, mostly correctness and security fixes across WooCommerce, the audit log, ACF, and the MCP endpoint, and it opens with us correcting a claim we had been making about our own audit log. Version 1.6.3 followed right behind it, a small release that condensed the changelog so it stays readable. Neither one widens what an agent can do. This post walks the themes and points to the longer write-ups where there is more to say.
We corrected what our audit log claims
For a long time both the plugin readme and this site said the audit log stores the argument keys but never the values. That was too absolute, and it was our claim to get right. Since 1.5.0 the log has, by design, kept a short note of identifier-only values, such as ids, slugs, and status values. What it has never stored is free-text content, so a post body or an email address does not land in the log. In 1.6.2 the plugin corrected its own wording to say exactly that, and this site was corrected to match in the same pass.
The log was doing the right thing. The claim was the thing that was off, and an honest, precise record is worth more than a tidy absolute. The full reasoning is in what the audit log actually stores.
Customer data sits behind the right capability
Editing a WooCommerce customer over the MCP endpoint used to require only the manage-WooCommerce capability, which in practice let a caller with that one capability read and overwrite any user’s billing details. Editing a user and managing a store are not the same permission. So the endpoint now requires a real user-editing capability on that specific account before a customer edit goes through, and the same gap in the user-meta and ACF user-field writes was closed at the same time.
Names, emails, and addresses now sit behind the capability meant to guard them, not a broad store-management one. There is more on the WordPress capability model at play in editing customer data should need the capability that guards it.
The audit trail records the true cause, on every path
A record you cannot trust is worse than none, so three fixes went to the trail itself. A call blocked by read-only mode was being logged as “high-risk locked,” the wrong cause in the exact row meant to explain the block; it names read-only mode now. Enabling or disabling abilities through Quick Connect or the bridge tab used to leave no audit rows while the main settings save did; every path writes them now, including a blocked enable under read-only mode. And a caller with valid credentials on a blocked IP could flood the log with denial rows; those are capped per source now, the same way failed logins already were.
The theme, and why each property matters when you actually sit down to review what an agent did, is in an audit log is only useful if you can trust what it records.
Sanitization with no blind spots
Input that arrives from an agent is untrusted, and sanitization cannot skip a corner because of where a value happens to sit. ACF fields inside flexible-content layouts, and clone fields, were being treated as unknown plain text. That flattened rich text and, worse, let a javascript: link slip through, because the field was never resolved to its real type. The sanitizer now resolves layout and clone sub-fields at any nesting depth, so a field is cleaned according to what it actually is, however deeply it is nested. A sanitizer with a depth limit is a sanitizer with a hole, and this closes it. It is the same posture as the 1.4.1 standards release: the edges are where trust is won or lost.
Smaller correctness fixes across the catalog
The rest of the release is the unglamorous work that keeps a governed tool honest. Several WooCommerce writes that reported success while changing nothing, deletes that removed nothing, order-status changes that failed to apply, and per-line refunds that quietly became full refunds, now confirm or refuse before they report success. Bad values that used to be coerced silently, an unparseable date, a non-numeric coupon amount, a negative limit, an unknown tax class, are refused now. An enabled admin-only tool could leak into a lower-privileged connection’s tool list, and an SEO head read could return for a post type the operator had not exposed; both are closed. And on multisite, the plugin’s tables are created on every site, including ones added later.
What 1.6.2 and 1.6.3 are, and are not
Neither release adds a feature or widens what an agent can do. 1.6.2 tightens correctness, makes the audit trail record the true cause on every path, and corrects a claim so the words match the code. 1.6.3 condensed the changelog, because a record of what changed is only useful if you can read it. If you run the plugin, both are worth taking. You can see the current posture on the features and security pages.