Key Security Features
- Fail-Closed Architecture — Default deny and explicit allow only
- 7-Gate Permission System — Multiple independent security checks
- Full OAuth 2.0 Compliance — PKCE, refresh tokens, and revocation
- AES-256-CBC Token Encryption — Industry-standard cryptography
- Scope-Based Access Control — Granular permission model
- OAuth Isolation — Prevents tokens from accessing WordPress core API
- Comprehensive Audit Logging — Full transparency
- Rate Limiting — Prevents abuse
OAuth 2.0 Security Architecture
Authentication Flow
The plugin implements an OAuth 2.0 flow initiated in Claude Desktop. When a user authorizes access:
- The browser redirects to WordPress’s authorize endpoint.
- The user approves scopes in the WordPress admin interface.
- WordPress issues a 10-minute authorization code.
- Claude Desktop exchanges the code for access (1 hr) and refresh (30 days) tokens using PKCE verification.
- Tokens are encrypted with AES-256-CBC before storage.
Security strengths include:
- Mandatory PKCE (prevents code interception)
- Short-lived access tokens
- Single-use authorization codes
- CSRF protection via state parameter
- Redirect URI validation
Scope System
Six distinct scopes define access levels:
| Scope | Risk Level | Access |
|---|---|---|
read | Low | File system (read_file, list_files, search_files) |
database | Low–Medium | SELECT-only queries |
memory | Low | Isolated storage |
abilities | Medium–High | WordPress abilities |
admin | Critical | Wildcard full access |
claudeai | Critical | Full MCP access |
Scopes are validated at authorization, token creation, execution, and MCP server level—a true defense-in-depth model.
Token Encryption
Algorithm: AES-256-CBC
Key Derivation: PBKDF2-SHA256 (10,000 iterations)
Key Material: WordPress salts (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY)
Format: v1:base64(IV + ciphertext)
Uses a unique IV per encryption, timing-safe comparisons, and versioning for future upgrades.
Critical Security Feature: OAuth Token Isolation
Unlike standard WordPress authentication, OAuth tokens never call wp_set_current_user().
They only access plugin-specific endpoints—never core WordPress APIs.
Result:
- No access to admin panels
- No privilege escalation or lateral movement
Ability Permissions System
7-Gate Security Model
Each ability execution must pass through seven independent gates:
- Abilities API enabled?
- Ability registered in WordPress?
- Listed in permission registry?
- Admin enabled?
- Rate limits satisfied?
- User capability valid?
- (Critical only) Admin approval present?
Default = DENY.
Every denial is logged with detailed reasons.
Permission Database Schema
Dedicated database table includes:
- Ability name (unique, indexed)
- Enabled status & risk level
- Rate limits (per day/hour)
- Approval requirements (user/admin)
- WordPress capability required
- Custom validator function
- Audit trail (execution count, timestamp)
Rate Limiting
Per-ability limits (daily + hourly) enforced via database queries.
Strengths:
- Fine-grained control
- Accurate counters
Input Validation
Each permission can define a custom validator function, enforcing a fail-fast approach.
Validation occurs before execution and is fully logged.
Risk Level System
| Level | Description | Approval |
|---|---|---|
| Low | Read-only (no side effects) | User approval |
| Medium | Reversible writes (e.g., send-email) | User approval |
| High | Significant writes (e.g., update-settings) | User + higher limits |
| Critical | Destructive actions (e.g., delete-user, SQL) | Real-time admin approval |
Security Audit Logs
Logging Architecture
Logs record:
- Permission checks (allowed/denied)
- Ability executions
- OAuth authorization events
- Token generation, refresh, revocation
- Rate limit violations
- MCP tool executions
Every event includes user, IP, timestamp, and reason. Logs are accessible via the WordPress admin.
Threat Model Analysis
1. Stolen OAuth Token
- Risk: Low
- Mitigation: Short expiration (1 hr), scoped tokens, no core API access, rate limits, full logging
2. Malicious Ability Registration
- Risk: Medium
- Mitigation: Admin-only registration, approval with reasoning, full logging
3. Rate Limit Bypass
- Risk: Low
- Mitigation: Database-enforced rate limits, per-ability counters
4. Scope Escalation
- Risk: Very Low
- Mitigation: Cryptographically embedded scopes, validation on every tool call
Conclusion
The AI System Admin Plugin showcases security architecture built with defense-in-depth principles.
Highlights:
- Fail-Closed Permission Model
- OAuth Token Isolation
- Comprehensive Logging
- Granular Scopes and Validation
The standout achievement is OAuth token isolation, which prevents WordPress core access and drastically reduces potential attack surface.