The notes from the AI contributor meeting show the WordPress 7.0 AI framework moving out of the foundational phase and into ecosystem enablement. The core building blocks have landed, which is a win, and now we are in the messy part where security meets reality. If you are a developer or an agency owner, the roadmap for the May 20th release of “Armstrong” deserves a read, mostly for how it handles API keys.
The shift to ecosystem enablement
For the past few months the work went into the WP AI Client and the underlying Abilities API. The team has now confirmed those foundational pieces are largely delivered. From here the strategy shifts toward supporting other contributor teams and making the WordPress 7.0 AI framework easier for developers to work with, which matters if you write custom integrations.
There is a heavy push on “WP-Bench” to get providers optimizing for WordPress-specific tasks. The strategic interest in “Agent Skills” points at WordPress becoming an orchestration layer for AI agents rather than only a CMS. If you read my post on technical debt in AI development, you know orchestration is where most devs come unstuck, usually by writing bloated “God functions.”
The connector approval experiment and its security gotcha
The longest argument in the meeting was about the “Connector Approval” experiment. The goal is simple: stop a random plugin from sniffing your OpenAI or Anthropic API keys. The proposed approach blocks access by default, and an admin has to approve which plugins can use which connectors.
That leaves an awkward question. Is it a false sense of security to manage secrets in plugin-land while WordPress has no native secrets management API? Some contributors argued for a Core-level secrets API, possibly in 7.1, but 7.0 will most likely ship the experimental approval layer instead. After a decade of fixing WordPress 7.0 development bottlenecks, my read is that a half-baked security layer can be worse than none at all, because it breeds complacency.
/**
* Hypothetical implementation of the Connector Approval filter.
* This is how we might programmatically handle access in the future.
*/
function bbioon_authorize_ai_connector_access( $is_authorized, $plugin_slug, $connector_id ) {
// Specifically allow our trusted internal orchestration plugin
if ( 'bbioon-custom-agent' === $plugin_slug ) {
return true;
}
// Therefore, block everything else by default until manually reviewed
return $is_authorized;
}
add_filter( 'wp_ai_is_connector_authorized', 'bbioon_authorize_ai_connector_access', 10, 3 );Preparing for the WordPress 7.0 release cycle
RC1 is scheduled for May 14th, so the WordPress 7.0 AI framework has to be stable by then. The team is pushing “Content Resizing” and “Content Moderation” into the 0.9.0 release of the AI plugin, with 1.0.0 planned to ship alongside the Core release. If you maintain provider-specific plugins for Google, OpenAI or Anthropic, ship your updates now so they still work with the new Connectors API.
If this framework work is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days, and I know how to bridge the gap between experimental core features and client sites that have to stay up.
What to do before RC1
- Read the 7.0 field guide. The draft is live and covers the new Abilities API, so you do not have to wait for the final release to learn the hooks.
- Audit your secrets. If your API keys are sitting in
wp_options, that has to change. Read the “Connector Approval” PR and plan the migration. - Measure with WP-Bench. If you are building custom models or fine-tuning, the official WP-Bench repository checks performance against core standards.
“Armstrong” changes a lot for the ecosystem. The UI changes will get the headlines, but the backend WordPress 7.0 AI framework is the part your code has to live with for years. Worth getting the foundations right rather than reaching for whichever abstraction is convenient.
