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
- Bring AI access under the same governance as the rest of the bank.
- People use SSO; workloads use scoped keys with quotas.
- Translate existing job families into workspace, role and resource permissions.
- SIEM export with retention up to 7 years answers access-review questions.
- Federate identity first, then replace shared keys with attributed ones.
How it works, step by step
- List every human group and service that calls the AI platform today.
- Map existing job families to workspace, role and resource-level permissions.
- Federate identity with SAML/OIDC SSO and automate lifecycle with SCIM.
- Replace shared keys with a scoped key per application and environment.
- Apply per-key rate limits and quotas to bound runaway usage.
- Export request and admin events to your SIEM with policy-matched retention.
- Run an access review and confirm every key has an owner.
Try it yourself
Open the AI API key security checklist →
Why banks need an access model
Banks already have the hardest part: an access governance regime. Joiners, movers and leavers are processed through controlled workflows, access reviews happen on a calendar, and auditors expect evidence. AI platforms often arrive outside that regime, sharing one API key across teams with no attribution — which is exactly the pattern internal audit will flag.
Bring AI into the same model. People authenticate through your identity provider, permissions follow job families, workloads authenticate with scoped keys, and every request lands in the audit trail with a user, a model, a time and a region.
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 banks, the audit trail is the point: access reviews and incident forensics both depend on naming the identity behind every request.
Controls banks should configure first
Map roles before you map models. Start from existing job families — developer, analyst, risk, operations — and translate them into workspace, role and resource-level permissions. Service accounts get scoped keys per application and environment, with per-key quotas so one runaway process cannot consume the platform.
For evidence, export request and administrative events to your SIEM and set retention to match policy, up to 7 years. BYOK through AWS KMS, Azure Key Vault, HashiCorp Vault or an on-prem HSM keeps encryption keys inside your custody, and VPC, on-prem or air-gapped deployment keeps processing inside the perimeter. Review the DPA, sub-processor list and EU SCC coverage as part of vendor risk, and treat SOC 2 Type II and ISO 27001 evidence as inputs to your own control testing.
A practical rollout order
Sequence the rollout: federate identity first, then convert shared keys into scoped keys per application, then turn on audit export, and only then widen access. Prototype on the free plan to validate the key model, and use Enterprise for SSO, SCIM and private deployment. 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 we keep service accounts attributable?
Yes. Give each service a scoped key per environment, record the owner, and group usage by key ID so every request maps back to a system and a team.
How do access reviews work with API keys?
Treat keys as access entitlements: assign owners, review them on the same cadence as user access, and use audit logs to confirm each key is still required and correctly scoped.
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.