Key facts
| Single sign-on | SAML 2.0 / OIDC SSO on Enterprise |
| Provisioning | SCIM user provisioning and deprovisioning on Enterprise |
| Permission model | RBAC with workspace, role and resource-level permissions |
| API keys | Scoped keys per project, environment or tenant; per-key rate limits and quotas |
| Audit logs | Request and admin events export to SIEM (Splunk, Sentinel, QRadar, Datadog) |
| Key custody | BYOK via AWS KMS, Azure Key Vault, HashiCorp Vault or an on-prem HSM |
| Compliance | SOC 2 Type II under NDA, ISO 27001/27017/27018, HIPAA with a BAA; FedRAMP Moderate in process |
| Deployment | Hosted, VPC, on-prem and air-gapped with the same API |
TL;DR
- Separate the control plane from the data plane in the design.
- Humans authenticate via SSO; workloads authenticate via scoped keys.
- Mirror existing organisational boundaries in workspace and role design.
- Audit export and retention are architecture decisions, not afterthoughts.
- The same access model survives hosted, VPC, on-prem or air-gapped deployment.
How it works, step by step
- Draw the control plane and data plane and name every identity consumer.
- Define workspace boundaries for environments and business domains.
- Design roles from existing job families with resource-level rules where needed.
- Standardise workload identity on scoped keys issued from a secret manager.
- Choose key custody: managed KMS or BYOK with an on-prem HSM.
- Specify audit fields, SIEM export and retention for both request and admin events.
- Set governance cadence for access, quota and model-version reviews.
Try it yourself
Open the AI API key security checklist →
Why enterprise architects need an access model
Draw the control plane and the data plane separately. The control plane covers who can administer the platform, issue keys and read logs; the data plane covers requests, embeddings and outputs. Most AI incidents come from conflating the two — a data-plane key with control-plane powers, or a human account used as a service identity.
Then map identity sources to consumers. Humans come from your IdP; workloads come from your secret manager; partners come through your own gateway so their keys are never yours to leak. The permission model should mirror existing organisational boundaries, not invent new ones.
The four layers: identity, permission, keys, evidence
Think in terms of who, what, which and proof. Who is federated identity — SAML 2.0 / OIDC SSO on Enterprise, with SCIM keeping the user list current. What is authorisation — RBAC with workspace, role and resource-level permissions. Which credential is in use — scoped API keys per project, environment or tenant, with per-key rate limits and quotas. Proof is the audit trail — request and admin events exported to your SIEM, retained up to 7 years. For architects, the model maps onto existing identity governance, so AI joins the standard joiner-mover-leaver process instead of running beside it.
Controls enterprise architects should configure first
Four architecture decisions follow. Workspace boundaries: separate environments and business domains so permissions and quotas do not need exceptions. Role granularity: keep roles coarse enough to administer and fine enough to satisfy least privilege, with resource-level permissions where data sensitivity demands it. Key custody: BYOK through AWS KMS, Azure Key Vault, HashiCorp Vault or an on-prem HSM when policy requires it. Evidence: log requests and admin actions, export to Splunk, Sentinel, QRadar or Datadog, and set retention to match the strictest applicable policy, up to 7 years.
Because the same model applies to hosted, VPC, on-prem and air-gapped deployment, the access design survives a change of data plane.
A practical rollout order
Roll out in phases: identity federation, then key scoping, then audit export, then governance routines — access reviews, quota reviews and model-change reviews on the same cadence as other dependencies. Prototype on the free plan and use Enterprise for SSO, SCIM and private deployment. See the live pricing page for current plans.
Honest comparison
| Control | Plugsky | Shared API keys only | Building in-house |
|---|---|---|---|
| Single sign-on | SAML 2.0 / OIDC on Enterprise | Not available | You integrate the IdP |
| Deprovisioning | SCIM on Enterprise | Manual key deletion | Custom lifecycle jobs |
| Permission granularity | Workspace, role and resource-level | One key for everything | You build the model |
| Key scoping | Per project, environment or tenant, with quotas | Shared key, no attribution | Custom key service |
| Audit evidence | Request and admin events with SIEM export | Limited request logs | You build the pipeline |
| Key custody | BYOK via KMS or on-prem HSM | Provider-managed keys | You operate the HSMs |
Frequently asked questions
What belongs in the control plane versus the data plane?
Control plane: admin actions, key issuance, role changes and log access. Data plane: inference, embeddings and outputs. Give them separate identities so a compromised workload key cannot administer the platform.
How granular should roles be?
Start with roles that match job families and add resource-level rules only where data sensitivity requires them. Excessive granularity becomes unmaintainable and hides real over-permissioning.
Do we need the OpenAI SDK to change?
No. Authentication and access control sit alongside the same OpenAI-compatible API, so application code keeps working when keys or roles change.
Is there a free plan?
Yes — plugsky-micro and plugsky-lite with 2 API keys and no credit card. A 14-day full-access trial is also available.
How is pricing structured?
Self-serve plans are flat monthly with unlimited fair-use usage and no per-token charges or overage fees. See the live pricing page for current plans.
Can we keep our own identity provider?
Yes on Enterprise: SAML 2.0 / OIDC SSO and SCIM provisioning work with standard identity providers, and RBAC maps your roles to workspace and resource permissions.