What the OpenAI Preparedness Framework actually covers
The OpenAI Preparedness Framework is aimed at catastrophic and frontier risks from advanced models. It defines tracked risk categories, evaluation mechanisms, and thresholds that can gate further development or deployment when safeguards are judged insufficient. Core tracked areas include cybersecurity (offensive capability), CBRN-related assistance, persuasion and manipulation, and model autonomy behaviors such as agentic self-exfiltration, self-proliferation, or resource acquisition.
Evaluations are not a substitute for routine enterprise accuracy, bias, or service-quality metrics. They combine baseline capability assessments, red-teaming, and safeguarded post-mitigation scoring rather than relying only on training-time alignment. OpenAI has stated it will not deploy models that reach High or Critical levels on tracked categories without adequate mitigations, and may pause development at Critical without sufficient safeguards.
For enterprise deployers, the practical takeaway is narrower than the public discussion often implies. The framework informs which models ship with which residual capability profiles. It does not automatically configure your agent orchestrators, tool adapters, secrets, data boundaries, or production monitoring. Those remain customer responsibilities once models are integrated into applications with real permissions and side effects.
Provider preparedness versus enterprise responsibility
Provider preparedness addresses whether a model should be released and under what residual capability profile. Enterprise responsibility begins when that model is given identity, tools, data paths, and the ability to cause side effects in your environment. Confusing the two leads to over-reliance on model refusals and under-investment in authorization, monitoring, and evidence.
Shared-responsibility clarity should be explicit in usage-policy and legal review: what the provider covers at the model and platform boundary, and what the enterprise must enforce in production agent stacks. Secondary summaries can overstate protections. Base decisions on primary framework scope and your own residual-risk analysis.
Map preparedness risk categories to concrete agent scenarios
Before production, map each framework category to the actual agent you plan to run. This mapping should be use-case specific. A retrieval assistant with read-only document access and no external actions has a different residual profile than an operations agent that can open tickets, change infrastructure, move funds, or send email.
| Risk category | When it becomes concrete | Example enterprise signals |
|---|---|---|
| Cybersecurity | Agent can call code execution, cloud APIs, vulnerability scanners, or internal admin interfaces | Unexpected tool chains, privilege-broadening attempts, high-risk destinations |
| Autonomy | Multi-step planners can acquire credentials, expand tool access, persist state, or initiate outbound actions without a human gate | Session sprawl, credential acquisition patterns, unapproved persistence |
| Persuasion | Agents message customers, employees, or partners at scale | Outbound volume spikes, unapproved audiences, manipulative content flags |
| CBRN-related assistance | Domain tools, knowledge bases, or research workflows could support prohibited assistance paths | High-risk domain queries combined with capable tools or data access |
Document which model tier is in scope, which tools are enabled, what data domains are reachable, and which framework-aligned harms remain plausible after provider mitigations.
NIST AI RMF functions (Govern, Map, Measure, Manage) are a useful translation layer. They do not replace the Preparedness categories, but they give governance leaders a structure for ownership, measurement, monitoring, and change control when model capability or agent autonomy increases. Pin assessments to the framework version and evaluation methodology relevant to the deployed model, because public materials evolve and full scorecard detail is not always customer-visible.
Runtime architecture for frontier-model agents
A production agent stack typically includes the model endpoint, a planner or orchestrator, tool adapters, identity and secrets, and an observability path. Provider safeguards sit at the model and platform boundary. Enterprise controls must sit where intent becomes action: before tool side effects execute against mail systems, code runners, payment rails, cloud control planes, or sensitive data stores.
Separate identity for agents from human user identity. Bind tokens to least-privilege roles and short-lived credentials. Place a tool-call mediator in front of adapters so policy can inspect intended action and arguments, enforce allow or deny decisions, require approval for high-impact operations, and record the decision. Segment environments and data by risk tier so frontier-model agents do not receive unrestricted network paths or production-admin privileges by default.
Design explicit degradation paths. Session termination, tool disablement, and capability reduction should be first-class controls when monitors detect threshold breaches, privilege escalation attempts, exfiltration-like patterns, or high-risk domain content. Auditability depends on correlation across model or request identifiers, agent session identity, tool-call payloads and results, policy decisions, and human escalations. Without that join key design, later investigation and assurance reviews cannot reconstruct what the agent was permitted to do.
Implement runtime controls that own residual risk
Translate the mapping into enforceable controls rather than policy documents alone. Codify tool-use rules at the orchestrator: allow, deny, or require approval. Validate arguments, constrain destinations, and keep high-impact actions behind human-in-the-loop gates. Do not rely on model refusals as the only authorization mechanism when tools can produce irreversible effects.
Continuous monitoring should watch for anomalous tool sequences, attempts to broaden privileges, suspicious data access volume or destinations, and content patterns tied to your higher-risk scenarios. Define severity criteria that route to human operators and security teams, and retain decision logs for those escalations. Pair monitoring with rapid revocation: disable a tool, revoke a credential, or terminate a session without waiting for a full incident process.
OpenAI API and enterprise offerings expose identity, project, and key management plus usage monitoring constructs. Those are necessary configuration inputs, not a complete governance system for autonomous agents. Enterprises still need application-layer authorization, data handling rules, operational oversight, and evidence that safeguards remain effective as workflows change.
Governance evidence and operating ownership
- Split ownership explicitly: AI governance or model risk accepts thresholds and residual risk. Security and engineering own runtime enforcement. Internal audit tests evidence quality.
- Keep a deployment evidence package: Link use-case risk assessment, model tier, enabled tools, safeguard configs, residual risks, approvals, incident runbooks, and access reviews.
- Align change management: Treat model upgrades and new agent autonomy as control-triggering changes, not routine library bumps.
- Clarify shared responsibility: Usage-policy and legal review should state what the provider covers versus what the enterprise must enforce in production.
- Prefer measurable signals: Track policy denials, approval latency, revoked sessions, anomalous tool patterns, and completeness of correlated audit trails.
- Avoid overclaiming provider guarantees: Secondary summaries can overstate protections. Base decisions on primary framework scope and your residual-risk analysis.