Security and privacy

Readiness diagnostics contain configuration states and bounded test timestamps only. They never copy provider keys, webhook secrets, recipient addresses, ticket text, AI prompts, or AI responses. Incomplete inbound email, compatible-AI, and outbound notification configurations are rejected at save time so an administrator cannot accidentally expose a nonfunctional enabled state.

Private requests are visible only to their author and authorized staff. REST mutations require an authenticated WordPress session and REST nonce. Public questions never expose order, entitlement, license, or email data.

Documentation feedback is accepted only from the ticket owner and only when that ticket contains a server-created automated documentation message. The server ignores client-supplied comment identifiers, locates the trusted message itself, restricts outcomes to solved or still-needs-help, and applies the corresponding workflow state idempotently.

Assignment, priority, category, SLA, first-response timing, and AI analysis are staff-only operational data. Customers and signed-out visitors receive none of these fields. Staff changes validate supported values and assignee capabilities on the server; the SPA is only a presentation layer.

Messages accept the WordPress safe-post HTML subset. Product and reference fields are normalized before storage. ShopiChain context is reduced to non-secret public order, subscription, or entitlement identity plus product, state, term, and expiry fields. Addresses, email, amounts, provider payment references, license keys, and credentials are excluded. Purchase selections use a server-signed opaque token. Ticket creation discards client-supplied commerce references, re-resolves the selection for the authenticated user, verifies current eligibility, and then persists the authoritative safe context. Public questions clear all commerce linkage.

Support creation and ticket replies enforce server-side character ceilings and per-account hourly limits in addition to authentication and ownership checks. These controls apply equally to standalone, SnapWeb, and FluentCommunity clients because the SPA cannot bypass the REST enforcement layer.

Notification delivery and inbound email are disabled by default. Emails intentionally omit ticket bodies and commerce secrets. Delivery audit rows store only audience role, event type, outcome, and time; they do not store recipient addresses or message content. Ticket-specific Reply-To routing activates only when an inbound address and a signing secret of at least 32 characters are configured.

AI assistance is opt-in and staff-only. When enabled, Support sends a bounded, minimized context to the configured OpenAI-compatible endpoint. It redacts email addresses, common credential assignments, and token-like keys, limits reply history, uses a safe outbound HTTP request, and rate-limits each staff account. Provider keys can be supplied through SNAPWEB_SUPPORT_AI_API_KEY; keys and raw provider responses are never returned through Support REST or MCP. Returned drafts and analysis are sanitized and never sent or applied automatically. Each successful operation stores only a bounded audit entry containing event, provider identifier, staff user ID, and time—never the prompt, response, or key. The versioned filters remain available for stricter redaction or alternate providers.

MCP ticket bodies and replies are disabled by default, while metadata reads remain capability checked. MCP status and triage changes are write tools: the SnapWeb MCP gateway must have writes enabled and the caller must provide explicit confirmation. Support also rejects either mutation itself unless confirm: true is present, providing defense in depth if another compatible gateway invokes the callback.

MCP AI drafting and analysis reuse Support's own provider boundary and staff permission checks. The context is minimized and redacted before leaving WordPress, and results are returned with humanApprovalRequired: true. Drafts are never sent and analysis suggestions are never applied by these tools.

Inbound email fails closed. The default webhook requires an HMAC-SHA256 signature, a timestamp within five minutes, a valid ticket-specific recipient token, a provider-verified sender, and an exact match between the sender and ticket owner's WordPress email. Provider event identifiers are stored only as SHA-256 hashes and make retries idempotent. A short-lived atomic per-ticket processing lock also serializes simultaneous deliveries. A 65,536-byte webhook ceiling, per-ticket rate limiting, a UTF-8-safe 20,000-character reply ceiling, quoted-history trimming, bounded event history, and database-failure handling prevent unbounded or duplicate ticket mutation. Rotating the signing secret invalidates old Reply-To tokens. Raw MIME, provider credentials, webhook signatures, and attachments are not stored; payloads declaring attachments are rejected.