What is the difference between a plugin and an external service publishing to WordPress?

A plugin executes on your server, inside wp-admin, with whatever capabilities the installing administrator has, and stores its configuration and keys in your database. An external service never runs on your server; it calls the WordPress REST API with an Application Password tied to a specific user, so it can only do what that user's role allows, cannot log into the admin, and can be cut off by revoking one credential.

How many WordPress plugins is too many?

There is no fixed number; quality and overlap matter more than count, and well-run sites typically sit in the low teens. The better question is whether each plugin does something only a plugin can do. Content drafting, review and publishing can happen entirely outside the site through the REST API, so an AI writing plugin is usually adding surface area for a job that does not need to run on the server at all.

← All posts

WordPress AI Plugin or External AI Writer? The Security and Bloat Question Marketers Skip

Q: Are WordPress AI plugins safe?

Some are well maintained and some are not, and the category has a track record. The most widely recommended AI plugin disclosed three significant vulnerabilities between late 2025 and 2026, including one that exposed bearer tokens on more than a hundred thousand sites and one authentication bypass. Any plugin runs as PHP inside your site with the reach of the admin that installed it, and an AI plugin additionally holds API keys, so the blast radius of a flaw is the whole site plus your AI account.

Q: What is the give-the-writer-an-Editor rule?

Create a dedicated WordPress user for publishing with the Editor or Author role, never Administrator. Issue that user one named Application Password. Any tool that publishes through it can create and edit posts and media and nothing else: no settings, no plugins, no themes, no users. If the credential leaks, revoke it; the site is untouched.

Every “best AI plugin for WordPress” list makes the decision sound like a feature comparison: this one has a chat widget, that one writes meta descriptions, this one is cheaper per month. What none of them asks is the question a developer would ask first, and it is the one that decides whether the choice is safe: where does the code run, and what can it reach?

A plugin runs on your server, inside wp-admin. An external service runs somewhere else and talks to your site through an API. That difference is not a detail. It determines what happens when the thing has a bug, which, in this category, it has. This post lays out the two models, what the last year of vulnerability disclosures showed, why WordPress 7.0 raised the stakes, a rule that limits the damage either way, and how a marketing team without a developer should decide.

Two models

The plugin. PHP that executes inside your WordPress installation. It is installed by an administrator and runs with that reach: it can read and write the database, call other plugins, alter settings, and, in the case of an AI plugin, store your OpenAI or Anthropic or Google API keys in the options table so it can call the model on your behalf. Its update cadence is the developer’s. Its security is the developer’s. It is, functionally, a piece of your site.

The external service. Software that never runs on your server. When it needs to publish, it calls the WordPress REST API, which has been in core since 2016, and authenticates with an Application Password, which has been in core since version 5.6. An Application Password belongs to one WordPress user, is named for the application that holds it, works only for API calls, cannot log into the admin, and can be revoked alone without touching the user’s real password. The service can do what that user’s role permits and nothing else.

Both models can write a blog post. Only one of them can also break your site.

What the last year showed

The plugin most often at the top of the AI-plugin lists, the one recommended for developers and agencies, disclosed three significant vulnerabilities between late 2025 and 2026.

October 2025, CVE-2025-11749. A no-authentication MCP endpoint exposed bearer tokens through the public REST namespace on more than a hundred thousand sites. Anyone who could read the endpoint could obtain credentials to act on the site.
An authentication bypass in versions 3.4.0 through 3.4.1.1, through a remote-management integration, allowing actions without proper login.
2026, CVE-2026-16954. Secrets rendered unredacted in an admin inline script, fixed in version 3.6.4.

None of this is an argument that the developer is careless; the fixes shipped, and that plugin is better maintained than most. It is an argument about the model. A plugin flaw is a site flaw. When the plugin holds AI keys and can act as an administrator, a flaw exposes the keys and the site together. That is the blast radius you accept when the code runs inside wp-admin, and no amount of feature comparison changes it.

WordPress core has responded to the category’s pace: plugin releases that touch AI now get an additional review window before distribution. That is a sign of how much new code is arriving, not a guarantee about any of it.

WordPress 7.0 raised the stakes

WordPress 7.0 introduced a Connectors API that centralizes AI provider credentials so that every AI plugin on a site can share the same keys instead of each storing its own. For site owners it is tidier. For security it concentrates the target: one compromised plugin now has the credentials every other AI plugin uses, and a marketing site running three AI plugins (a writer, an image generator, a chatbot) has three ways in to one set of keys.

The safest number of plugins holding your AI keys is zero. That is only possible if the AI work happens off the site.

How many plugins is too many? There is no magic number; well-run sites tend to sit in the low teens, and overlap hurts more than count. The better question for each plugin is whether it does something only code on the server can do. Caching, forms, SEO metadata: yes. Drafting, reviewing and publishing content: no. Those can happen entirely outside the site through the REST API, which makes an AI writing plugin surface area for a job that does not need to run on the server.

The rule: give the writer an Editor, not an Administrator

Whichever model you choose, one rule limits the damage, and it takes five minutes.

Create a dedicated WordPress user for publishing. Name it for the tool. Give it the Editor role (or Author, if it should only publish its own posts). Never Administrator.
Issue that user one Application Password, named for the tool, from the user’s profile page. Copy it once into the tool. WordPress will not show it again.
Give the tool that credential and nothing else. Not an admin login, not an admin’s Application Password.

Now the tool can create and edit posts and media, set categories and tags, upload a featured image, and schedule. It cannot change settings, install or update plugins, switch themes, or touch users, because the user it acts as cannot. If the credential leaks or the tool is retired, revoke that one password and the site is exactly as it was.

This is the WordPress security model working as designed, and it is only available to the external-service model. A plugin does not act as a user; it acts as the site. The brief-to-published workflow post shows what a full publish looks like over this credential, with every field and the schedule set from outside.

The bloat argument, separately

Security is the decisive argument. Bloat is the everyday one.

An AI writing plugin adds its admin pages, its database tables, its scheduled tasks, its front-end scripts if it includes a chat widget, and its update notifications to a site that a marketing team without a developer is already nervous about touching. Each update is a small risk of a conflict with the theme or the page builder. Each plugin is one more thing to keep current, and the plugin nobody updates is the plugin that gets exploited.

The external model adds nothing to the site. The content is drafted, reviewed and given its fields somewhere else, and arrives as a finished post through the API. The site’s plugin list is the same length it was, and the marketing team’s relationship with wp-admin stays what it should be at a company without a WordPress developer: occasional.

How to decide

A short test, in order.

Does the job need to run on the server? A chat widget on the site’s front end does. A form that captures leads does. Drafting, reviewing and publishing posts do not. If the job does not need the server, do not put it there.
Who maintains the plugin, and what is its disclosure history? If you cannot answer both in a minute, do not install it.
Does the external service publish through an Application Password on a scoped user? If it asks for an admin login, it is a plugin in disguise. If it supports a scoped credential, the give-the-writer-an-Editor rule applies and the blast radius is one revocable password.
Does it carry the fields? Title, slug, excerpt, featured image with alt text, categories, tags, meta fields, schedule. If the external service leaves you typing eleven fields in the sidebar, you have moved the drafting off the site and kept the 11-field tax.

Marqeable is the external model: nothing is installed on the site, the blog editor and review gate live in the workspace, and publishing goes through the WordPress REST API with an Application Password on the user you choose, creating or updating the post with its categories, tags, featured image, excerpt, SEO fields and schedule. The exposure is one credential you can revoke. The plugin list is unchanged.

Frequently asked questions

Are WordPress AI plugins safe?

The category has a track record: the most recommended AI plugin disclosed three significant vulnerabilities in 2025 and 2026, including a bearer-token exposure on more than a hundred thousand sites and an authentication bypass. Any plugin runs as PHP with the installer’s reach, and an AI plugin also holds API keys, so a flaw exposes the site and the keys together.

What is the difference between a plugin and an external service?

A plugin executes on your server inside wp-admin with administrator reach and stores keys in your database. An external service calls the REST API with an Application Password tied to a user role, cannot log into the admin, and is cut off by revoking one credential.

What is the give-the-writer-an-Editor rule?

A dedicated publishing user with the Editor or Author role, never Administrator, holding one named Application Password. The tool can create and edit posts and media and nothing else.

How many plugins is too many?

No fixed number; quality and overlap matter more than count. Ask whether each plugin does something only server code can do. Content drafting and publishing do not.

The bottom line

The question is not which AI plugin has the best features. It is whether AI writing should run inside your site at all. A plugin is PHP with administrator reach and your keys in the database, and the category’s disclosure history shows what that costs when it goes wrong. An external service publishing through a scoped, revocable Application Password can do the same job with the blast radius of one credential and nothing added to the site. Give the writer an Editor, not an Administrator, keep the AI keys off the server, and let the plugin list stay short.

Marqeable runs your campaigns, answers every visitor, text, and email in seconds, and turns them into booked jobs and meetings - even at 9pm on a Saturday. We’re in private beta with a small early cohort. Get early access