RFC: AI governance experiment for role-based usage controls

[WouterP0lman]

Origin and collaboration

This idea emerged during conversations at WCEU. A community member initially raised it, and several people independently explored parts of it afterwards.

I continued the work by turning those discussions into a more concrete local proof of concept and the proposal below. The goal of this issue is to give the idea a shared, maintainable direction within the WordPress AI project.

I do not want to present this as a single-person initiative. The people involved can be credited or tagged here with their agreement.

Problem

The AI plugin makes it possible to connect providers and use AI features, but site administrators currently have no first-party way to answer:

• Which WordPress roles may use AI?
• How much AI usage is acceptable in a given period?
• Which requests, users, or features are responsible for usage?
• What should happen when a limit is reached?

Connector Approvals answer whether a plugin may use a connector. They do not provide role-based access or usage governance for AI requests.

Proposal

Explore an opt-in AI Governance experiment in the AI plugin.

The feature would provide local, site-owned controls for AI access and usage. It would not require a hosted service, central account, remote telemetry, or paid plan.

Existing proof of concept

A local proof of concept has been used to validate the administrator workflow: usage visibility, role policies, limits, provider settings, alerts, and local audit data.

It also revealed an important architectural constraint. Its early enforcement path used pre_http_request, which is too broad for upstream use because it cannot reliably identify the AI client, actor, feature, and model context.

That implementation is not proposed here. Its value is in validating the product need and showing why a provider-neutral lifecycle control point is required.

Important dependency

This experiment needs complete, provider-neutral request lifecycle data.

Issue #732 documents that AI Request Logging currently misses providers that use custom or sidecar transports. Governance controls must not claim complete usage or enforce limits only for some providers.

The lifecycle coverage direction in #732 should be agreed before this experiment implements enforcement.

Suggested v1 scope

1. Enable or disable AI access per WordPress role.
2. Set local request and token limits per role for a defined period.
3. Show a local usage overview by role, user, provider, and feature where context is available.
4. Support a clear action at the limit: warn or block.
5. Record minimal local governance events for administrator review.

Explicitly out of scope for v1

• Cost budgets and provider price tables
• Automatic model downgrades
• Per-user overrides
• Email alerts
• Central reporting or telemetry
• Compliance claims or automated AI Act assessments
• Intercepting arbitrary WordPress HTTP requests

Design principles

• Opt-in WordPress admin experiment.
• Provider-neutral and compatible with supported AI client paths.
• Site-local storage and processing.
• No prompt content stored by default.
• A governance failure must not interfere with unrelated HTTP requests.
• A blocked request must give the user a clear reason and recovery path.
• Limits must have documented behaviour under concurrent requests.
• Single-site and multisite behaviour must be explicitly defined.

Questions for maintainers

1. Does this fit the AI plugin as an experiment, or should it start as a separate feature plugin?
2. Should this extend AI Request Logging, Connector Approvals, or live as a separate experiment?
3. Which canonical lifecycle point should provide policy enforcement and request context?
4. What is the minimum useful v1 data model for single-site and multisite?
5. If the direction is supported, would a small design PR after agreement be useful?

Initial acceptance criteria

• The request lifecycle exposes reliable actor, feature, provider, and model context for supported provider paths.
• A role policy can allow or deny AI access through that lifecycle.
• Request and token limits have documented behaviour under concurrent requests.
• Governance logging stores only the minimum metadata needed for local administration.
• The administrator can understand why a request was warned or blocked.
• The initial experiment has explicit single-site and multisite behaviour.
• No external service, billing, provider-specific interception, or remote telemetry is required.

[dkotter]

Thanks @WouterP0lman for putting this together. I'm definitely on board with adding something like this, I think quite a few people have requested something similar.

One thing to consider is we do already have a PR up that adds user access controls (#749). Some of what is being done there likely matches what is described here so we'll want to ensure we align on a plan between those two pieces (that could mean many things, maybe deciding to close that PR out and approach the problem differently. Maybe slightly change the approach in that PR to match what else is described here).

To answer your questions:

Does this fit the AI plugin as an experiment, or should it start as a separate feature plugin?

Yes, this would be a perfect experiment to add to this plugin

Should this extend AI Request Logging, Connector Approvals, or live as a separate experiment?

Personally I would build this separate from those but they do all kind of relate to each other so just need to ensure it all works together correctly

Which canonical lifecycle point should provide policy enforcement and request context?

We do have #757 open that attempts to resolve #732 but it is stale and needs help to bring it across the finish line.

What is the minimum useful v1 data model for single-site and multisite?

We've not considered much with multisite yet. Not saying we can't do that here but it is something that could be pushed off if we truly treat this as a v1.

In addition, I think the scope proposed here is likely better handled in a few different PRs instead of one larger one. For instance, limiting user access can definitely be it's own PR (or continue work on #749). Then usage limits can be separated out from that

If the direction is supported, would a small design PR after agreement be useful?

If you have time/interest to put something like that together, it does tend to help get useful feedback without having to put the full effort in first