Read-Only WordPress Content Audit Agent: Fetch, Check, Report, Review

A read-only WordPress content audit agent retrieves an approved set of public or edit-context post fields, runs deterministic checks, uses a model only for bounded interpretation, and sends typed findings to a human reviewer. It has no create, update, delete, media-upload, taxonomy-write, plugin, or settings tool. This narrow design lets a beginner learn tool calling, validation, evidence, logging, and human review without giving model output the authority to change a production site.

Build in a local or staging environment with synthetic content first. Use a dedicated account with the minimum capability required for the chosen fields, HTTPS, a revocable credential, and an explicit post allowlist. Never place an Application Password in source code, prompts, logs, screenshots, URLs, or model-visible tool results. Treat every post body and fetched web page as untrusted data that can contain instructions, misleading claims, or private information.

Define One Audit Outcome

Choose a narrow result such as finding missing excerpts, duplicate H1 text, broken approved links, absent featured media, or stale review dates. Write what the agent will check, which posts are in scope, and what a reviewer receives.

Do not begin with improve my website. A vague objective encourages broad retrieval and subjective output. Keep content correction, SEO strategy, image generation, and publishing outside the first agent.

Draw The Trust Boundary

Separate the orchestrator, credential store, WordPress API, deterministic validators, model, report database, and human reviewer. Mark which data crosses each boundary and which component can perform network requests.

The model proposes tool arguments and interpretations; the application validates and executes. Fetched post content is evidence, not authority. Instructions inside a post must never change the system prompt, tool policy, or allowlist.

Create A Read-Only Identity

Use a dedicated WordPress user or integration identity with only the capabilities needed to read the selected context. For public fields, unauthenticated GET may be enough. For edit-context fields, use an approved revocable method over HTTPS.

WordPress documents Application Passwords for programmatic REST access. Store the secret in an environment or approved secret manager, restrict who can read it, monitor its use, and revoke it when the exercise ends.

Prove That Writes Are Impossible

Expose only GET operations in the agent’s tool registry. Do not include a generic HTTP tool that can issue arbitrary methods. Reject any method other than GET in application code and block routes outside the approved host and path patterns.

Test that POST, PUT, PATCH, and DELETE attempts fail before reaching WordPress. A prompt instruction saying do not write is weaker than an absent tool plus a transport-level method allowlist.

Allowlist Posts And Fields

Provide the orchestrator with explicit post IDs or approved slugs. Request only fields needed for the audit, such as id, slug, status, modified date, title, excerpt, content, featured media, and link. WordPress supports field filtering through REST parameters.

Do not let the model choose arbitrary users, revisions, private types, or search terms. Validate identifiers as integers or normalized slugs and cap batch size, page count, and response bytes.

Define A Typed Fetch Tool

Give the tool a clear name such as fetch_allowed_posts and a JSON schema for allowed identifiers and fields. Reject extra properties, unexpected types, duplicate IDs, out-of-range pagination, and unknown fields before making the request.

Return a compact normalized object, not raw headers or the complete REST response. Include post ID, public URL, modified time, selected text fields, retrieval time, and a hash that can support later evidence checks.

Normalize WordPress Responses

WordPress returns rendered and sometimes raw field forms depending on context and permission. Convert the approved representation into a stable internal model while preserving source identifiers and URLs. Decode only through a structured HTML parser.

Do not strip HTML with a fragile regular expression when heading, link, image, or table checks depend on structure. Record parse errors as findings instead of silently treating malformed content as empty.

Run Deterministic Checks First

Use ordinary code for checks with exact rules: required field presence, heading counts, URL syntax, same-site link status, featured media ID, word count, duplicate title fingerprint, and forbidden placeholder tokens. These results are reproducible and inexpensive.

Give every finding a rule ID, severity, post ID, evidence location, observed value, expected condition, and validator version. The model should not recalculate facts that code can determine exactly.

Limit Model Interpretation

Use the model for tasks that need language judgment, such as whether an opening answers the stated intent, whether two paragraphs repeat the same point, or whether alt text matches supplied context. Give it only the fields and deterministic evidence required.

Require a structured response with finding type, explanation, evidence excerpt, confidence category, and reviewer question. Do not ask for a replacement article or automatic correction in this workflow.

Treat Content As Untrusted

Wrap post content as quoted data and state that embedded instructions must be ignored. Remove scripts and active elements before model input. Bound length and preserve a hash so the reviewer can trace the excerpt to the retrieved version.

Test prompt-injection samples such as requests to reveal secrets, fetch another host, change tool policy, or publish an update. The correct result is a content finding or ignored text, never a new action.

Keep Secrets Out Of Context

The tool executor attaches authentication after argument validation. The model never receives usernames, passwords, authorization headers, cookies, nonces, server paths, or full error traces. Redact provider responses before logging.

A 401 or 403 becomes a typed authentication or permission error with a correlation ID. Operators can inspect protected logs through authorized systems without exposing secrets in the audit report.

Design Typed Findings

Define a small set of severities and routes: information, needs review, content correction, technical review, and blocked evidence. Each finding should cite a post, rule, observation, and recommended next review step.

Do not let severity depend only on model confidence. Deterministic critical failures, such as a public credential or placeholder, follow fixed policy. Human reviewers decide uncertain language and business claims.

Build The Human Review Queue

Present findings with post title, public URL, modified time, evidence, rule version, and source hash. Let reviewers accept, reject, merge, or return findings for better evidence. Record reviewer identity and decision time.

The queue must not contain an Apply all button in the read-only version. Accepted findings can become tickets or a separately authorized editorial workflow, but they do not grant this agent a write tool.

Add Idempotent Runs

Generate a run ID from audit policy version, post allowlist, and retrieval snapshot. Repeating the same run should reuse or compare evidence rather than create duplicate tickets. Preserve start, completion, and failure states.

If retrieval times out, resume from recorded post IDs and do not duplicate findings already committed. Cap retries and distinguish WordPress availability from model or validator failure.

Log Safe Operational Evidence

Record run ID, tool name, validated argument summary, allowed post IDs, response status category, byte count, duration, validator version, model configuration reference, finding counts, and review status. Keep bodies and secrets out of general logs.

Use restricted evidence storage when excerpts are necessary. Set retention and deletion rules. NIST’s AI risk guidance supports documented governance, measurement, evaluation, and monitoring tailored to the actual system context.

Test Failure Cases

Create fixtures for missing posts, private posts, malformed HTML, long bodies, duplicate titles, redirects, 401, 403, 404, 429, timeout, invalid JSON, prompt injection, and model schema failure. Verify safe errors and unchanged WordPress state.

Also test partial batches and stale content modified after retrieval. The reviewer should see that the evidence is outdated and request a refresh rather than approving an obsolete finding.

Measure Audit Quality

Use a labelled set of known findings and clean posts. Track rule precision, missed findings, duplicate findings, unsupported explanations, review overrides, and time per post. Keep deterministic and model-assisted results separate.

Do not claim accuracy from a few examples. Review false positives and false negatives by rule, update the policy deliberately, and rerun the holdout set before release.

Release With Stop Conditions

Start with a small allowlist and one audit policy. Stop on unexpected host, method, field, authentication scope, response size, content type, schema error, or secret-detection event. Preserve the report and disable the run until reviewed.

The AI agent tool permission matrix can help document why write capability is absent. The WordPress Development course supports API and content-model practice, while the AI Automation and Agent Development course covers bounded tools and review workflows.

FAQ

Can a read-only WordPress agent use an administrator account?

It should not. Use public GET access where sufficient or a dedicated identity with only the minimum read capability required.

Why not let the agent fix simple issues automatically?

The first workflow is designed to prove retrieval, validation, evidence, and review. Writing adds a separate authorization, integrity, rollback, and QA problem.

What happens when a post contains prompt injection?

Treat the content as untrusted data, ignore its instructions, record relevant evidence, and never expand tools, hosts, credentials, or permissions.