Key facts
| Architect fit | Token broker maps app tokens to scoped keys; gateway enforces policy |
| 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 plus per-key scopes for workload identity |
| Audit | Authentication, key lifecycle and admin events exportable to SIEM |
| Residency | Region-locked planes: EU (Frankfurt), GCC (UAE), APAC (Singapore), US (Virginia) |
| Deployment | Plugsky cloud, your VPC, on-prem and air-gapped |
| Pricing | Flat monthly self-serve plans; enterprise scoping on the pricing page |
TL;DR
- Treat workforce identity and workload identity as separate planes with separate controls.
- Put a token broker behind your existing gateway: app token in, scoped key out.
- Keep entitlements, quotas and model allow-lists in your gateway, not in client code.
- Pin each business unit to a region-locked plane, or deploy in your VPC or on-prem.
- Join consent, key usage and inference metadata in one audit store for reviewers.
How it works, step by step
- Document the two identity planes, their owners and the evidence each must produce.
- Federate your IdP to Plugsky SSO and decide which groups map to which RBAC roles before enabling SCIM provisioning.
- Place a token broker behind your API gateway: validate the internal token, resolve entitlements, then fetch a short-lived scoped key from the secrets manager.
- Define key naming, scope and rotation standards per environment, team and workload, and automate revocation through your existing offboarding runbook.
- Choose the deployment and residency topology per business unit, including VPC, on-prem or air-gapped where required.
- Define the audit schema: consent, token issuance, key lifecycle, model, tokens and latency, exported to the SIEM.
- Run a threat model and a failure-mode review — broker outage, key compromise, region failover — before production cut-over.
Try it yourself
Open the API key security checklist →
Two planes: workforce identity and workload identity
Workforce identity covers people: engineers in the console, administrators changing settings, auditors reading logs. That plane maps naturally to OIDC SSO with SCIM provisioning and RBAC roles, and it needs fast deprovisioning more than it needs long-lived credentials.
Workload identity covers services: the summarisation worker, the agent, the batch job. These must not borrow a human's account. They get scoped keys with least-privilege permissions, stored in your secrets manager and rotated on a defined schedule. User-delegated OAuth sits between the two planes and belongs in your own authorization server, with the broker translating an application session into a scoped key.
Reference topology
The topology that scales is a thin broker behind the gateway you already run. The IdP provides SSO and group data; SCIM keeps roles in sync. Requests arrive with your internal token, the broker validates it, resolves the tenant or user entitlement, and obtains a short-lived scoped key before forwarding to the OpenAI-compatible endpoint in the chosen region.
- Gateway: quota, model allow-lists, prompt policy, and request logging.
- Broker: token validation and key retrieval; no business logic.
- Secrets manager: one scoped key per environment, team and workload.
- SIEM: authentication, key lifecycle and inference metadata joined with consent records.
Decisions, trade-offs and honest boundaries
The broker adds a network hop and a component to operate; in return it centralises policy and makes key rotation invisible to applications. Multi-region deployments should keep keys and logs in the same jurisdiction as the workload, even when the serving plane changes for failover. Review the SLA and DPA against each business unit's obligations before committing.
Be explicit about what Plugsky does not provide: it is not your authorization server, policy engine, consent manager or entitlement database, and it holds no regulatory reporting duties. It supplies a model API with scoped keys, SSO and audit events, and deployment options from shared cloud to air-gapped. See the live pricing page for tiers and enterprise scoping.
Honest comparison
| Concern | Plugsky | SaaS AI platform | Self-hosted stack |
|---|---|---|---|
| Workforce identity | SSO (OIDC) with SCIM and RBAC | Platform accounts, varying federation | Build on your IdP |
| Workload identity | Scoped keys via gateway broker | Platform service accounts | Custom credential service |
| Policy point | Your gateway; API stays OpenAI-compatible | Vendor policy settings | Entirely yours |
| Residency | Region-locked planes plus VPC, on-prem and air-gapped | Vendor regions only | Wherever you deploy |
| Audit | Key, auth and admin events to SIEM | Vendor dashboards and exports | You build the pipeline |
Frequently asked questions
Is Plugsky an OAuth authorization server?
No. Plugsky supports SSO with SCIM for workforce access and authenticates API calls with scoped keys. Your organization's authorization server owns user-delegated OAuth; a broker maps sessions to keys.
Where should the token broker live?
Behind your existing API gateway, so there is one policy and logging point. Keep the broker thin: validate the token, resolve entitlements, fetch a scoped key, forward the request.
How do we manage keys at scale?
Standardise naming and scope per environment, team and workload; store keys in a secrets manager; automate rotation and revocation through the same runbook that handles staff offboarding.
How do we satisfy residency requirements?
Pin each business unit to a region-locked plane, or deploy in your VPC, on-prem or air-gapped. Keep keys and logs in the same jurisdiction as the data they serve.
What evidence can reviewers get?
Authentication, key lifecycle and administrative events are exportable to your SIEM, alongside inference metadata such as model, token count and timestamps.
How does this affect migration risk?
Because the API is OpenAI-compatible and policy lives in your gateway, switching the base URL or rolling back is a configuration change rather than an application rewrite.
Can different teams use different plans?
Yes. Self-serve plans are flat monthly, and enterprise scoping is discussed on the pricing page; separate workspaces and keys keep ownership clean.