Permissions are the heart of this plugin. Everything an AI client can do on your site is decided here, on Sokket → Settings → Access.
The three gates
Every single tool call has to pass all three of these. They are independent, and none of them can be skipped:
- The connection’s tool allowlist. Is this specific tool ticked for this token? A token that wasn’t granted
update_postcannot call it, full stop. - The read-only ceiling. If the connection is marked read-only, every write tool is blocked — even one that is ticked in the allowlist.
- A real WordPress capability check. The request runs as the bound user, and
current_user_can()is called against the tool’s mapped capability. A token bound to an Editor cannot list plugins, because that user cannot activate plugins.
The token is never trusted on its own. Gate 3 is what makes the whole model safe: the worst a leaked token can do is what its user could already do in wp-admin, minus everything you didn’t tick.
Tools whose real permission is per-object — posts, terms, comments — check again inside the tool.
update_postre-checkscurrent_user_can( 'edit_post', $id )for that specific post, so a Contributor can’t edit someone else’s article just becauseedit_postspassed the outer gate.
Creating a token
On Settings → Access, fill in the create form:
- Label — where this token will live: "Claude Code on my laptop", "Cursor at the office". You’ll thank yourself at revocation time.
- Run as user — the WordPress user the connection acts as. This is the single most important security decision on the page: it sets the ceiling for everything else. Bind a content-editing connection to an Editor, not an Administrator.
- Scope — the Read-only checkbox. Tick it to block every write tool on this connection regardless of the allowlist.
- Allowed tools — the checkbox list, grouped into Site & diagnostics, Content, Media, Taxonomies & terms, Comments, and Other (where any tools added by other plugins appear). Write tools carry a write badge.
Click Create token.
The token is shown exactly once
The plaintext token appears once, at the top of the screen, with a Copy token button. Sokket stores only its SHA-256 hash — there is no "show token again" because the plugin genuinely does not have it. Lose it and the fix is to revoke that token and create a new one.
The token list afterwards shows only a short prefix, enough to tell your tokens apart.
Choosing a starting set
A few sets that work well in practice:
Audit and debug (read-only, bound to an Administrator)get_site_info, list_plugins, list_themes, get_php_error_log_tail, get_site_settings, list_posts, get_post, search_content
Content assistant (bound to an Editor)list_posts, get_post, search_content, create_post, update_post, list_taxonomies, list_terms, assign_terms, plus list_media and set_featured_image if it should handle images
Comment moderation (bound to an Editor)list_comments, moderate_comment, reply_to_comment
Note that list_comments returns commenter email addresses and get_site_settings includes the site’s admin email — the same data that user sees in wp-admin. Leave them off if you’d rather not share them.
Editing, revoking, and deleting
Each row in the token list has three actions:
- Edit — change the read-only flag and the tool allowlist. Takes effect on the very next request; there is no cache to clear. You cannot change which user a token is bound to — create a new token instead.
- Revoke — deactivate the token while keeping the row, so you can still see it in the list and in the audit trail. The credential stops working immediately.
- Delete — remove the row entirely.
Revocation is instant and unconditional. If a laptop goes missing, revoke and you’re done.
Scope, users, and roles
The bound user’s role is the real limit. Some useful pairings:
| Role | What tools can reach |
|---|---|
| Administrator | Everything, including get_site_info, list_plugins, list_themes, get_php_error_log_tail, and get_site_settings (all require manage_options, activate_plugins, or switch_themes) |
| Editor | All content, media, taxonomy, and comment tools — but no site diagnostics |
| Author | Their own posts and uploads; no comment moderation, no term creation |
| Contributor | Draft-level content only; create_post works, publishing does not |
If you need site diagnostics and want to limit blast radius, the right move is an Administrator-bound token that is read-only with only the diagnostic tools ticked.
New tools and existing tokens
When a Sokket update adds tools, existing bearer tokens keep exactly the tools they were granted. New tools are simply unticked on those tokens until you enable them. That’s deliberate: an update should never widen a permission you already decided on.
OAuth connections behave differently — they aren’t per-tool, so they pick up new tools automatically within their read-only or full-access scope. See OAuth 2.1 Connections.
Application Passwords
WordPress Application Passwords work as an alternative credential with no setup in Sokket at all — the client sends them as HTTP Basic auth and WordPress authenticates the user before the request reaches the MCP endpoint.
The trade-off is that an Application Password is all-or-nothing: it authenticates with that user’s full capabilities and every tool enabled, because there is no Sokket-side allowlist attached to it. There is no read-only ceiling either.
Use them for quick local testing, or when you deliberately want a connection with the same reach as the user. For anything ongoing, a bearer token gives you far more control.
Rate limiting
Every credential — bearer token, OAuth connection, or Application Password — is limited to 120 requests per minute, tracked in a transient. Past that, requests get a 429. Developers can change the ceiling with the sokket_rate_limit_per_minute filter; see the Developer Reference.