Op 20 mei 2026 verscheen WordPress 7.0 "Armstrong" met AI-providerconfiguratie in wp-admin. Handig, maar de echte verandering zit niet in het knopje: een AI connector-key is nu een sitebrede credential waarmee plugins kosten kunnen maken, data kunnen routeren en de vertrouwensgrens van je site kunnen oprekken. Behandel zo'n key dus net als SMTP-, payment- en backupcredentials, niet als een vrijblijvende feature-toggle.
TL;DR
- WordPress 7.0 bevat een provider-onafhankelijke PHP AI Client en een Settings > Connectors-scherm, maar core bundelt geen OpenAI-, Google- of Anthropic-providerimplementaties. Die providers zijn losse WordPress.org-plugins.
- AI-aanroepen vragen expliciete providerconfiguratie en expliciete code die de AI Client aanroept. Een verse WordPress 7.0-site stuurt niet vanzelf prompts of content naar externe AI-providers.
- Connector-keys die via wp-admin worden opgeslagen zijn gemaskeerd, maar niet versleuteld in de database. Trac #64789 staat op 4 juni 2026 nog open en op Future Release.
WP_AI_SUPPORT=falseis in 7.0 de sterkste globale uitknop, omdat plugins hem niet meer via dewp_supports_ai-filter kunnen overrulen.
Inhoudsopgave
- Wat WordPress 7.0 echt heeft veranderd
- Waarom een connector-key operatiebezit is
- Opslagvolgorde en het plaintext databaseprobleem
- De pluginvertrouwensgrens
- Welke remmen WordPress 7.0 wel geeft
- Wat de aparte AI-plugin niet bewijst
- Beleidschecklist voordat je connectors aanzet
- Wanneer ik AI gewoon uit zou laten
- Belangrijkste punten
Wat WordPress 7.0 echt heeft veranderd
WordPress 7.0 voegde twee onderdelen toe die hier belangrijk zijn. Het eerste is de AI Client, een provider-onafhankelijke PHP-API die je via wp_ai_client_prompt() aanroept. Het tweede is de Connectors API met het Settings > Connectors-scherm, waar beheerders externe serviceverbindingen kunnen instellen. De 7.0 Field Guide plaatst dit onder de AI building blocks van de release.
Dat klinkt alsof WordPress "AI heeft toegevoegd". Preciezer: WordPress heeft gedeelde infrastructuur toegevoegd die plugins kunnen gebruiken. Changeset 61700 is hier de bron die ik erbij zou houden. Daar staat dat er standaard geen AI-providers worden meegeleverd, en dat WordPress geen prompts of data naar externe diensten stuurt zonder expliciete configuratie en expliciete aanroepende code.
De eerste uitgelichte providers zijn Anthropic, Google en OpenAI, maar hun implementaties zijn losse plugins op WordPress.org: AI Provider for Anthropic, AI Provider for Google en AI Provider for OpenAI. WordPress 7.0 installeren en een providerplugin installeren zijn dus twee aparte operationele keuzes.
Die nuance is belangrijk voor site-eigenaren die alleen de koppen over AI in core zien. Doe je niets, dan gebeurt er ook niets nuttigs of riskants vanzelf. Installeer je een providerplugin, configureer je een key en installeer je code die de AI Client aanroept, dan heeft je site een route naar een extern modelplatform. Daar begint beleid.
Wil je de bredere releasecontext, dan staat die in mijn eerdere overzicht van WordPress 7.0 voor site-eigenaren. Hier focus ik op de security- en operatiekant van connector-keys.
Waarom een connector-key operatiebezit is
Een connector-key is niet alleen een geheime string. Het zijn drie dingen tegelijk.
Eerst is het een facturatieroute. Het provideraccount achter de key betaalt voor requests, en WordPress core 7.0 levert geen maandbudget, tokenlimiet of kostendashboard per plugin. De WordPress AI GitHub-issue over usage safeguards and cost awareness laat zien dat die behoefte bekend is, maar dat maakt het nog geen corefunctie in 7.0.
Daarna is het een dataroute. WordPress core bepaalt niet wat een plugin in een prompt stopt. Een plugin kan een titel, afbeeldingsmetadata, een conceptalinea, een WooCommerce-producttekst, een formulierinzending of een stuk private pagina-inhoud meesturen. De AI Client levert de leiding; de aanroepende plugin bepaalt wat erdoorheen gaat.
Tot slot is het een pluginvertrouwensgrens. De AI Client zorgt er bewust voor dat pluginontwikkelaars niet zelf met credentials hoeven te werken. Dat is netjes API-ontwerp. In de praktijk betekent het ook dat een geconfigureerde providerroute beschikbaar wordt voor geïnstalleerde WordPress-code die de AI Client aanroept.
De goede vraag is dus niet "moet deze site de AI-feature aanzetten?" De betere vraag is: van wie is het provideraccount, welke plugins mogen het gebruiken, welke data mag de site verlaten en wie krijgt de rekening als een bulkactie opeens 40.000 prompts genereert?
Opslagvolgorde en het plaintext databaseprobleem
Voor api_key-connectors zoekt WordPress credentials in deze volgorde: environment variable, PHP-constante en daarna de database-instelling uit het adminscherm. De Connectors-devnote geeft ANTHROPIC_API_KEY als voorbeeld van een environment variable, define( 'ANTHROPIC_API_KEY', 'sk-...' ); als constante en connectors_ai_anthropic_api_key als database-instelling.
Die volgorde is goed voor operations. In productie beheer ik keys liever via deployment of hostingconfiguratie dan via wp-admin. Een environment variable of PHP-constante kan een databasekey overrulen, overleeft een database-restore beter en houdt de bron van waarheid buiten de contentdatabase.
Maar verwar dat niet met sandboxing. In een Make/Core-discussie onder de Connectors API-devnote legt Greg Ziolkowski uit dat de key een site-instelling is en dat elke plugin erbij kan. Hij zegt er ook bij dat hetzelfde geldt voor environment variables en constanten, omdat geïnstalleerde derdepartijcode die ook kan benaderen. Met andere woorden: env vars en constanten geven je betere operationele controle. Ze maken onbetrouwbare plugins niet veilig.
De database-route vraagt extra aandacht. Databasekeys worden gemaskeerd in de UI, maar de Connectors-devnote zegt expliciet dat ze niet versleuteld zijn. Trac #64789 beschrijft AI-providerkeys als plaintext option values en houdt de security-audit op Future Release. Trac #64793 repareerde voor 7.0 een specifiek maskeringsprobleem in wp-admin/options.php, maar maskeren is schermbescherming. Het is geen encryptie.
Concreet: staat een live key in de database, ga er dan vanuit dat hij mee kan reizen met database-dumps, staging-refreshes, lokale ontwikkelkopieën, backuparchieven en supportexports tenzij je hem scrubt. Je staging-script moet dus connectors_*_api_key kennen, niet alleen OPENAI_API_KEY.
De pluginvertrouwensgrens
De vertrouwensgrens in WordPress is geïnstalleerde PHP-code. Dat was voor AI al zo, maar AI-connectors geven die grens een nieuw gevolg: een geïnstalleerde plugin kan potentieel externe modelaanroepen doen via de sitebrede credentialroute.
Dat sluit direct aan op het oudere WordPress-securityprobleem: plugins zijn op de meeste sites het grootste praktische aanvalsoppervlak. Ik schreef daar eerder over in WordPress plugins zijn je grootste beveiligingsrisico. AI vervangt dat risico niet. Het voegt een nieuwe uitkomst toe wanneer een plugin slordig, te breed of gecompromitteerd is.
Het subtiele risico is niet alleen keydiefstal. Een gecompromitteerde plugin hoeft de ruwe key misschien helemaal niet uit te lezen of te exfiltreren. Hij kan ook kosten maken via de geconfigureerde provideraccount door AI Client-aanroepen te doen, en gevoelige promptinhoud meesturen als de plugin binnen WordPress bij die inhoud kan.
Agencies moeten AI-capable plugins daarom behandelen zoals payment gateways of SMTP-plugins. Vraag voor goedkeuring wat de aanroep triggert, welke rollen hem mogen triggeren, of hij via cron of bulkacties draait, welke contentvelden worden meegestuurd, of de plugin feature detection gebruikt en of hij gesloten faalt wanneer er geen provider is geconfigureerd.
Dezelfde gewoonte heb je nodig bij platformplugins die een brug naar infrastructuur leggen. In mijn artikel over het securitymodel van de Cloudflare WordPress-plugin ging het over een andere route naar externe controle. AI-connectors zijn een andere brug, maar de reviewvraag is hetzelfde: de plugin is niet alleen UI. Hij is een route naar een ander account.
Welke remmen WordPress 7.0 wel geeft
WordPress 7.0 geeft je wel degelijk nuttige remmen. Ze zijn echt. Ze zijn alleen niet compleet.
De sterkste globale rem is:
define( 'WP_AI_SUPPORT', false );Na changeset 62239 stopt wp_supports_ai() meteen wanneer WP_AI_SUPPORT expliciet false is, nog voordat de wp_supports_ai-filter draait. Een plugin kan AI-support dus niet zomaar via die filter weer aanzetten. Voor managed fleets en klanten zonder goedgekeurd AI-beleid zou ik dit als standaard kiezen.
Voor fijnmaziger controle documenteert de AI Client-devnote wp_ai_client_prevent_prompt. Die filter kan specifieke promptuitvoering blokkeren. Als hij blokkeert, wordt er geen AI-call geprobeerd, support checks geven false terug en generation methods geven WP_Error.
Feature detection is een tweede belangrijk kwaliteitscriterium voor plugins. Methoden zoals is_supported_for_text_generation() en is_supported_for_image_generation() controleren of een gewenste capability beschikbaar is zonder API-call en zonder kosten. Een plugin die aanneemt dat "WordPress 7.0" automatisch "AI beschikbaar" betekent, is nog niet productiewaardig.
Wat deze remmen je niet geven: per-plugin approvals in core, maandbudgetten, budgetten per klant, een centraal auditlog, versleutelde key-opslag of toestemmingsregistratie. WP_AI_SUPPORT=false is een kill switch. wp_ai_client_prevent_prompt is een poort. Feature detection is een beschikbaarheidscheck. Geen van drieën is volledig operatiebeleid.
Wat de aparte AI-plugin niet bewijst
De canonieke AI-plugin is het volgen waard, omdat daar praktische governance-ideeën al zichtbaar worden. Release 1.0.0 voegde Request Logging en Connector Approvals toe als experimenten, en de Make/AI-update beschrijft die als observability and governance tooling.
Dat is nuttig signaal. Het is geen garantie van WordPress 7.0 core.
Die nuance raakt snel kwijt in klantgesprekken. Een site-eigenaar hoort "WordPress heeft connector approvals" en denkt dat elke 7.0-site per-plugin toestemming afdwingt voordat connectors gebruikt worden. Dat zeggen de corebronnen niet. Core levert de AI Client, Connectors-infrastructuur en de remmen hierboven. De aparte AI-plugin experimenteert met logging en approvals als pluginfunctionaliteit.
Mijn praktische lezing: heb je vandaag WordPress-side observability of connector approvals nodig, evalueer die AI-plugin dan bewust. Neem niet zomaar aan dat hij is geïnstalleerd, ingeschakeld, stabiel genoeg voor je risicoprofiel of verplicht op elke site. Experimenten kunnen nuttig zijn zonder dat je er je beleid aan uitbesteedt.
Beleidschecklist voordat je connectors aanzet
Dit is het minimumbeleid dat ik zou willen zien voordat een productieconnector op een klantsite aan gaat.
Credential ownership. Leg vast wie het provideraccount bezit, wie betaalt, wie keys mag maken, wie ze mag roteren en wie provider-side usage logs mag bekijken. Gebruik niet standaard één agency-brede key voor losse klanten, tenzij je daar echt goede accounting- en incidentresponsprocessen omheen hebt.
Provider allowlist. Documenteer goedgekeurde providers en toegestane capabilities. Tekstgeneratie, beeldgeneratie, web search, function calling en speech generation vallen niet in dezelfde risicoklasse. Een plugin die web search of function calling kan triggeren verdient strengere review dan een handmatige alt-teksthelper.
Omgevingsscheiding. Gebruik aparte keys of projecten voor local, staging en productie. Productiekeys horen niet in staging te verschijnen na een database-refresh. Hier stopt een fatsoenlijke WordPress staging-workflow met "handig" zijn en wordt hij gewoon een control.
Key source standard. Gebruik in productie bij voorkeur environment variables of PHP-constanten. Sta databasekeys alleen toe voor laag-risico tests, lokale ontwikkeling of expliciete uitzonderingen waarbij de klant zelf wp-admin beheert. Scrub connectors_*_api_key bij databasekopieën.
Plugin approval. Inventariseer plugins die wp_ai_client_prompt aanroepen, connectors registreren, prompttekst via REST-endpoints aannemen of het aparte wp-ai-client JavaScript-package enqueuen. Eis duidelijke trigger points en role checks voordat je ze goedkeurt.
Rollen en admin-toegang. Behandel manage_options als gevoeliger zodra connectors actief zijn. Geef redacteuren geen Administrator omdat dat sneller is dan rollen goed instellen.
Budgetcaps bij de provider. Zet harde limieten, alerts en per-site of per-klant projecten in de dashboards van de provider. WordPress 7.0 core is niet je facturatievangnet.
Logging en review. Bekijk providergebruik na het inschakelen van een connector, na installatie van een nieuwe AI-capable plugin, na het toevoegen van een admin en na grote pluginupdates. Gebruik je de Request Logging-experimenten uit de AI-plugin, zie dat dan als extra zicht, niet als je enige waarheid.
Toestemming en privacy. Bepaal welke datacategorieën naar providers mogen: publieke posts, concepten, reacties, formulierinzendingen, orders, klantnotities, logs. Voor gereguleerde sites zou de standaard moeten zijn: geen persoonsgegevens, medische data, financiële data of juridische inhoud in prompts zonder expliciete goedkeuring.
Rotatie en incidentrespons. Schrijf het eerste uur van een incident uit: zet WP_AI_SUPPORT=false als je meteen wilt stoppen, revoke providerkeys, verwijder databasekeys, roteer env/constant keys via deployment, bekijk providergebruik, controleer recente plugin- en adminwijzigingen en zet pas weer aan nadat het beleidslek dicht is.
Wanneer ik AI gewoon uit zou laten
Voor veel zakelijke sites is de conservatieve standaard simpel: laat AI uit totdat er een echte workflow is die het nodig heeft. Een brochuresite zonder redactieteam heeft geen live OpenAI-key in productie nodig omdat een toekomstige plugin hem misschien ooit gebruikt.
Ik zou AI ook uit laten bij klanten die de eigenaarschapsvragen niet kunnen beantwoorden. Weet niemand van wie het provideraccount is, wie budgetalerts krijgt of wie op vrijdagavond de key kan intrekken, dan is de connector niet productierijp.
Hetzelfde geldt voor sites met rommelige adminrollen. Hebben zes mensen Administrator-toegang omdat niemand na de projectoverdracht permissions heeft opgeruimd, fix dat dan eerst. AI connector-instellingen maken brede admin-toegang net wat risicovoller.
Voor agencies is de praktische standaard: WP_AI_SUPPORT=false op unmanaged sites of sites zonder beleid, en daarna per site opt-in. Dat is niet anti-AI. Dat is gewoon credentialhygiëne.
Belangrijkste punten
- WordPress 7.0 bracht op 20 mei 2026 AI-infrastructuur: een PHP AI Client en Settings > Connectors. Providerimplementaties voor Anthropic, Google en OpenAI zijn losse plugins.
- WordPress stuurt niet automatisch data naar AI-providers. Het risico begint wanneer een provider is geconfigureerd en geïnstalleerde code de AI Client aanroept.
- Databasekeys voor connectors zijn in 7.0 gemaskeerd maar niet versleuteld. De
options.php-maskeringsfix is nuttig, maar geen secrets-systeem. - Environment variables en PHP-constanten zijn betere productiestandaarden, maar geïnstalleerde WordPress-code kan de geconfigureerde AI-route nog steeds gebruiken.
WP_AI_SUPPORT=falseis de sterkste globale uitknop;wp_ai_client_prevent_promptis de praktische hook voor fijnmaziger promptblokkering.- Zet connectors pas aan wanneer credential ownership, provider allowlists, omgevingsscheiding, plugin approval, budgetten, logging, privacy en rotatie op papier staan.