Permissions and access control
Who can do what in Aimogen Pro, the capability model, and how to restrict access for editors, authors and visitors.
The capability#
One custom capability, access_aiomatic_menu, gates every plugin admin screen and the seventeen plugin
post types.
It is granted to administrator plus any roles listed under
System & Logs › AI Usage Limits › Additional Roles, and removed from every other role on each
admin request.
What that capability actually permits#
Two screens require more: AI Snippets requires manage_options, because snippets execute PHP, as does
the Abilities API ability.
Layers of restriction#
From weakest to strongest:
| Layer | Enforced | Use for |
|---|---|---|
| Workspace | No | Reducing clutter |
| Menu restrictions | Yes, server-side | Keeping a role out of specific screens |
| Removing the capability | Absolutely | Roles that should have no access |
What to restrict first#
AI Playground. Unrestricted API spend.
AI Agents. Unrestricted action, subject to the tools enabled.
Settings. Contains every credential in readable fields.
AI Snippets. PHP execution, already gated on manage_options.
AI MCP Integration. Exposes the site to external clients.
Front-end users#
Visitors do not need the capability. Front-end features are governed instead by:
| Control | Purpose |
|---|---|
| Usage limits | Guest and user credit allowances |
| Rate limiting | Requests per time window on the chatbot |
Restrict User IDs List / Restrict User IPs List | Blocking specific users or addresses |
required_user_capability | On [aimogen_user_remote_chatbot] |
The aiomatic_ai_allowed filter | Arbitrary logic |
Max Guest Credits set to zero makes any front-end feature effectively login-only.
AJAX endpoints#
The plugin registers a large number of AJAX actions, around 50 of which are also registered for logged-out
visitors (wp_ajax_nopriv_*). Those are the front-end features: chat submission, form submission, image
generation, file uploads, voice, moderation.
They are intended to be public — that is how a chatbot works. Their protection is usage limits and rate limiting, not authentication.
Delegated permissions#
Some features act on behalf of an AI rather than a user:
Chatbot extensions run with the permissions of the tool, not of the visitor who triggered them. A visitor who cannot edit posts can still cause a post to be edited if the tool is enabled.
Agents run with their configured tool set, regardless of who started them.
Snippets run as PHP on the front end.
This is the most commonly misunderstood part of the security model. Enabling a tool grants that capability to whoever can reach the AI, not to whoever has the WordPress capability.
A recommended model#
| Role | Configuration |
|---|---|
| Administrator | Full access |
| Editor | access_aiomatic_menu, with menu restrictions hiding Settings, Agents, Playground, Snippets and MCP |
| Author | No plugin access. Front-end tools with a credit allowance if required |
| Subscriber | Front-end tools only, with user credits |
| Visitor | Front-end tools only, with guest credits and rate limiting |
Related#
Still stuck? Open a support ticket and include the diagnostics from Aimogen Pro › System & Logs › System Info.