Key facts
| MSP fit | Workspace per client; delegated admin with scoped keys and SSO |
| API auth | Bearer API keys, scoped per environment and revocable on rotation |
| Workforce identity | SSO with SCIM provisioning for technician accounts |
| Authorization | RBAC with least-privilege scopes per key |
| Tenant isolation | Separate workspaces, keys and vector namespaces per client |
| Audit | Authentication, key lifecycle and admin events exportable to SIEM |
| Pricing | Flat monthly self-serve plans; no per-token billing |
| Free plan | plugsky-micro and plugsky-lite, no card; 14-day full-access trial |
TL;DR
- One workspace and key set per client; never a shared MSP-wide credential.
- Technicians sign in with SSO and SCIM, not with personal API keys.
- Broker delegated access server-side and issue short-lived scoped keys.
- Namespace retrieval per client so one tenant's data can never surface in another.
- Stream key and admin events to your SIEM to make multi-tenant operations auditable.
How it works, step by step
- Define a tenant model: workspace per client, naming convention per system and environment, and an owner for every key.
- Federate your identity provider to Plugsky SSO and provision technicians through SCIM so joiners and leavers are handled automatically.
- Issue client scope keys into your secrets manager at onboarding and schedule rotation; never store them in shared documentation or scripts.
- Implement delegated access in the MSP portal, with a broker that validates the session and fetches a short-lived scoped key for the right tenant.
- Namespace embeddings and retrieval per client, and enforce tenant checks in your gateway before any model call.
- Export authentication, key and admin events plus inference metadata to your SIEM, tagged with the client identifier.
- Run an offboarding runbook that revokes keys, freezes namespaces and produces an evidence pack for the client.
Try it yourself
Open the API key security checklist →
The tenant identity model
MSPs sit between their clients and the platform, so the identity design has three layers. Your own staff authenticate with SSO and SCIM against your identity provider. Each client gets a workspace with its own scoped keys, so a compromise in one engagement cannot touch another. End users at the client, where they exist, authenticate against the client's identity provider or your portal, and never receive a Plugsky key.
That three-layer split is what makes multi-tenant AI auditable: every request can be attributed to a client, a system and a purpose without relying on convention or documentation that drifts.
Onboarding and offboarding runbook
Onboarding should be mechanical: create the workspace, issue the keys for the agreed systems and environments, namespace retrieval, register the client in your SIEM mapping, and store the scope in your configuration management system. Offboarding should be just as mechanical in reverse, with a check that no other key points at the tenant.
- Blast radius: keys are per client, per system, per environment.
- Rotation: scheduled, plus immediate rotation when a technician leaves.
- Delegation: consent and access decisions live in your portal, not in prompts.
- Evidence: key lifecycle and inference events tagged with the client identifier.
Margins, reporting and honest limits
Flat monthly self-serve plans keep your cost base stable while you add tenants, and per-key analytics let you attribute usage by client for reporting and chargeback. Because the API is OpenAI-compatible, the same integration work serves every client; only workspace, key and namespace configuration changes. See the live pricing page for plan details.
State limits clearly in client contracts: chat, streaming, JSON mode, function calling and embeddings are live, while audio, images, files and batch endpoints are labelled coming soon. OAuth delegation is implemented in your portal, and Plugsky does not act as the client's consent or records system.
Honest comparison
| Concern | Plugsky MSP pattern | Shared-account approach | Client-hosted platform |
|---|---|---|---|
| Tenant isolation | Workspace, keys and namespaces per client | One key for all clients | One deployment per client |
| Technician access | SSO with SCIM and RBAC | Shared logins | Per-client accounts |
| Delegated access | Broker in the MSP portal | Out of scope | Client-managed |
| Cost model | Flat monthly plans, usage per key | Untraceable spend | Client infrastructure |
| Evidence | Key and inference events per client to SIEM | Limited visibility | Client SIEM only |
Frequently asked questions
How do we isolate each client's data?
Use a workspace per client, scoped keys per client system, and tenant-scoped vector namespaces. Enforce the tenant check in your gateway before any model call.
Do technicians need their own accounts?
Yes. Federate your identity provider with SSO and provision technicians through SCIM so access follows employment, not shared credentials.
Can clients keep control of their identity provider?
Yes. Clients can own their IdP and consent while you hold the workspace keys; the broker validates their session and issues a short-lived scoped key.
How are keys rotated across many clients?
Automate it. Track key metadata in configuration management, rotate on schedule, and revoke immediately on technician departure or client offboarding.
What evidence can we give a client at offboarding?
An evidence pack from your SIEM: authentication and key lifecycle events for their workspace, plus inference metadata, showing that keys and namespaces were revocable and revoked.
Does this work if we white-label the service?
Yes. Keep Plugsky behind your own gateway and brand; the OpenAI-compatible API is an implementation detail of your service.
How do we trial this with a client?
On the free plan with plugsky-micro and plugsky-lite and a bounded workflow, no card required, then move to a paid plan or the 14-day full-access trial.