Access Control and Roles
AI Permission Groups
Access to AI Gateway is scoped through three permission groups, each independent of the others:
Create and edit LLM Gateways, policies, provider connections, and the models of a provider.
Manage limit plans and assign them to consumers, API clients, applications and organizations, and read usage reports. The Identity group is accepted in its place for these.
View usage reports, cost breakdowns, and request traces — read-only.
AI Development and Proxy Management
For managing a proxy — editing it, deleting it, starting or stopping a trace, clearing trace logs, rolling back to an earlier deployed version, regenerating its public or secret key — AI Development × Manage and API Management × Manage are interchangeable: holding either one is enough. This applies to every proxy type, not only LLM Gateways, so a user who holds AI permissions alone is never blocked halfway through a flow they were allowed to start.
Deploying and undeploying is deliberately kept separate: it requires the Deploy/Undeploy action — on AI Development for AI, MCP and A2A gateways, and on API Management for other proxy types. Manage alone never grants the right to push a change live.
AI Roles
Four built-in roles combine these permission groups so you can assign access by job function instead of granting each permission individually:
| Role | Development | Budgets | Analytics |
|---|---|---|---|
| AI Admin | All actions | All actions | All actions |
| AI Developer | View, Manage, Deploy/Undeploy, Export/Import | View only | View only |
| AI Finance | – | View only | View only |
| AI Analytics | View only | View only | View only |
Assign these roles to users the same way you assign any other Apinizer role — a person can hold a different AI role in each project or team they belong to.
Explicit Deploy (Save Isn't Deploy)
Saving a change to an LLM Gateway, policy, or provider connection doesn't put it into effect immediately — the change sits in a redeploy required state until someone explicitly deploys it. This gives you a review point between editing and going live, the same explicit-deploy model used throughout the Apinizer gateway. See Deployment Models for how deployment works across environments.
Shared Records
Some AI Gateway records belong to the platform rather than to a single project:
- The built-in LLM provider templates Apinizer ships with (OpenAI, DeepSeek, Voyage AI, Moonshot, Zhipu)
- The built-in vector database connections (PgVector, Qdrant)
- The built-in guardrail presets (personal-data, prompt-guard, and data-loss protection templates)
- Any record a system administrator creates from the Administration section and shares with every project
These records appear on the relevant list screens in every project — Models, Vector Database, Knowledge Bases, Prompt Templates, and the PII, DLP, Prompt Guard, and Prompt Decorator preset screens — so every project can see and reuse them. From inside a project, though, they're read-only:
| You can, on a shared record in a project | You cannot, on a shared record in a project |
|---|---|
| View it | Edit it |
| Export it (if you have export/import access) | Delete it |
| View its audit history | Enable or disable it |
| Duplicate it | Roll it back |
This holds no matter how much access you have — a user with AI Development Manage permission, or one who can reach every project, still can't change a shared record from a project screen; the buttons for the actions you can't perform simply aren't shown there. To edit, delete, enable/disable, or roll back a shared record, open it from the Administration section instead.
Duplicate, Audit, and Rollback
AI Gateway assets use the general Asset Lifecycle operations — Duplicate, Audit, and Rollback — from the asset's own list and detail screens.
Duplicate is the exception to the table above: it works on shared and built-in records too. The copy is created inside your own project, and because you now own it, it's no longer "built-in" — you can edit or delete it right away. Duplicating is useful when you want the shipped record to stay as it is and work on a copy — the shipped records themselves are editable too, so it is a choice rather than the only route.
A record that belongs to a different project — not a shared, platform-wide one — can't be duplicated at all; you only see it in Administration's cross-project lists, and there's no project of yours to resolve it into.
Audit and Rollback follow the record's context. Viewing audit history only needs View permission and is available even on shared and built-in records. Rolling back is a change, so it needs Manage permission on a record you're allowed to edit from where you're looking at it — a shared record opened from a project doesn't offer a rollback action, but the same record opened from Administration does. The tab title reflects this: it reads "Audit" where rollback isn't available, and "Audit and Rollback" where it is.
To move a configuration to a different project or environment — rather than duplicating it within your current one — use Export/Import; see Global Policies for how this applies to AI policies.
Directory (LDAP/AD) Identity Sync for AI Users
If your organization manages identities in LDAP or Active Directory, those users — and the AI roles assigned to them — can be kept in sync automatically instead of maintained by hand in Apinizer. This uses the same directory sync integration as the rest of Apinizer's identity management, so AI users don't need a separate onboarding process. See LDAP / Active Directory to configure directory sync.
Source Types
Each organization record carries a label that shows where it comes from:
| Source | Description |
|---|---|
| Manual | Created directly by a user |
| LDAP OU | Synchronized from a directory organizational unit |
| LDAP Group | Synchronized from a directory group |
Synchronization Screen
From Synchronization under Identity Management you can run a synchronization manually (Synchronize Now) and review past runs. Consumer and organization records show a directory badge and a read-only directory information panel.
Records Removed From the Directory
What happens to records that were no longer in the directory on the last run is set by Deactivation Mode on the LDAP provider:
| Behavior | Description |
|---|---|
| Disable (recoverable) | The record is made inactive and can be restored (default) |
| Delete (irreversible) | The record is permanently deleted |
| None (keep as is) | The record is left as it is; the drift is accepted |