Provider-key isolation
Upstream AI credentials stay on the Barnd API server. WordPress receives an authorized response, not a provider secret.
Security
Helpful AI should not mean handing over control.
Barnd separates your WordPress site, your entitlement, and the AI provider boundary. The result is a workflow that can fail closed and explain what happened.
Site-aware identity
Signed Pro requests bind to the installation, site, request body, timestamp, and nonce. A copied request should not become another site’s access.
Bounded mutations
Supported adapters target one exact metadata field, attachment, visible FAQ, or validated internal-link source. There is no generic arbitrary-content writer.
Capability + nonce
Apply and rollback require the appropriate WordPress capability and a valid nonce, then re-resolve the authoritative server state.
Freshness checks
If a page or media value changed after an AI draft was created, Apply stops and asks for a fresh review.
Specific rollback
Each applied draft retains bounded prior state and an audit event so one change can be restored without reverting the whole site.
What we protect
One customer should never become another customer.
Entitlements, site binding, request signatures, replay protection, and usage limits are checked at the service boundary. Provider failure returns a safe error rather than an unverified result.
WordPress
→ signed request
Barnd API
→ identity + entitlement + nonce
AI provider
→ normalized suggestion
WordPress review queue
What not to send support
Support will never need your WordPress password, database password, payment-card details, private Ed25519 key, provider credential, or raw activation key. Send the site URL, plugin versions, and a non-secret diagnostic code instead.