Key facts
| Bank fit | Separation of duties: SSO for staff, scoped keys per workload |
| API auth | Bearer API keys, scoped per environment and revocable on rotation |
| Workforce identity | SSO with SCIM provisioning for console and admin access |
| Authorization | RBAC with least-privilege scopes per key |
| OAuth pattern | User-delegated OAuth stays in your app; keys stay server-side |
| Audit | Authentication, key lifecycle and admin events exportable to SIEM |
| Residency | Region-locked planes plus VPC, on-prem and air-gapped |
| Free plan | plugsky-micro and plugsky-lite, no card; 14-day full-access trial |
TL;DR
- Federate staff identity with OIDC SSO and automate joiner and leaver flows with SCIM.
- Never give a browser, mobile app or third party a Plugsky key; broker calls in your backend.
- Issue scoped keys per service, environment and purpose, and rotate on schedule.
- Pin inference and logs to a region-locked plane or deploy in your VPC or on-prem.
- Export authentication, key and admin events to the SIEM for supervisory review.
How it works, step by step
- Separate the two identity planes in your design: workforce login to consoles, and API access from services.
- Connect your IdP to Plugsky SSO and enable SCIM so group membership drives RBAC roles and offboarding revokes access.
- Create service identities for each workload and issue scoped keys into your secret manager — never into application config or client code.
- Implement customer-delegated OAuth in your application's authorization server, then have a broker exchange the app session for a short-lived scoped key server-side.
- Route model calls through your API gateway to the OpenAI-compatible endpoint so quota, entitlements and logging stay in one place.
- Export authentication, key lifecycle and admin events plus inference metadata to your SIEM, and rehearse key rotation and revocation.
- Pilot with one bounded workflow and a named owner before extending OAuth scope to further systems.
Try it yourself
Open the API key security checklist →
What OAuth covers — and what stays in the bank
OAuth and OIDC solve identity and delegation, not model access. In a bank that splits into two planes. Workforce access covers staff signing into consoles and admin tools; Plugsky supports SSO with SCIM provisioning for that plane, mapped to RBAC roles. Customer-delegated access covers a customer authorising your application to act; that flow belongs in your own authorization server, with consent records kept where supervisors expect to find them.
Plugsky's API itself authenticates with scoped bearer keys. The pattern that keeps auditors comfortable is simple: the customer's token never reaches the model provider, and the Plugsky key never reaches the customer's device. A broker in your backend maps one to the other.
Reference flow from IdP to inference
The sequence is: your IdP authenticates the user through OIDC or federation, SCIM provisions entitlements, and service accounts receive scoped keys per workload in a secrets manager. When a customer consents, your authorization server issues an application token; the broker validates it, checks entitlements, and obtains a short-lived scoped key before calling the OpenAI-compatible endpoint.
- Keys: one per service, environment and purpose, with expiry and rotation.
- Policy: quota, model allow-lists and prompt filters enforced at your gateway.
- Evidence: consent, token issuance and key usage joined in your audit store, with inference metadata exported to the SIEM.
- Revocation: offboarding in the IdP revokes console access immediately; keys are rotated the same day.
Controls, residency and evidence
Pin workspaces to a region-locked plane — EU (Frankfurt), GCC (UAE), APAC (Singapore) or US (Virginia) — or deploy in your VPC, on-prem or air-gapped where in-country processing is mandatory. Keep keys and logs in the same jurisdiction as the data, configure retention to the minimum your policy allows, and review the DPA before production traffic.
Be honest about boundaries in your architecture review: Plugsky does not replace your authorization server, entitlements engine or consent management, and it does not execute banking transactions. It provides the model API, authentication surface, residency options and audit events your controls wrap around. See the live pricing page for plans and enterprise scoping.
Honest comparison
| Concern | Plugsky | API-key-only vendor | Building in-house |
|---|---|---|---|
| Staff sign-in | SSO (OIDC) with SCIM provisioning | Shared admin credentials | Build identity from scratch |
| Service authentication | Scoped keys with rotation and revocation | One broad key for everything | Custom token service |
| Customer delegation | OAuth implemented in your app in front of the API | Not supported | You run the authorization server |
| Least privilege | RBAC plus per-key scopes | Coarse roles | Hand-rolled policy code |
| Audit trail | Auth and key events exportable to SIEM | Limited vendor logs | You build the evidence |
Frequently asked questions
Does Plugsky support OAuth?
Two parts. Workforce sign-in to the console can use SSO with SCIM provisioning, and API calls authenticate with scoped bearer keys. Customer-delegated OAuth is implemented in your own application, which holds the Plugsky key server-side.
Can a browser or mobile app call Plugsky directly with an access token?
No. Keep Plugsky keys server-side and have your backend broker calls, so you can rotate or revoke credentials without shipping a new client build.
How do we enforce least privilege?
Issue separate scoped keys per service, environment and purpose, map IdP groups to RBAC roles, and review key usage alongside authentication and admin events.
How do we evidence control to auditors?
Export authentication, key lifecycle and admin events to your SIEM, and retain consent records and token issuance in your own systems where supervisors expect to see them.
Where is data processed?
Choose a region-locked plane — EU (Frankfurt), GCC (UAE), APAC (Singapore) or US (Virginia) — or deploy in your VPC, on-prem or air-gapped.
What about rotation and revocation?
Plugsky keys are revocable; rotate them on schedule and immediately on staff or vendor changes. SCIM offboarding removes console access, and the broker should stop issuing sessions for the same user.
Is the API OpenAI-compatible?
Yes. OAuth work happens around the API, not inside it, so your SDK, prompts and evaluation harness stay as they are.