Authentication & Permissions

Authentication and permissions in Aimogen are the security layer that governs who can trigger AI, from where, and under what conditions. This applies equally to the WordPress admin UI, frontend features, automation, and the Aimogen REST API. Nothing bypasses this layer, and nothing executes without passing through it.

Aimogen treats AI execution as a privileged action, not a generic request.

---

Authentication: Proving Identity #

Authentication answers a single question: who is making this request?

Depending on context, authentication can be:

• a logged-in WordPress user
• a guest user (frontend)
• an authenticated REST API consumer
• an automated system or MCP client
• a scheduled or background task

Every AI execution is associated with an identity, even when the user is anonymous.

---

WordPress User Authentication #

For logged-in users, Aimogen relies on native WordPress authentication.

This means:

• no separate user system
• no duplicated credentials
• full compatibility with WordPress roles and capabilities
• seamless integration with membership and role plugins

If WordPress knows who the user is, Aimogen does too.

---

Guest Authentication (Frontend AI) #

Guests are treated as a separate execution class, not as users.

Guest authentication is typically based on:

• session identifiers
• rate limiting
• contextual rules
• chatbot-specific logic

Guests are always subject to the strictest limits and permissions.

---

REST API Authentication #

All Aimogen REST API requests require authentication.

Key principles:

• unauthenticated requests are rejected
• authentication is mandatory
• identity is explicit
• permissions are evaluated per request

The REST API never runs in anonymous mode.

---

Permissions: Deciding What Is Allowed #

Authentication identifies the caller.
Permissions decide what that caller is allowed to do.

Permissions control:

• which AI features can be used
• which providers and models are allowed
• whether bulk or automation is permitted
• whether Playground access is allowed
• whether content editing is allowed
• whether workflows can be triggered

Permissions are enforced before execution.

---

Role-Based Permissions #

Aimogen permissions are aligned with WordPress roles.

Typical patterns:

• administrators: full access
• editors: content-related AI access
• authors: limited generation access
• subscribers: restricted or chatbot-only access
• custom roles: tailored permissions

This keeps permission management simple and familiar.

---

Feature-Level Permission Control #

Permissions are not all-or-nothing.

You can control access per feature, such as:

• single post generation
• bulk generators
• AI Content Editing
• image generation
• chatbots
• OmniBlocks
• Playground access
• REST API execution

A user can be allowed to use one feature and blocked from another.

---

Permissions and the REST API #

REST API permissions mirror UI permissions.

This means:

• an API call cannot do more than a user could do in the UI
• role restrictions apply equally
• usage limits apply equally
• provider and model restrictions apply equally

The API is not a privilege escalation mechanism.

---

Permissions and Automation #

Scheduled jobs, OmniBlocks workflows, and background tasks run under a defined execution context.

This ensures:

• permissions are still evaluated
• limits are still enforced
• providers are still restricted
• execution is auditable

Automation never runs “as root”.

---

Permissions vs Usage Limits #

Permissions decide whether something is allowed at all.
Usage limits decide how often it can happen.

Both are required for execution.

A user can:

• have permission but hit a limit
• have available limits but lack permission

In both cases, execution is blocked cleanly.

---

What Happens When Permission Is Denied #

When a permission check fails:

• execution stops immediately
• no AI call is made
• no provider cost is incurred
• a clear error is returned
• logs reflect the denial

Permission failures are safe and explicit.

---

Logging and Auditing #

Authentication and permission outcomes are visible in:

• Usage Logs
• Execution Logs

This allows you to:

• audit access
• debug permission issues
• validate security assumptions
• support multi-user environments

There is no silent access.

---

Common Mistakes #

• assuming admins should be limited like regular users
• granting bulk access to untrusted roles
• exposing REST API without permission review
• treating guests like authenticated users
• relying only on usage limits for security

Permissions should always come before limits.

---

Best Practices #

Design permissions conservatively. Grant access by role, not by habit. Restrict bulk and automation features to trusted roles. Keep guest access minimal. Treat REST API access as production access. Review logs after enabling new features.

---

Summary #

Authentication and permissions in Aimogen form the first line of defense for AI execution. Authentication establishes identity. Permissions determine allowed actions. Together, they ensure that AI features are only accessible to the right users, in the right contexts, and under controlled conditions. This security model applies consistently across the UI, frontend, automation, and REST API, making Aimogen safe to scale without sacrificing control or visibility.