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
- Every privileged action should be attributable to a person or service.
- Role design follows clearance and function, not convenience.
- Audit export to the departmental SIEM covers requests and admin actions.
- BYOK and on-prem HSM custody keep keys with the institution.
- The same access model runs in air-gapped deployments with no egress.
How it works, step by step
- Federate with the department identity provider and agree role mappings.
- Automate joins and leavers with SCIM on the internal network.
- Issue scoped keys to services and contractors with named sponsors and review dates.
- Export request and administrative events to the departmental SIEM.
- Set retention to the strictest applicable policy, up to 7 years.
- Decide key custody and, where required, run the stack in an air-gapped deployment.
- Formalise an access review before expanding the pilot.
Try it yourself
Open the AI API key security checklist →
Why government need an access model
Public-sector AI access has three drivers: insider risk, accountability and continuity. Privileged access must be attributable to a person, contractor or service; role design has to reflect clearance and function rather than convenience; and when the programme is reviewed, the evidence must exist without a scramble.
The failure mode is familiar: one platform key shared across a programme, a departed contractor's credentials still working, and no record of who asked the system what. Fixing this before the pilot is far cheaper than retrofitting access controls after an incident.
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 government programmes, the same four layers hold in air-gapped deployments, so privileged activity stays visible even without internet egress.
Controls government should configure first
For air-gapped and sovereign programmes, identity stays local: federate with the department's IdP, keep SCIM provisioning on the internal network, and maintain a local authoritative list of keys and owners. Audit events export to the national or departmental SIEM with retention up to 7 years, covering both request activity and administrative actions such as key issuance and role changes.
Key custody can stay with the institution through BYOK with AWS KMS, Azure Key Vault, HashiCorp Vault or an on-prem HSM. Where classification demands it, the same access model runs inside an on-prem or air-gapped deployment with no internet egress and offline update channels. SOC 2 Type II under NDA, ISO 27001/27017/27018 and HIPAA with a BAA support vendor review; FedRAMP Moderate is in process, so treat it as pending.
A practical rollout order
Pilot with an internal, unclassified workload and a small group, then formalise access review before widening it. Everyone with a key should have a named sponsor, a role and a review date. Prototype on the free plan, then move to the deployment plane the programme requires. 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
Does identity federation work in an air-gapped deployment?
Yes. Federation and SCIM run against internal identity services, and the platform needs no internet egress; the same SSO, role and audit model applies.
Are administrative actions logged too?
Yes. Administrative events such as key issuance, role changes and configuration updates are exportable alongside request logs, so privileged activity is visible in the same trail.
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.