Teams adopt OpenAI directly, often without the onboarding that governs the rest of your cloud. The organization has its own members, pending invites, projects, API keys, and a live inference surface, all outside the controls that protect the rest of your estate.
Today Turbot Guardrails brings the same prevention-first model to the OpenAI API platform. The new OpenAI Prevention mod adds objectives that govern who can reach the organization, which credentials stay valid, and which models projects can run. Every objective is enforced directly at the OpenAI API and continuously remediated when the live state drifts.
Control Who Can Reach Your Organization
Much of the risk on a fresh AI platform is identity: an out-of-domain account that should never have joined, an owner-level invite sent to the wrong address, an API key that has not rotated in a year. Guardrails checks each of these against a policy you set and acts when the live state falls out of line.
Membership and invites are governed by an allowlist. OpenAI > User > Allowed > Email Domain removes existing members whose email domain falls outside your list. The invite-stage controls reject pending invites for out-of-domain identities and revoke invites carrying non-approved roles, so the over-privileged member never lands in the first place.
Stale invites are revoked once their age crosses your threshold, so a compromised mailbox cannot redeem an old invitation. Members idle beyond a window you define are removed, so dormant accounts do not pile up as unused access. Roles are capped too: organization membership is limited to approved roles, and project membership is governed per project, independent of org posture.
API keys are long-lived credentials, easy to create and easy to forget. OpenAI > API Key > Active > Age flags keys past their useful life, and because OpenAI surfaces a last-used timestamp, OpenAI > API Key > Active > Recently Used removes keys that have gone idle. Organization-wide Admin API keys are rotated on the same model, and project key ownership is restricted to approved owner types, typically forbidding user-owned keys in production so workloads run on service-account credentials.
OpenAI identity, invite, and key-rotation objectives, each with its own coverage score.
Control Which Models Projects Can Run
Membership decides who is in. The next question is what they can run. OpenAI > Project > Approved Models locks a project's inference to an allowlist. Disallowed models are disabled per project so OpenAI refuses requests against them, which keeps experimentation inside the boundary your governance team has set without blocking the models that are approved.
Project inference locked to an allowlist of approved models.
Recommendations for Improvement
For each objective, Guardrails shows your current posture and the steps to close the gap.
Take the approved-models allowlist. Guardrails flags the projects still running models outside your list, and offers two ways to fix it:
- Config layer: zero the per-model rate limits on the disallowed models through the OpenAI API, so OpenAI refuses inference against them.
- Runtime layer: enforce the allowlist with the OpenAI > Project > Approved Models control, which re-applies the zero limit whenever a disallowed model reappears.
Each option includes the deployment steps to roll it out across every project.
Each objective comes with its posture, implementation options, and deployment steps
Runtime Prevention
Each objective runs as a Guardrails control against the OpenAI API. It reads the live state on a schedule, compares it to your policy, and remediates the difference directly.
Take an out-of-domain member. Set OpenAI > User > Allowed > Email Domain to delete members outside your domain list, and when someone invites and then accepts a personal-email account, the control moves to alarm and removes the user through the OpenAI API. Owner-level members are surfaced by alarm only, since the platform write-protects them. The gap is found and closed without a ticket.
Prevention-First Security for Your Entire Stack
Preventive security for AI brings the same prevention-first approach that enterprise teams rely on for AWS, Azure, GCP, GitHub, and OCI. Block what should never happen at the access layer, enforce the right configuration at runtime, and correct drift automatically, the same defense in depth that protects the rest of your cloud. It is one part of a broader set of AI preventions launching this week.
Interested in bringing preventive security to your AI environment? Connect with us to get your free preventive security posture assessment.