Controlling and disabling AI

[JasonTheAdams]

Within the WordPress as an AI Fundamental post, multiple people have expressed concerns around AI models being accessible from WordPress, and would like the ability to disable it entirely — and, at the very least, strictly control it. Especially for sites that house sensitive data, I can see this being a very sensible use case.

Let's use this issue to discuss ways we can do this that allows developers to gracefully hide AI-powered features for such sites.

[JasonTheAdams]

My first thought here is to leverage the Prompt_Builder::supports_x() methods, which developers are encouraged to check at present. I'm thinking we can add two checks that provide control:

1. A hook which runs in both the support and generate methods
2. Custom use_ai user capability check

Custom Hook
The hook simply acts as a kill switch. It would be a boolean filter than is true by default. If false in the support method, it returns false; if false in the generate method, it throws an exception or WP_Error. In both cases, let's pass the context of the prompt in case the developers want to limit a subset of prompts (e.g. text generation only is fine).

Custom Capability Check
Here, I'm imagining a use_ai capability check that's very primitive and, by default, is added to every kind of user role. Developers could remove said capability for specific roles (and/or we could have a filter there, too) to restrict AI access to specific roles.

Now, this doesn't address unauthenticated users. That, I suppose, could be another hook which permits unauthenticated users by default, and can be set to false to prevent unauthenticated AI usage. Perhaps this should be false by default.

I'm just trying to get the ball rolling on this one. I'm not attached to these ideas. I'm more invested in coming up with a safe, secure solution that helps folks feel more confident.

[jeffpaul]

Let's use this issue to discuss ways we can do this that allows developers to gracefully hide AI-powered features for such sites.

Given you'd have to have the AI Experiments plugin active (or some other plugin / custom code that's leveraging the WP AI Client), is this primarily a question of being able to hide certain service providers and/or experiments so someone can NOT enable/configure them?

[JasonTheAdams]

@jeffpaul I don't think so. I believe this is in anticipation of the WP AI Client coming to WordPress in 7.0. I don't think it's about specific experiments, though I could see having control over which providers are available potentially being important to this conversation. In any case, that's why I'm surfacing the conversation here and not in the AI Experiments repo. I believe it has to do with running arbitrary AI prompts (especially passing data to said models) in 7.0 and later.

[felixarntz]

@JasonTheAdams Can you elaborate on what the concrete ask or concern is? Is this about disabling AI entirely, or is it about disabling certain models or certain providers (but leave AI allowed when using other models/providers)?

[JasonTheAdams]

From the comments I've seen, it's about controlling the usage of AI in sensitive contexts. This could be preventing AI calls entirely, preventing specific modalities, limiting to certain providers, etc.

My inclination is to start on the simpler side of things, giving folks the ability to prevent AI entirely on a site, and terminating specific prompts. I'd rather not get too complex/specific until clearer use cases come in.

[juanmaguerrero]

I just read the article and posted a comment there. If it's easier for you, to be able to turn the new AI features completely off (all of it) would be just great for all of us concerned. We really appreciate this!

[kaeldra]

allows developers to gracefully hide AI-powered features for such sites.

Please provide a way for non-technical people like me to disable all AI "features" on our websites, e.g. as a setting in the dashboard.

[justlevine]

@JasonTheAdams does #49 completely closes this ticket out?

From that PR diff and a basic glance of the codebase (looking forward to reviewing the merge candidate 🙇) seems that only disables the prompt building/execution but leaves everything else (ui, registration, discovery) intact. Also can be overloaded ... From the feedback here and downstream seems the request is for a top level supports_ai(): \WP_Error|bool that's checked before any functionality, hooks, chrome, are initialized.

(Long term planning for granularity we'd be able to extend it with a @param string $feature = '' and wrap in whatever eventual current_user_can() permission model early return, but that's not needed to MVP this request)

[felixarntz]

@justlevine where do you see the request for a "top level" off switch?

As far as I can tell, the request is to allow disabling all AI, or all AI features, and the existing filter can be used to do that, by returning false.

It'll lead to every AI feature that uses this SDK to not work, and developers of those plugins can discover that via one of the "is supported" methods. So I don't think there's anything else needed.

[JasonTheAdams]

@felixarntz is right. I've done my best to read between the lines of folks' concerns and come up with a solution that makes sense, but there's been virtually no specificity around what exactly this looks like in practice. The PR we merged does offer a way to prevent prompts from running.

As far as the UI is concerned, it only shows up because the PHP AI Client comes bundled with providers. This won't be the case shortly, as I'm working on pulling them out into their own plugins. So for a site that wants to totally disable AI, they simply won't install any providers.

So I think this Issue is resolved sufficiently based on the ambiguity of the feedback we've received so far. If folks have more specific ideas on this, we can create new, more specific issues. Thanks for raising the question, @justlevine! It is a good double-check!

[justlevine]

@felixarntz from the AI as a WordPress Fundamental post that @JasonTheAdams shared in the OP:

[From desmith] (https://make.wordpress.org/core/2025/12/04/ai-as-a-wordpress-fundamental/#comment-48089)

Will there be appropriate filters to disable this, and to prevent accidental use of any such features? [...]To expand on the pseudocode in the above, I’d like any instances of new AiClient to return an error.

(Jason's suggestion in response is to remove providers. This leaves them intact)

From ahortin

First and foremost, if WordPress intends to invest this heavily in the use of AI, then it also needs to provide a way to turn every single AI option, completely off. Right from the very start!

[From tjnowell]
(https://make.wordpress.org/core/2025/12/04/ai-as-a-wordpress-fundamental/#comment-48112)

Is there a way of turning this off by default at a code level and opting in so that we be sure no plugin is exposing data to AI companies or models that might train or leak data? [...]

From pjohanneson

Also: add my voice to the chorus demanding complete, transparent, and effective opt-out controls on this.

[From pjedavidson]
(https://make.wordpress.org/core/2025/12/04/ai-as-a-wordpress-fundamental/#comment-48180)

as others have said, at least have the decency to allow everyone to turn it off. Completely.

From flberger

by all means they should do so via pluggable components – not making it “a fundamental part”.

For expediency I didn't bother with the discussions in Slack, meeting minutes, or other posts, but you can also see the two replies right above mine in this thread from @juanmaguerrero and @kaeldra . I feel pretty confident saying that folks seem to feel it pretty essential to turn off "all of it", and not just prevent the prompt itself from firing (? this is the part I'm trying to get clarification, what exactly does the filter disable?), as well as making sure that their decision cant be overloaded elsewhere. e.g. WooCommerce or Elementor. And yes rogue plugins too (unless we're hoisting an entirely new exploit vector for the plugins team to be aware of.) The corollary is plugins should integrate AI in a way that that can still be disabled by the user too.

As far as the UI is concerned, it only shows up because the PHP AI Client comes bundled with providers. This won't be the case shortly, as I'm working on pulling them out into their own plugins. So for a site that wants to totally disable AI, they simply won't install any providers.

@JasonTheAdams Thanks for adding, that's good to note. I take it that means the best time for me to offer more practical feedback is once you've done that and where the core entrypoint will be, but this sort of "off switch" modularity isn't a novel engineering problem - even in the WP space. Even without knowing how you're planning to migrate the Composer autoloader, a simple

// class AI_Client {
private static function AI_Client::is_enabled(): bool {
  return defined( 'BYE_AI' ) && BYE_AI ? false : apply_filters( 'wp_ai_enabled', true, get_current_user_id() );
}

that's called in AI_Client::init() should be enough.

if you think preserving the thread here is more important than the extra click for the folks you linked out to and want me to create a new thread lmk, I should have a bit of time after today's call 🙇

[maddisondesigns]

I've just found this thread and wondering why it's been closed when it doesn't look like any solution has been provided. As multiple people (including myself) have been quoted in @justlevine's post above, there needs to be a way to completely disable ALL AI functionality. This include screens like the newly added Settings > Connectors screen added in the recent WP 7.0beta, along with all UI components anywhere else in core (if there are any). A hook or filter that simply restricts a prompt execution is far from an adequate solution!

What happens when a plugin that a site relies on decides that they're now going to hook into your new AI API? Are we now just expected to rebuild the whole website so that we can remove this plugin because they've added AI functionality, because that's not good enough. There needs to be a KILL SWITCH that stops every single AI call, screen and UI component. If you're making AI part of core, then this kill switch also needs to built into the core settings pages as well, rather than forcing people to implement a solution through hooks or filters in a plugin or theme. This solution also needs to roll out with WP 7.0 if you plan on rolling out the AI Client in 7.0. It's not good enough to say that you'll implement this at a later date.

[justlevine]

@maddisondesigns please take a look at https://core.trac.wordpress.org/ticket/64706 and WordPress/wordpress-develop#11149 where work on this continues for 7.0.

Feedback there would be helpful to get it in in time for RC1 next week 🙏