MCP audit logging and privacy
The site records MCP and OAuth activity so administrators can investigate access and changes. Network-delegated execution is recorded in the main site's MCP log, with the destination blog ID, operation and tool in the request summary. Delegation does not require a separate OAuth or audit setup on each destination.
Recorded fields
An audit entry includes the UTC timestamp, acting WordPress user ID when available, authentication type, OAuth client ID when present, action name, status, redacted request and response summaries, and a one-way hash of the request IP.
The logger recursively replaces values whose keys look sensitive. Long strings are truncated after 600 bytes; nested or large collections are summarized, with each stored request or response summary limited to 16 KiB. This reduces exposure but is not a substitute for input minimization: a secret placed under an unexpected key or inside ordinary prose may not be recognized.
Successful pom_get_task status polls do not create audit entries. Failed polls retain error logging, and the original operation request retains its normal audit entry. Use the task receipt to inspect its execution result.
The configured log-retention period defaults to 30 days and cannot be set below one day. Cleanup removes entries older than that period along with expired or revoked OAuth records.
Integration guidance
- Use clear client IDs and separate service identities.
- Keep secrets and unnecessary personal data out of arguments.
- Do not rely on the audit log as a content backup.
- Restrict diagnostics access to authorized administrators.
- Share only redacted action, time, status, and stable error codes with support.
POM AI’s audit log covers the site-local MCP server and delegated network executions initiated through the main-site connection. The external AI client may keep its own history under a separate privacy policy.
Related guides: privacy, safe support information, and MCP authentication.