An engineer leaves the company. The laptop is collected and the SSO account disabled — but the OpenAI workspace membership, added by manual invite a year earlier, survives all of it. So does the connector they authorized. Nobody watches that boundary, because nobody decided it was one.
OpenAI security is not just prompt hygiene. The newest identities in your organization belong to AI itself: workspaces, projects, keys, apps, files, and connectors are identities with power, and the member roles and retention settings around them complete the boundary.
That makes this a different kind of review than cloud exposure work. It is a SaaS and developer-platform control plane. The question is not what infrastructure can be reached, but who can use AI systems, which business data they can connect, and which actions those systems can take. Prompt security does not matter much if workspace access is unmanaged.
Start with identity. Workspace owners and admins should be intentional. Membership should follow employment and group lifecycle. Strong account protection is a requirement for anyone who can administer users, apps, projects, keys, or data.
SSO and SCIM matter because informal lifecycle does not scale. If people join and leave through manual invitations, stale accounts and accidental admins become normal. Managed lifecycle keeps the workspace aligned with the real organization.
Project structure matters on the API side. Production, development, experimentation, and client work should not share the same keys, service accounts, budgets, or access assumptions.
Connectors and apps move the data boundary. A workspace that can reach drives, repositories, tickets, or internal knowledge inherits the access hygiene of those systems. If source permissions are messy, connected AI will surface the mess.
AI access is quiet. That is the problem. Review admin events, key creation, app and connector changes, unusual usage, and retention settings. The security team should know not only that AI is being used, but which boundary it is crossing.
What to check now: workspace owners, admin roles, SSO and SCIM, MFA or passkey adoption, project membership, service accounts, API keys, app approvals, connector scopes, uploaded knowledge, audit logs, and retention settings.
The goal is to make one compromised user, token, app, or project boring: bounded, visible, revocable, and unable to quietly become a standing entrance into the organization.