Spike: AI Protection for WordPress AI/chat plugins

[cport1]

Goal

Determine how to offer WebDecoy AI Protection to WordPress sites that embed AI chat or generation features, and produce an evidence-backed implementation plan plus one minimal proof of concept.

Starting recommendation: add an optional AI Protection module to the existing WebDecoy plugin, reusing its account/property connection and dashboard. Validate this before committing to a separate WordPress plugin.

Questions to answer

1. Which AI integration should we support first?

• Identify 2–3 maintained WordPress AI/chat plugins with credible adoption or paying-customer signals. Cite current sources and record tested versions.
• Inspect the actual server-side hooks, REST/AJAX routes, authentication, streaming and provider-call paths.
• Identify a supported interception point before inference starts. Verify that direct endpoint calls cannot bypass it.
• Determine whether the model call happens in WordPress or a third-party service. Document integrations where WordPress cannot enforce admission reliably.
• Recommend one first connector based on demand, hook stability, coverage and maintenance cost. Do not assume a generic browser script or REST middleware protects every AI plugin.

2. What belongs in PHP and what can we reuse?

• Review the existing WordPress plugin and WebDecoy/php-sensor for reusable detection, property binding, trusted-IP handling and HTTP transport.
• Define a PHP equivalent of the AI Protection contract: local rules using authenticated server context; cloud detection; explicit decisions/reasons/degraded status; enforcement; separate outcome reporting.
• Reuse the existing property-scoped API key and plan entitlements. Keep credentials server-side; do not introduce another account, subscription or meter.
• Do not trust browser-supplied user IDs, plans or forwarding headers. Account for existing trusted-IP work in Remove BotDetector’s untrusted forwarded-IP fallback #85.
• Keep prompts, model output and raw application context out of detection/report payloads. Use stable, non-sensitive rule IDs and reason codes.

3. How does this fit WordPress request handling?

• Preserve the AI plugin's authentication, nonces/origin checks, input validation and existing quotas.
• Start cloud protection in observation. Keep local rule modes explicit and independent.
• Cloud detector outages fail open by default. A failed detector/report must not become a blanket block on legitimate requests; existing application restrictions still apply.
• Preserve supported streaming and cancellation behavior. Document PHP/web-server limitations; do not promise that cancellation stops provider billing.
• Evaluate practical reporting options under PHP/WordPress request lifecycles: timeouts, scheduling, delivery loss and added latency. Do not assume Node-style waitUntil exists or that a shutdown hook is latency-free.
• Reports must remain property-scoped, bounded and deduplicated, with SDK-reported outcomes distinguished from server detector evidence.

4. Existing module or separate plugin?

Document installation/activation flow, dependency compatibility, update/support burden, discoverability and treatment of existing customers. Recommend one distribution approach. Default to an opt-in module unless evidence supports a separate plugin.

Proof of concept and validation

Using the recommended connector and a local/fake model provider:

• Valid requests reach the provider and retain the expected response/stream format.
• An enforced local denial prevents provider invocation.
• An enforced cloud denial prevents provider invocation; observation records the verdict and allows the request.
• Detector timeout/outage allows otherwise valid requests. Reporting failure does not change the decision or interrupt the response.
• Direct endpoint requests still encounter protection; invalid authentication continues to fail independently.
• Demonstrate trustworthy client-IP resolution and server-derived user/plan context.
• Inspect outgoing payloads for prompt/context/credential leakage and verify property attribution.
• Measure added latency for warm/cold checks and reporting on the tested PHP/WordPress stack. Label fixture results as transport validation, not detection accuracy or savings.

Deliverables / completion criteria

• Candidate integration comparison with sources, versions and concrete hook locations.
• Existing-plugin versus separate-plugin recommendation and customer setup flow.
• PHP reuse/gap assessment and proposed API/data flow.
• One minimal working connector proof of concept with reproducible validation results.
• Explicit coverage gaps, unsupported configurations and rollout/dependency risks.
• Follow-up implementation issues with scope and estimates, or a documented no-go if no reliable pre-inference hook exists.

Related work and boundaries

The AI Protection prototype uses local customer rules plus remote WebDecoy detection. The application repository contains the account/config, detection and central reporting work under feat/ai-abuse-protection-core; the standalone @webdecoy/ai-protection SDK is still local/unpublished. Confirm backend availability before any live-account test.

Relevant application code: ingest/internal/handlers/ai_abuse_config_handler.go, ingest/internal/handlers/ai_protection_report_handler.go, and integrations/ai-abuse/AI_PROTECTION_REPORTING.md.

This is a feasibility/integration spike, not authorization to publish a WordPress release, choose an SDK license, or promise protection for all WordPress AI plugins. Prompt-injection filtering, agent identity verification and hard model-spend caps are outside this spike.