WPALLOY SECURITY
Security is part of the architecture.
WPAlloy is designed around explicit identity, least privilege, isolated site authority, revocation and auditable structured operations—not broad remote control.
Per-installation identity
Each connected WordPress installation has its own identity and credential boundary.
Least privilege
Clients receive only explicitly approved scopes and capabilities.
Site isolation
Authorization for one site does not become authority over another site.
Revocation
AI grants and site connections can be revoked independently.
Structured actions
Approved operations use defined semantic actions rather than arbitrary PHP, SQL, shell or filesystem execution.
Auditability
Important authorization and execution events retain useful provenance without exposing reusable secrets.
Your AI account is not your WordPress password.
Customers use their own supported AI account or workspace through separate, scoped grants. WordPress administrator credentials are not intended to be shared with the AI client.
Control path: client → WPAlloy authorization and policy → WPAlloy Connect → validated WordPress action → audit result.
Normal site operation should not depend on AI or cloud availability.
WPAlloy’s local-resilience doctrine keeps ordinary WordPress rendering and local product functionality outside the critical path of Gateway or AI-provider availability wherever the product can reasonably operate locally.
Security claims should be verifiable.
WPAlloy will publish product-specific permissions, supported controls and release status as products mature. We do not claim certifications or guarantees that have not been established.