How to Audit Every AI Credential on a WordPress Site
Inventory every credential used by an AI assistant, plugin, connector or client, then make an explicit retain, rotate, revoke or investigate decision for each record. This is an ownership and lifecycle audit, not a connection troubleshooting sequence.
Inventory schema
| Field | Evidence to collect |
|---|---|
| Integration | Plugin, assistant, client, MCP server or backend name and version |
| WordPress identity | Username, role and relevant capabilities |
| Credential | Type, visible label, creation date, last-used time and last IP when WordPress exposes them |
| Purpose | Approved task, environment and responsible owner |
| Exposure | Route, method, ability or tool the integration can request |
| Lifecycle | Creator, rotation rule, revocation trigger and recreation behavior |
| Decision | Retain, rotate, revoke or investigate, with approver and date |
Never copy the secret value into the inventory.
Collection procedure
- List every plausible WordPress user instead of inspecting only the current administrator.
- Record Application Password metadata from each relevant profile and correlate labels, dates and last-use evidence with known integrations.
- Inventory plugin-specific tokens, connector configuration and MCP credentials from their authorized control planes without exporting secret values.
- Map each assistant or client to one WordPress identity and one approved purpose. Record shared or ambiguous ownership as a finding.
- Compare installed versions and behavior with primary documentation and changelogs.
- Test revocation only after the owner, purpose and rollback consequence are recorded.
Disposition matrix
| Finding | Decision |
|---|---|
| Current owner, approved purpose, narrow capability and recent expected use | Retain until the next review date |
| Approved integration but weak name, shared ownership or overdue rotation | Rotate into one named credential and retire the predecessor |
| Departed owner, retired integration, duplicate or confirmed unused credential | Revoke and verify that authentication fails |
| Unknown owner, unexplained recreation or contradictory evidence | Investigate before revocation; isolate the workflow if risk requires it |
Evidence and sign-off
The final register must account for every observed credential, document unresolved gaps, identify the decision owner and schedule the next review. Evidence may include sanitized profile metadata, versioned configuration references, refusal results and revocation results. It must not include Application Passwords, Authorization headers, tokens, cookies, customer domains or personal data.
Frequently asked question
When should the audit be repeated?
Repeat it after plugin or client changes, staff changes, environment cloning, incident response and at the review interval assigned to each retained credential.
Related guides
- How to Identify Which WordPress User an AI Assistant Uses
- How to Find WAP Application Passwords in WordPress
- How to Revoke an AI Assistant’s Access to WordPress
- Checklist Before Enabling an AI Assistant Inside a WordPress Plugin
- WordPress AI Access Watch: Plugin Assistants, Credentials and Permission Changes
Sources and verification
This page was checked against the following primary sources. Last source review: .
- Application Passwords · WordPress Developer Resources
- Application Passwords REST API Reference · WordPress Developer Resources
- Roles and Capabilities · WordPress Developer Resources
- WAP Client for WordPress Plugins · group.one / One.com