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
- Access follows minimum necessary for clinical and administrative roles.
- Services get scoped keys with quotas, not shared or borrowed credentials.
- SCIM deprovisioning closes access when staff or contractors leave.
- VPC, on-prem or air-gapped deployment with BYOK and a HIPAA BAA for covered workloads.
- Keep PHI out of shared collections and document control mapping.
How it works, step by step
- Define roles by function and map them to workspace and resource permissions.
- Separate administrative collections from any patient-adjacent content.
- Federate staff authentication with SSO and automate lifecycle with SCIM.
- Issue scoped keys to services with an owner, a purpose and a review date.
- Export audit events to your SIEM and set retention to match policy.
- Deploy covered workloads in your VPC, on-prem or air-gapped with BYOK and a BAA.
- Run access reviews with privacy and security officers before scaling.
Try it yourself
Open the AI API key security checklist →
Why healthcare need an access model
Healthcare access is defined by minimum necessary and workforce lifecycle. Staff rotate between departments, contractors cover shifts, and students and residents come and go. Any system that grants broad access 'for now' creates a review problem that compounds every quarter.
AI adds a new consumer class: services that summarise, retrieve or draft. Those workloads need their own identities and narrow scopes, not a clinician's account or a shared integration key. Treat them like staff accounts with a defined purpose and a review date.
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 healthcare, minimum-necessary access maps to role design, and SCIM makes workforce turnover a solved problem rather than a quarterly cleanup.
Controls healthcare should configure first
Model the organisation: role definitions by function (clinical, billing, compliance, IT), workspace separation between administrative and patient-adjacent workloads, and resource-level rules for the most sensitive collections. People authenticate through SSO; SCIM removes access when employment ends; services use scoped keys with per-key quotas.
Audit logs record model, tokens, latency, user and region per request and export to your SIEM with retention up to 7 years, which supports access reviews and incident investigation. For covered workloads, deploy in your VPC, on-prem or air-gapped with BYOK and a HIPAA BAA, and keep PHI out of shared collections. Document the control mapping against your HIPAA Security Rule provisions rather than claiming compliance as a feature.
A practical rollout order
Start with administrative corpora and a small group, prove the access model, then extend to patient-adjacent workloads with privacy and security sign-off. Prototype on the free plan, then move to a covered deployment before PHI is involved. 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
How do contractors and students fit the model?
Give them time-bound roles with an end date and a named sponsor, deprovision through SCIM at the end of the rotation, and review their access like any other workforce member.
Do we need a BAA for every workload?
Workflows that handle protected health information need a BAA and a deployment that keeps PHI inside your perimeter. Administrative workflows on de-identified or public content can run with a lower tier.
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.