Defensive Data Design: WordPress’s Safety Rules for AI Agents

The most interesting thing about the agent era is not what agents can do; it is what they are allowed to break. When an autonomous process gets a permission gate, a REST endpoint and a natural-language prompt, what stops it from wiping a category tree at three in the morning because a customer-service assistant “wanted to clean up”?

For a long time the answer was “hope, and a backup”. Matt Mullenweg publishing Defensive Data Design on Make/Core this morning is the first attempt to write that answer down as a doctrine. It is short, opinionated, and it lines up almost too neatly with the Abilities API and JSON Schema work that landed in the last two weeks of WordPress 7.1 Beta.

I read it twice this morning. Once as a WordPress lifer who has watched three “revolutionary” content platforms silently vanish while a 2005 install still upgrades cleanly. Once as somebody with an internal agent on staging that already lists the last twenty WooCommerce orders on request. Both readings landed the same way.

What is actually new

The Defensive Data Design post is not a merge proposal and not a dev note. It is Matt setting out design considerations for the agent-driven future, with safe defaults as the through line. The principles, in his words:

• “Putting something in the trash should be easy; deleting should be very hard.”
• “Proposing a draft should be easy; publishing to the world should be hard.”
• Changes should be reversible and visible wherever possible.
• Data visualisation should enhance legibility and comprehension, not obscure it.
• Error messages should use conversational language, with a copy-to-clipboard button so people can paste them into search or an AI.
• Errors should explain the why, not just the what.
• Failure should be graceful and minimise potential harm or data exposure.
• Treat everything — networking, formatting, structure — as unreliable and potentially hostile.
• Maximise visible information; avoid unnecessary clicks.
• Use plain, obvious, natural language, with a bit of personality.

What makes the timing striking is the plumbing that showed up in Make/Core the week before. The Abilities API execution lifecycle filters gave core the four hooks that let developers short-circuit, normalise input, override permissions and reshape the result of any ability call. The JSON Schema preparation function put a clean boundary between the schema a server holds and the schema a client sees, so PHP callbacks never leak into an AI tool declaration. And on August 3, Joe Dolson quietly added wp_get_tooltip() and wp_get_toggletip() — the small, boring functions that turn “click this icon” into “click this icon to move a widget”, which is the plain-language visibility Matt is arguing for.

Picture: doctrine on Tuesday, filters the week before, schema safety the week before that, tooltip functions the day before. WordPress 7.1 is due August 19, 2026, with RC1 tomorrow. The primitives shipped first; the philosophy shipped second; unusually for our project, they agree with each other.

Why it matters for WordPress / WooCommerce people

The two “easy vs hard” lines are the whole show. WordPress has quietly had that trade in the trash bin, revision history and the draft/publish split for fifteen years. What Matt is doing is naming it and telling contributors to apply the same asymmetry to any surface an AI agent can touch. “Cancel this order” should be easier than “refund and permanently delete it”. The friction is not there for humans; it is there for machines that can loop a mistake ten thousand times before anyone notices.

For a WooCommerce agency the mapping is close to one-to-one. Every hosted commerce platform I have watched clients migrate to and back from had two flavours of destructive action stitched into a single button. On WordPress you get to choose. Coupons that expire instead of vanish. Orders that go to a cancelled bucket with a thirty-day countdown before actual removal. Customer accounts that anonymise in place before they are dropped. None of that is new capability. What is new is a doctrine that says: when you wire an ability into core/read-orders or a private store/refund-order, the easy path is the reversible one and the hard path is the destructive one, on purpose.

The principle about hostile everything lands with equal force. Any senior WordPress dev already writes defensively against a network that will time out and a plugin that will filter a hook in a way you did not expect. Extending that posture to arguments arriving from an MCP client, or to a chat model that will hallucinate a valid-looking product ID, is the same discipline pointed at a new source. WordPress’s oldest habits — sanitise on the way in, escape on the way out, capability-check before you act — travel into the agent surface without much translation.

What I would do (or not do) about it

Print the ten principles. Stick them on the wall. Not as a marketing poster, as a code review checklist. The next time somebody on your team registers an ability that “just deletes a product for the agent”, the checklist tells you what the reviewer’s first question should be: is there a soft-delete path first, and does the agent get that one by default while the hard delete needs a second, explicit permission?

Concretely, three things this week on any estate that already has agent surfaces in staging. First, audit every custom ability against the trash-vs-delete lens. If the ability can only destroy — no reversible option, no trash bucket, no draft equivalent — split it in two before RC1 lands tomorrow. The wp_ability_permission_result filter is the seam for saying “the agent can call the soft path always, and the hard path only when a human has approved it in the last five minutes”. Write that filter in a mu-plugin, versioned with the site.

Second, rewrite your ability error strings the way Matt describes them. “Order 4821 cannot be refunded because it was already fully refunded on 2026-07-30” is a message a model can use to stop looping and pass the failure back to a human. “Error: ORDER_STATE_INVALID (code 42)” is a message a model will retry three times and then confidently lie about. One afternoon through your error-handling code; highest-leverage change on the list.

Third, do not build a plugin that “adds a UI to configure defensive design settings”. The defaults are the safety; the moment someone can flip them off in a settings screen, the safety is gone for whoever forgot to lock the screen down. Put it in code review and in the mu-plugin, not in an option. And do not stack this audit on top of the WooCommerce 11.0 upgrade window opening today after last week’s RC1 fatal — two moving pieces on the same estate on the same afternoon is how you spend a Saturday narrowing which one broke.

Every WordPress release cycle has a moment where the project’s philosophy and its plumbing agree with each other. This is one of them. The 7.1 GA on August 19 will get the release-notes coverage; Defensive Data Design is the note under it that determines whether the abilities you build on top are the ones you can leave running on a Sunday night.