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 AI Gateways, policies, provider connections, and the model catalog.
Manage token quotas, monthly USD budgets, and per-model pricing.
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 AI 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 | ✅ | ✅ | ✅ |
| AI Developer | ✅ | – | – |
| AI Finance | – | ✅ | – |
| AI Analytics | – | – | ✅ |
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 AI 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 definitions 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 — LLM Providers, Vector Database, Knowledge Bases, Model Catalog, 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. This is the way to turn a read-only platform preset or provider into something you can customize: duplicate it, then edit the copy.
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.