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
- One scoped key per service and environment, never a shared production key.
- Store keys in a secret manager and inject them at runtime.
- Per-key quotas contain runaway usage from a single service.
- Human access belongs to SSO; machine access belongs to keys.
- Rotate on a schedule and group usage by key ID for traceability.
How it works, step by step
- Inventory every place an API key is currently stored or hard-coded.
- Create a scoped key per service and environment and record an owner for each.
- Move keys into your secret manager and remove them from code and CI variables.
- Set per-key rate limits and quotas that match each service budget.
- Enable audit logging and group usage by key ID in the dashboard.
- Automate rotation with an overlap window so deployments do not break.
- Federate human access through SSO and deprovision with SCIM.
Try it yourself
Open the AI API key security checklist →
Why developers need an access model
The shared-key anti-pattern is everywhere: one production key pasted into a CI variable, a staging deployment and a local .env file. When it leaks, you cannot tell whether the traffic came from your app, a notebook or an attacker, and revoking it breaks everything at once. The fix is boring and effective — split the key.
Issue a scoped key per service and environment, store it in your secret manager, inject it at runtime, and never let it near prompts, logs or client-side code. Group dashboards by key ID and usage spikes become traceable instead of mysterious.
The four layers: identity, permission, keys, evidence
Start with identity, then constrain what each identity can do. Federation uses SAML 2.0 or OIDC on Enterprise; SCIM provisions and removes users automatically. Authorisation is RBAC with workspace, role and resource-level permissions, and machine access is separated into scoped API keys per project, environment or tenant with their own rate limits and quotas. Everything is observable: request and administrative events export to Splunk, Sentinel, QRadar or Datadog, and retention runs up to 7 years. For developers, the practical win is blast-radius control: when one key leaks, only one service and one environment are affected, and rotation is routine.
Controls developers should configure first
Then layer the platform controls. Per-key rate limits and quotas stop one service from consuming the budget; workspace and resource-level permissions separate prototypes from production; people authenticate through SAML or OIDC SSO rather than sharing keys. SCIM removes access automatically when someone leaves, which is the easiest compliance win you will ever ship.
For secrets themselves, keep rotation on a calendar you can automate. Old keys stay valid briefly while deployments roll, then are revoked, so rotation does not become an outage. If your threat model requires it, BYOK through your own KMS keeps encryption keys under your control even in a hosted deployment.
A practical rollout order
Adopt in this order: inventory keys, split by service and environment, move secrets into a manager, add quotas per key, enable audit export, then federate humans with SSO. Prototype on the free plan, which includes 2 API keys, and move to a paid self-serve plan when you outgrow fair-use limits. 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
Should CI use the same key as production?
No. Use a separate scoped key for CI with tight quotas, and never let pipeline keys touch production data or prompts. Separate keys make revocation surgical.
How do we rotate keys without downtime?
Create the new key, deploy it everywhere, verify traffic on the new key ID, then revoke the old one. An overlap window makes rotation routine instead of risky.
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.