WordPress platform annex

What this annex covers

This is a Platform annex. It describes WordPress and nothing else: what its APIs expose to an app, whose personal data that is, how a merchant installs and authorises an app, and what happens to access and data when the app is removed.

It exists so that no other page has to restate it. Every app we publish has its own privacy policy at /legal/apps/, and those policies inherit this annex instead of repeating it. An app policy names the specific permissions that app holds, the records it actually touches, and the retention that applies to it. This annex describes the outer limit: what WordPress makes available to an app that asks for it.

Read the two together with these rules:

• An app never holds more than this annex describes, and normally holds far less. We ask for the narrowest permission a task needs.
• Where an app's own policy and this annex differ about what that app does, the app's own policy governs.
• This annex is a description, not a contract. It does not change your agreement with WordPress. See where the platform's policies govern.

For what an Agent actually does on this platform, see the WordPress platform page.

WordPress is different from the other five in a way that changes every section below. There is no hosted platform sitting between you and your data. Self-hosted WordPress runs on hosting you control, the plugin runs inside your own installation, and there is no platform operator who can revoke an app, mandate a deletion callback or hold a copy of your records. That is a real advantage and a real responsibility, and this annex treats it as both.

This annex covers self-hosted WordPress, the kind you install on your own hosting. {{VERIFY: whether WordPress.com hosted plans need a separate annex, since plugin installation, REST API access and data handling on WordPress.com are governed by Automattic rather than by the site owner alone}}

What this platform exposes to an app

Our agents ship as a plugin. The plugin runs inside WordPress, hooks in with add_action and add_filter, and reads and writes through the WP REST API. Nothing in core and nothing in your theme is patched.

Because the plugin runs inside WordPress rather than beside it, its reach is set by WordPress's own capability model, not by a separate scope list. Every write is made as a user and checked with current_user_can. Take a capability off the agent's role and the write stops, without a code change.

The table below lists the routes and surfaces our WordPress work uses, taken from the WordPress platform page.

Two things to confirm rather than assume:

• {{VERIFY: the current REST route paths and the capability required by each, against the WordPress REST API Handbook and the WooCommerce REST API reference for the versions running on the site}}
• {{VERIFY: which additional REST routes are registered by the plugins already on the site, since any plugin can register routes and a route registered by a third party is outside this table}}

Personal data an app can reach, and whose it is

The personal data on a WordPress site belongs to the site owner's readers, commenters, form respondents, members and buyers. Under the definitions we use across these documents they are End Customers. They are not our customers.

• End Customers. Commenters, form respondents, registered members and WooCommerce buyers. Name, email, IP address, addresses, order history.
• Site staff. Editors, authors and administrators. Their accounts appear at /wp/v2/users exactly as members do, which is why the users route is treated carefully.
• Anyone named in content or an upload. Post content, media files and post meta are unstructured. A PDF in the media library can hold personal data that no database field describes.

For End Customer Data that an Agent reads or writes on your systems, you are the controller and we are the processor. You decide what the Agent does, which systems it reaches, and what it is allowed to write. We act on your documented instructions, which are the scope and configuration we agree with you in writing.

For Service Data, we are the controller.

The WordPress-specific point is that the capability model is the boundary. An agent given an editor's capabilities can read everything an editor can read. It cannot do anything an editor could not do, and that cuts both ways: an editor can usually read comments, and comments carry IP addresses. We name the capabilities the agent needs before we build, and we say plainly when a task needs one we would rather it did not have.

A run trace can contain personal data. On WordPress that means comment authors, form fields and order records end up inside the trace. Trace retention is {{TODO: how long run traces and logs are kept. This one matters, traces can contain end-customer data}}.

How the plugin is installed and authorised, and what you are agreeing to

You install the plugin the way you install any plugin: upload it, activate it, and configure it. There is no app store grant screen and no OAuth consent screen, because there is no platform operator in the middle. That means the authorisation is something we have to make explicit rather than something a screen does for us.

Authorisation on WordPress has two parts:

• A role and its capabilities. The agent runs as a user of your site. That user's role decides what it can read and write, and every write is checked with current_user_can before it runs. This is the control we ask you to set deliberately, not accept by default.
• Credentials for calls that come from outside. Where a run is driven from outside the site rather than in-process, the request has to authenticate. WordPress ships application passwords in core for exactly this. {{VERIFY: whether application passwords remain the recommended authentication method for external REST API calls in the current WordPress version, and whether the site has them enabled, since some hosts and security plugins disable them}}

What you are agreeing to when you activate the plugin:

• Plugin code runs with the same privileges as any other plugin on your site. WordPress does not sandbox plugins from each other. This is true of every plugin you have installed, and it is why we say what ours does rather than asking you to take it on trust.
• The agent's reach is the role you give it. Widening the role widens the agent, immediately and without a code change. Narrowing it narrows the agent the same way.
• Posts the agent writes land at draft or pending. Comments it is unsure about go to hold. Deletion is never an agent action.
• The plugin adds a run log screen to the admin, so what the agent read, what it wrote and which gate it stopped at has an answer on the site itself.

Uninstall and deletion

WordPress separates deactivation from deletion, and the difference is the whole of this section.

Deactivation

Deactivating a plugin stops its code from running. Its hooks stop firing, its scheduled events stop, and the agent stops. Deactivation does not remove the plugin's data. Options, custom tables and post meta the plugin created stay in your database.

Deletion

Deleting the plugin from the plugins screen removes its files and runs its uninstall routine, which WordPress invokes through uninstall.php or a callback registered with register_uninstall_hook. That routine is where a plugin cleans up after itself. What it removes is the plugin author's choice, which is why each of our apps states, in its own policy at /legal/apps/, exactly what its uninstall routine deletes.

Our commitment for a WordPress plugin: the uninstall routine removes the plugin's own options, its run log and any table it created. It does not delete your posts, comments, users or WooCommerce records, because those are your site's data and were not ours to remove.

Revoking access

Because there is no third-party token by default, the reliable revocation steps are yours: deactivate the plugin, remove or downgrade the user account the agent runs as, and revoke any application password issued for it. Any one of those stops the agent. We would rather you knew all three than depended on us performing one.

What we hold

Anything we copied out of your site, including run traces held on our side, is deleted or returned within {{TODO: COMMERCIAL TERM. Days after termination within which client data is deleted or returned}}, subject to the retention terms in the data processing addendum.

WordPress's own privacy tools

WordPress has no platform-mandated deletion webhook, because it has no platform operator to mandate one. Nobody can force a plugin on a self-hosted site to erase anything. What WordPress core does provide is a pair of admin tools that plugins can plug into.

Since version 4.9.6, WordPress ships Export Personal Data and Erase Personal Data tools in the admin, under Tools. An administrator enters an email address, the site confirms the request with the person by email, and WordPress then asks every registered exporter or eraser to contribute. Core registers exporters and erasers for its own data, including comments and user accounts, and any plugin can register its own.

That mechanism is the right place for a plugin of ours to answer a data subject request, and the design of these tools is stable. The specifics should still be read off the current handbook rather than from this page:

• {{VERIFY: the current filter names a plugin uses to register an exporter and an eraser, believed to be wp_privacy_personal_data_exporters and wp_privacy_personal_data_erasers, against the current WordPress Plugin Handbook privacy chapter}}
• {{VERIFY: whether WooCommerce registers its own exporters and erasers for orders and customers, and what it covers, against the current WooCommerce documentation}}
• {{VERIFY: whether the WordPress.org plugin directory guidelines impose any data handling or disclosure requirement on a plugin that sends site data to a third-party service, since our plugins call a model provider}}

Whatever those turn out to say, the position for you is the same: you are the controller and you answer the request. Where our plugin holds anything about the person, it registers an eraser so your existing Tools workflow reaches it, rather than making you email us.

Where someone else's policies govern, not ours

On WordPress there is no platform operator, so this section is about the parties who do sit in the path.

• Your hosting provider. Your host holds your database, your files and your server logs, and its terms and privacy policy govern that. Access logs recording visitor IP addresses are almost always kept by the host, not by any plugin.
• Your other plugins and your theme. Every plugin on a WordPress site runs with full privileges. Anything another plugin collects, sends or sets a cookie for is governed by that plugin's own terms, and is outside this annex and outside our control.
• WordPress.org. If we distribute a plugin through the plugin directory, the directory guidelines apply to us as the developer. That is our obligation, not a term of your agreement with us.
• Cookies on your site. WordPress core sets cookies for logged-in sessions and for remembering commenter details. Your theme, your caching layer and your other plugins may set more. That is your site's cookie position to describe, not ours. {{VERIFY: which cookies the current WordPress core version sets by default, and under which conditions, against the WordPress documentation}} Our cookie policy covers this website only.
• Payments. WooCommerce card handling is done by your payment gateway under its own obligations. It is not something our plugin touches.

Related documents

• App policies. The per-app privacy policies that inherit this annex. Start there if you want to know what one specific app holds.
• WordPress agents. What we build on this platform, the API surfaces we use, and where the human approval gate sits.
• All platform annexes: Shopify, Wix, Ecwid, HighLevel, BigCommerce.
• Privacy policy. How we handle personal data on this website and in agency work.
• Data processing addendum. The processor terms that apply when an Agent touches End Customer Data on your systems.
• AI and your data. What reaches a model provider, and on what terms.
• Sub-processors. Every third party that may process data on our behalf.
• Security. How credentials for this platform are held.

Changes to this annex

We may update this document. When we do, we change the "Last updated" date and add a row to the version history below. Section anchors are stable and we do not rename them, so a link to a section keeps working.

Platform requirements change on the platform's schedule, not ours. Anything on this page marked {{VERIFY: ...}} has not been confirmed against WordPress documentation at the time of writing and must not be relied on until it has been. If you find a statement here that no longer matches what WordPress publishes, tell us at hello@aispeedforce.com and we will correct it and record the change below.

Version history