What should an enterprise AI security checklist cover?

Key facts

Identity	SSO via SAML 2.0 / OIDC and SCIM provisioning on Enterprise
Authorization	RBAC at workspace, role and resource level; scoped per-key permissions
Key custody	BYOK via AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault and HSMs
Isolation	Plugsky cloud, VPC, on-prem and air-gapped deployments
Data controls	PII modes (no-PII, detect-only, passthrough) and region pinning
Audit	Key lifecycle events with actor, timestamp, IP and body hash; SIEM export
Compliance posture	SOC 2 Type II and ISO 27001 readiness in progress (not yet certified)
Contractual frame	Terms at /legal/terms and service commitments at /legal/sla

TL;DR

• Start with identity and keys — most incidents are configuration failures.
• Require evidence: exports, samples and architecture diagrams, not attestations.
• Treat suppression of PII at the boundary as a first-class control.
• Plan incident response for model, key and data paths separately.
• Move to VPC or on-prem when the data path itself is in scope for audit.

How it works, step by step

1. Inventory every place an AI credential or prompt log exists, including notebooks and CI.
2. Federate human access with SAML/OIDC SSO and automate joiner-mover-leaver with SCIM.
3. Replace shared keys with scoped per-service keys and define rotation owners.
4. Decide the PII mode per workload and test redaction on realistic data.
5. Choose the isolation tier the data classification requires — cloud, VPC, on-prem or air-gapped.
6. Turn on audit export to your SIEM and verify actor, action, resource and timestamp.
7. Run a tabletop exercise covering key leak, prompt injection and upstream outage.

Try it yourself

Open the sovereign AI readiness score →

The eight control domains

• Identity: SSO for human access, SCIM for lifecycle, no shared accounts.
• Keys: scoped per service and environment, rotatable, never in source control, with a documented owner.
• Network: private endpoints, egress control, no public data path for regulated workloads.
• Data: classification, residency pinning, PII mode, retention and deletion including derived vectors.
• Model governance: approved model list, prompt review, evaluation gates and change control.
• Audit: immutable logs for key and admin actions, exportable to the SIEM you already run.
• Supply chain: subprocessor inventory, upstream model providers and flow-down terms.
• Incident response: playbooks for key leak, data exposure, model deprecation and provider outage.

The questions that expose weak controls

Ask vendors to demonstrate, not describe:

• Show a configuration export of a production workspace's roles and scopes.
• Show an audit log sample with actor, action, resource and timestamp.
• Explain how a key is revoked and what the blast radius is.
• Show where prompts, completions, embeddings and logs are stored, region by region.
• Explain how customers bring their own keys, and who can revoke them.
• List subprocessors that touch customer data and the change-notification process.
• State certification status precisely — certified, in progress or aligned — and provide the evidence each claim allows.

How Plugsky maps to the checklist

Plugsky supports scoped keys with a 24-hour rotation overlap, SAML 2.0/OIDC SSO and SCIM on Enterprise, workspace/role/resource RBAC, PII modes with no-PII default for embeddings, region pinning, and SIEM-friendly audit export. Key custody can move to your KMS or HSM, and isolation tiers run from shared cloud to VPC, on-prem and air-gapped. Honest gaps: SOC 2 Type II and ISO 27001 are readiness in progress rather than completed certificates, and hyperscalers offer broader native governance suites — so plan compensating controls and verify current evidence during diligence.

Making the checklist operational

A checklist that never changes behaviour is documentation, not security. Assign an owner per domain, record the evidence location, and review quarterly. Tie exceptions to expiry dates so a temporary bypass cannot become permanent. Measure the boring things — percentage of keys rotated on schedule, time to revoke a leaver, audit export freshness — because those dashboards catch drift long before an incident does. Contractual commitments belong in the terms and SLA you sign; use /legal/terms and /legal/sla as the reference points, and keep the checklist aligned with them.

Honest comparison

Control area	Plugsky	Hyperscaler AI platform	Internal build
Identity	SSO/SCIM and RBAC on Enterprise	Mature, broad IdP coverage	You build and operate it
Key model	Scoped keys, 24-hour rotation overlap, BYOK/HSM	Cloud IAM and KMS	Custom key management
Isolation tiers	Cloud, VPC, on-prem, air-gapped	Shared tenancy with dedicated options	Your infrastructure
PII handling	no-PII, detect-only and passthrough modes	Varies by service	You implement
Audit export	SIEM export for key and admin events	Native cloud audit plus SIEM	Custom pipeline
Certification status	SOC 2 / ISO 27001 readiness in progress	Completed audits in most regions	Your own audit burden

Frequently asked questions

What is the minimum viable enterprise AI security baseline?

SSO and SCIM for access, scoped and rotated keys, RBAC, a defined PII mode, and exportable audit logs. Add BYOK and private deployment when key custody or residency enters your regulatory scope.

Does Plugsky support SSO and SCIM?

Yes. SAML 2.0 / OIDC SSO and SCIM provisioning are Enterprise capabilities; confirm plan coverage and test a full deprovisioning cycle during evaluation.

Can we use our own encryption keys?

Yes. BYOK integrations cover AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault and HSMs, so key rotation and revocation stay under your control.

Is Plugsky SOC 2 or ISO 27001 certified?

Not yet — SOC 2 Type II and ISO 27001 readiness are in progress. Treat certifications as pending, request the current evidence, and document compensating controls while readiness concludes.

How do we keep prompts and completions inside our network?

Choose a private endpoint in your VPC, an on-prem deployment, or an air-gapped install. The API contract stays OpenAI-compatible, so application code does not change.

What should we do about prompt injection?

Treat model input as untrusted, keep authorization in your application rather than in prompts, allowlist tools with narrow scopes, and require human approval for irreversible actions.

How do we audit what the AI did?

Use per-request logs with request ID, model, region and status, plus audit logs for key and admin actions, exported to your SIEM. Log tool calls and results on your side for full reconstruction.

What do we sign for contractual commitments?

Service and data commitments belong in the terms at /legal/terms and the SLA at /legal/sla. Review both against your checklist and negotiate enterprise addenda where needed.