Publishing AI Articles to WordPress Without Your Password
No, you don't hand over your WordPress password
You can publish AI articles to WordPress without admin access, and that is how Kwerivo is built. The Kwerivo WordPress plugin, installed on your own site, pulls approved articles from Kwerivo using a key that Kwerivo issued. Kwerivo never holds your site credentials, and it never signs in to your site or writes to it. The only requests it makes to your server are the public-page crawl you asked for — the same thing a search engine does.
That is one of three constraints that sit in the same chain. No credentials held. Articles are created as drafts, and publishing requires an explicit action. Every draft arrives with a list of claims it could not support from your business profile.
The honest consequence first: this narrows what a breach of the vendor can reach. It does not make your WordPress site secure. Your hosting, your user accounts and your other plugins are still yours to look after.
Two ways to publish AI articles to WordPress: with admin access, or without it
There are two common shapes for this, and it is worth understanding them as categories rather than as products.
In the push model, you give the vendor a login — an administrator account, or an application password generated inside your WordPress profile. The vendor stores that credential. When they have something to post, their servers make a request to your site and write the post.
In the pull model, the software that talks to your site is software you installed on your site. It asks the vendor for approved articles. The vendor's servers never need to know your site exists as something they can call.
The difference is close to the difference between a contractor who keeps a key to your house on their keyring and one who comes to the door when you call them. Both can end up doing the same work in the same room. What differs is where the standing permission lives while nobody is working — and who can use it if it goes missing.
Both models can produce an identical finished post. The question is not which one writes better. It is which one leaves a usable credential sitting somewhere outside your control.
What an application password actually lets a vendor do
WordPress's own documentation describes application passwords as a way for external software to authenticate to the REST API without using the normal login form. The developer documentation on REST API authentication is the part worth reading closely: a request is authorised against the capabilities of the user account it authenticates as.
Read that plainly. An application password created on an administrator account is not limited to creating posts. It carries whatever that administrator can do through the endpoints the REST API exposes. The name suggests something narrow. The scope is the scope of the user it belongs to.
Published security guidance on third-party integrations lands in the same place from a different direction: grant the least privilege that lets the integration do its job, and no more. If you do hand over a credential, the account behind it matters more than the credential itself.
I am not going to speculate about scoping options that WordPress or any particular plugin may or may not offer. Check the documentation for the versions you are running, on the day you connect.
If the vendor is breached, what can an attacker reach?
This is the question the reader actually has, so here it is answered for each model.
In the push model, the stored credentials are the prize. An attacker inside the vendor gets a list of sites and a way to act on each of them, with whatever capabilities the connected user holds. There is a reason people ask this question at all: supply-chain compromise of third-party publishing and plugin vendors has been reported often enough to be an ordinary risk rather than an exotic one.
In Kwerivo's model, a breach yields drafts, topics and business profile content. It does not yield write access to your site, because Kwerivo holds no site credentials at all — there is no key on the keyring to steal. The plugin keys it does hold are stored hashed, not in readable form.
That is the whole claim, and it is deliberately narrow. Kwerivo holds no way in. Your site's own security is unaffected either way.
It is still worth thinking about what a vendor holds about you. Your business profile and drafts are your content, and under UK and EU data protection guidance a vendor processing personal data on your behalf carries processor obligations for it. Ask any vendor what they would tell you, and when, if they were breached.
What the issued key is, and what someone could do with a copy
The key identifies your workspace to Kwerivo so the plugin can fetch approved articles. It is a credential for reading from Kwerivo. It is not a credential for writing to your site. Those are different objects with different consequences.
There are things this article deliberately does not tell you, because they are not confirmed and I will not guess: where the key is generated and displayed, whether you can rotate or revoke it yourself without contacting support, and whether it is bound to a single workspace and a single site.
Ask those three questions of any vendor before you connect, including this one. Email support@kwerivo.com and get the answer in writing. A vendor who cannot answer plainly is telling you something.
Nothing goes live until someone clicks approve
Articles are created as drafts. Publishing requires an explicit action. Nothing publishes on its own.
Who decides an article is ready is a person, not a schedule. Kwerivo supports workspaces with members and roles, and keeps an audit log of which actions were taken and by whom. If two people share a workspace, you can see who approved what.
What the plugin does after approval — how quickly it fetches, and what the log records for that fetch — is not something I am going to describe here, because it has not been confirmed. The approval step itself is the part that is fixed.
Every draft arrives with the claims it could not support
Drafts include a score for structure and voice, and a list of claims Kwerivo could not support from your business profile. Kwerivo will not state a price, a guarantee or a specific figure unless it is confirmed in the profile.
The profile is not something Kwerivo assumes. It crawls your public pages, builds a business profile, and you correct and confirm it before anything else is built on top. Kwerivo respects robots.txt, does not sign in, does not submit forms, and does not touch non-public pages.
That still leaves work for a person. Somebody has to verify the flagged claims against what the business actually does today. Somebody has to read the draft against a real audience and decide whether the tone fits. And somebody has to decide whether the topic is worth publishing at all. See when AI invents facts about your business for why that last check matters.
A short checklist before you connect any tool to WordPress
Apply this to any vendor, including this one:
- Does it ask for an admin login or an application password? If so, which user's capabilities would that credential inherit?
- Which side initiates the connection — their servers reaching your site, or your site reaching them?
- Does anything publish without an explicit human action?
- How do you cut the connection, and how do you delete your data? On what timetable?
- Who owns the drafted articles?
- Is your content used to train models, or reused for other customers?
- Is prompt or input data retained, and in what form?
Six of the seven can be answered from a vendor's public pages. If they cannot, that is your answer.
Leaving: cutting the connection and deleting your data
Deactivating the plugin removes the software you installed on your own site. Nothing has to be revoked on Kwerivo's side for it to stop publishing, because publishing was always the plugin asking Kwerivo, never Kwerivo reaching in. If the key itself may have leaked, rotate it as well — deactivating the plugin does not invalidate a key someone else has a copy of.
A workspace or account can be deleted self-service in Settings. Deletion is scheduled with a 30-day window that you can cancel, after which the data is permanently destroyed.
Customers own their inputs and outputs — website content, business profile and drafted articles. Kwerivo claims no ownership of any of it.
Prompts are not stored. Only the template, its version, the parameters, an input hash and the cost are recorded. Customer content is not used to train the AI provider's models and is not used for other customers' articles. The privacy policy sets this out in full.
What this does and does not promise
The claim in this article is narrow on purpose. Kwerivo holds no credentials for your site and no route into it. That is a statement about one attack path, not about your site's overall security.
Kwerivo does not promise a particular level of uptime, and may change or withdraw features, with reasonable notice for material withdrawals. No payment details are collected. Billing is not connected and nothing is charged at present.
If you want to try it: request an invitation. When your workspace is set up, the plugin connects using the key Kwerivo issues — no site login is handed over at any point.
Questions go to support@kwerivo.com. The terms and the rest of the legal pages were last updated 2026-08-04.