Expose, Govern, Attest — Reading WordPress’s AI stack as a trust model

I came up through WordPress’s earlier democratizations, and they rhyme. In 2012, page builders dropped the floor: you assembled a site instead of hand-coding one, and I was running the community around one of them. Blocks repeated the move around 2018: assemble from parts, not markup. AI is the same instinct one level up — describe the work and point an agent at it. Each wave widened who could build, but also produced fragile sites, because lowering the floor removes friction that once forced inspection. I read this wave through a trust lens: I have watched the floor drop before, and what survives is the discipline someone deliberately puts back in.

WordPress’s AI features look scattered until you see the trust model underneath: exposure, governance, and attestation. The Abilities API exposes schema-described capabilities an agent can invoke. A governance plane — Connector Approvals and Request Logging today, with unified management under discussion — controls access and records the requests it can observe. C2PA work explores detecting credentials on upload and binding provenance claims to outputs. Exposure makes WordPress usable by agents; governance makes that use accountable to the owner; attestation makes provenance claims verifiable beyond the site. Read together, these projects suggest one emerging trust model in three widening rings — capability, site, and artifact — my synthesis of a direction visible across the public roadmap, not a name the project has adopted.

Expose — discoverable capabilities

The foundation has shipped. WordPress 6.9 introduced the Abilities API as a PHP registry through which core, plugins, and themes declare functionality in a standardized, machine-readable format. WordPress 7.0 added the JavaScript counterpart and integrated abilities with the WP AI Client.

What is still converging is the agent-facing layer: a foundational core/* ability set, Skills in the WordPress admin, and the problem of exposing thousands of abilities without overwhelming an agent’s tool selection. The shape is consistent: a capability declares its contract — name, description, schemas, permissions, and implementation — so what WordPress can do is inspectable rather than asserted.

Govern — owner-controlled use

Discovery alone is not trust. Once an agent can find a capability, the site owner needs to decide whether it may use it and inspect what happened afterward. AI 1.0.0, released 19 May 2026, shipped Request Logging, intended to expose AI activity across core, plugins, and themes, and Connector Approvals, which lets administrators decide which plugins may use configured connectors. A proposed Unified AI Management Layer for Core would consolidate permissions, usage metering, and capability-aware provider routing; the proposal recommends deny-by-default for cost safety while acknowledging the compatibility case for allow-by-default.

That limitation is concrete in my own work: Request Logging cannot yet see providers that bypass the SDK’s HTTP transporter (#732), as the local sidecar in my ai-provider-for-codex project does. The principle is not that the log is complete today; it is that accountable AI use requires an inspectable record, and that gaps should become visible engineering work rather than disappear behind a trust claim.

Attest — verifiable provenance

Governance stops at the site boundary. Once an output leaves WordPress, the evidence supporting its origin and integrity has to travel with it or remain recoverable.

The distinction from governance is structural. A governance log gives the owner an internal record. A signed manifest lets an outsider validate a claim’s binding to an artifact, identify its signer, and detect alteration — whether that signer deserves trust is a separate question. It does not make the content true. It makes the claim and later changes testable.

Open C2PA proposals cover detecting existing Content Credentials on upload and signing new provenance claims to post text and images. Durable credentials use additional bindings such as fingerprints or watermarks to help recover a remotely stored manifest when embedded metadata is stripped. This direction aligns with Article 50 of the EU AI Act, scheduled to apply from 2 August 2026, which requires providers of certain generative systems to mark outputs in machine-readable form, making artificially generated or manipulated content detectable. C2PA is one possible implementation path, not the legal requirement itself.¹

These rings are not equally mature. Expose has shipped its foundation, though the default ability set, Skills model, and large-scale agent exposure are still converging. Govern has shipped site-owner controls, while unified management remains proposed. Attest remains open work. That is the WordPress AI project’s state, not the completed architecture I wish it already had.

The external-instrument test

The same logic extends beyond software: a claim becomes more credible when it survives an instrument the claimant does not control. AI Leaders sharpened that principle through impact measurement. Blake Bertuccelli-Booth’s comparison of workforce programs with incubators made the contrast concrete — administrative wage records and long-running randomized trials on one side, self-reported metrics distorted by survivorship bias on the other. Real impact is whatever survives an external instrument.

Read through that lens, the three rings form an accountability architecture. Each gives someone other than the author an instrument to read: a schema others can inspect, a log others can audit, a signature a stranger can verify. My ethics position follows the same principle: trust is not a disclaimer appended after the model answers; it is built into the workflow. I reached the same conclusion in cohort conversations about domains as distant from WordPress as battery governance in rural Mongolia — different systems, but the same need for inspectable decisions and accountable change.

I hold my own work to that standard. I do not ask readers to trust my account of a contribution; I point to current review status, merged changes, and changelog lines, checking GitHub rather than my notes. My portfolio’s proof bar renders state, never intent.

For targets that move faster than memory can settle, I use digests and search for discovery, primary documentation and changelogs for release facts, GitHub for implementation state, and living roadmaps to hold what no single source captures. My WordPress AI roadmap runs a repository census on refresh because even an official board can miss pull requests. I ground the agents I rely on with Cloudflare AI Search, then verify the load-bearing claims myself.

The pattern also appears in what I ship: suggestions stay review-first, applied changes leave an audit row, and a stale claim gets corrected rather than defended.

Putting the friction back

Rapid change does not push me to move faster or guess better. The tooling already does the relentless part — it will carry a half-formed idea to something that looks shipped without flinching. The scarce skill is knowing where to put the friction back: where a capability needs permission, an action needs a record, an artifact needs a verifiable claim, and my own conclusion needs checking. Each instrument here is exactly that — friction deliberately placed where a claim needs evidence instead of trust, mine included.

¹ A May 2026 provisional agreement would give systems already on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2). The Council compromise text contains the proposed amendment. Because it is not yet final, the body states the current rule and treats the grace period as pending. ↩