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
- Build roles from operational duties: NOC, SOC, care, engineering, automation.
- SSO and SCIM keep human access aligned with employment and contracts.
- One scoped key per automation system, with quotas and full logging.
- SIEM export with retention up to 7 years supports regulatory evidence.
- Region-locked, on-prem or air-gapped deployment per data classification.
How it works, step by step
- Interview NOC, SOC, care and engineering teams about required data reach.
- Define roles from those duties with least privilege as the default.
- Federate human access through SSO and automate lifecycle with SCIM.
- Issue one scoped key per automation system and environment, with quotas.
- Ensure audit logs capture automated and human actions alike.
- Export events to the SIEM with retention matched to regulatory policy.
- Choose deployment plane and key custody per workload classification.
Try it yourself
Open the AI API key security checklist →
Why telcos need an access model
Telcos have many teams touching the same platforms: NOC, SOC, care, field operations, engineering, plus contractors and a growing fleet of automation. Each has different data reach, and each will be audited at some point. Generic 'everyone is an admin' access fails the first regulatory review and the first incident postmortem.
Start from operations rather than org charts: what does a night-shift NOC engineer need to query? What may an automation run without human review? Roles built from answers to those questions are easier to defend and easier to maintain.
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 telcos, the layers map to operations: NOC, SOC and care roles, scoped keys per automation system, and a trail that satisfies regulatory review.
Controls telcos should configure first
Give humans SSO and automate lifecycle with SCIM, so contractor access ends when the contract does. Give automation scoped keys — one per system and environment — with quotas that cap damage from a runaway job, and log every call so an automated action is as attributable as a human one.
Export request and administrative events to Splunk, Sentinel, QRadar or Datadog with retention up to 7 years; that covers both service assurance and regulatory evidence. Where data classification requires it, deploy region-locked, on-prem or air-gapped, and keep key custody with BYOK through AWS KMS, Azure Key Vault, HashiCorp Vault or an on-prem HSM. RBAC with workspace and resource-level permissions keeps roles aligned to each deployment plane.
A practical rollout order
Pilot with one operational team and one automation, prove attribution end to end, then extend role by role. Prototype on the free plan and engage 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
How do contractors fit the role model?
Time-bound roles with a named sponsor, deprovisioned through SCIM when the contract ends, and reviewed on the same cadence as employee access.
Are automated actions attributable?
Yes. Each automation system uses its own scoped key, so audit logs tie every automated request to a system, an environment and an owner.
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.