PAGUP Agent ControlWordPress access for AI assistants
Start free trial

Which WordPress Plugin Added the WAP AI Assistant Notice?

Do not identify the source from the visible label alone. Search the installed plugin files, browser asset URLs, admin-page slug and recent changelogs. The WAP library can be embedded by more than one product, and the Application Password label may reflect the page title that first provisioned the credential.

The current Rank Math changelog is one confirmed example of a plugin that added an in-plugin Support Agent, but the same visible wording on another site is not sufficient proof that Rank Math is the source.

Likely causes

  • The notice comes from a plugin integration rather than from WordPress core itself.
  • Several similarly named credentials make ownership and active use ambiguous.
  • The documentation or support answer describes a different plugin, client or version.
  • A recent plugin update introduced, changed or corrected the assistant behavior.
  • The visible credential name is a label and may not uniquely identify the page or workflow that created it.

Diagnostic sequence

  1. Capture the exact sanitized message, HTTP status and response body without including secrets.
  2. Identify the plugin and admin page that renders the notice or assistant.
  3. Record WordPress, plugin, client, connector and server versions before changing anything.
  4. Compare the installed version with the plugin’s official changelog and corrected releases.
  5. Review the Application Passwords section of the relevant user profile without exposing any secret.
  6. After a controlled deactivation, verify whether the notice, credential or automatic provisioning behavior persists.

Apply the smallest correction

  1. Replace stale instructions with documentation tied to the installed client, plugin and version.
  2. Document who creates, rotates, reuses and revokes the credential, including the trigger for each change.
  3. Revoke credentials that are confirmed unused or no longer required.
  4. Update to the plugin release that documents or corrects the observed behavior.
  5. Escalate with sanitized, versioned evidence when the behavior remains specific to the plugin.

Verify the result

  • Every observed credential has an owner, purpose, creator, status and revocation decision.
  • The authenticated request resolves to the intended dedicated WordPress user.
  • The final record contains versions, evidence, change, verification and rollback information without secrets.
  • The notice disappears only under the corrected condition and does not return on unrelated admin pages.

What not to do

  • Do not describe the notice or credential as malware, a backdoor or a compromise without evidence.
  • Do not publish claims about remote data use, consent or permissions that have not been verified against the exact version.
  • Do not delete every unfamiliar credential before recording its owner, purpose and last use.
  • Do not place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.
  • Do not edit WordPress core or third-party plugin files as the first troubleshooting step.

Sources and verification

This page was checked against the following primary sources. Last source review: .