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 workspace, one scoped key and one audit trail per client.
- Hold tenant keys server-side so clients never touch them.
- Delegated admin roles let technicians help without broad privileges.
- Quotas prevent one tenant from degrading service for others.
- Make isolation an onboarding checklist and review keys quarterly.
How it works, step by step
- Define the tenant model: workspace, key, quota and audit trail per client.
- Create the onboarding checklist and run it for every new client.
- Issue scoped keys per tenant and store them in your server-side gateway.
- Map staff roles to duties and authenticate technicians through SSO.
- Automate joiners and leavers with SCIM so access does not outlive employment.
- Export audit events per tenant and share evidence in client reviews.
- Offer private deployment options for clients with stricter requirements.
Try it yourself
Open the AI API key security checklist →
Why MSPs need an access model
An MSP's worst day is one client's incident becoming every client's incident. If all tenants share a platform key, or a technician's personal key reaches production, a single leak has unlimited reach. Client security reviews increasingly ask precisely this question: how is our data separated from your other customers?
Answer it with structure: one tenant, one workspace, one scoped key, one audit trail. Add delegated admin roles so first-line technicians can support a client without holding platform-wide privileges.
The four layers: identity, permission, keys, evidence
The control model has four layers. Identity: SAML 2.0 or OIDC single sign-on on Enterprise, with SCIM handling joins, moves and leavers so deprovisioning is automatic. Permission: RBAC with workspace, role and resource-level permissions decides who can read, run and administer. Keys: scoped API keys per project, environment or tenant, each with rate limits and quotas, so a leaked key has a bounded blast radius. Evidence: request and administrative events export to your SIEM — Splunk, Sentinel, QRadar or Datadog — with retention up to 7 years. For MSPs, the model extends to tenants: a workspace and key per client, with evidence that can be exported in a client's own review.
Controls MSPs should configure first
Keep tenant keys server-side in your gateway, attach tenant identity there, and let clients see usage reported per key. Per-key rate limits and quotas prevent one tenant's runaway job from degrading service for others, and audit logs with user, model and region fields give each client evidence in their own review.
For your own staff, roles should map to duties — support, engineering, billing — with SSO for authentication and SCIM for joins and leavers. Where a client requires stricter isolation, offer VPC, on-prem or air-gapped deployment with BYOK, and include the DPA and sub-processor list in the onboarding pack you already send.
A practical rollout order
Turn isolation into a checklist: workspace created, key issued and stored, quotas set, audit export configured, client admin role assigned. Run it for every onboarding, and review keys quarterly. Prototype on the free plan, then standardise on a paid plan as the client count grows. 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
Can clients administer their own users?
Yes. Use workspace and role permissions to delegate administration for a single tenant without granting access to any other client or to platform-wide settings.
How do we prove client separation in a security review?
Show the workspace and key model, per-tenant quotas, and audit logs filtered by tenant. The separation is structural rather than a metadata filter, which is easier to defend.
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.