Operator System Card

We assessed user goals (referred to as “tasks”) and the steps a model could take to fulfill those user goals (referred to as “actions”) to identify risky tasks and actions and develop mitigating safeguards. Our intention is to ensure the model refuses unsafe tasks and gives the user appropriate oversight and control over its actions.

In developing policy, we categorized tasks and actions by their risk severity, considering the potential for harm to the user or others, and the ease of reversing any negative outcomes. For instance, a user task might be to purchase a pair of new shoes, which involves actions like searching online for shoes, proceeding to the retailer’s checkout page, and completing the purchase on the user’s behalf. If the wrong pair of shoes is purchased, the action could inconvenience and frustrate the user. To address such risks, we created a policy requiring safeguards for risky actions like completing a purchase.

These safeguards include measures like requiring human oversight at key steps and explicit confirmation before proceeding on certain actions. This approach applies to model actions such as conducting financial transactions, sending emails, deleting calendar events, and more to ensure users maintain visibility and control when assisted by the model. In some cases where the risk is determined to be too significant, we fully restrict the model from assisting with certain tasks, such as selling or purchasing stocks.

We aim to mitigate potential risks to users and others by encouraging the model to adhere to this policy of human-in-the-loop safeguards across tasks and actions (detailed in the Risk Mitigation section below).

OpenAI engaged a cohort of vetted external red teamers located across twenty countries and fluent in two dozen languages to test the model’s capabilities, safety measures, and resilience against adversarial inputs. Prior to external red teaming, OpenAI first conducted an internal red teaming exercise with representatives from our Safety, Security and Product teams. The goal was to identify potential risks using a model with no model-level or product-level mitigations in place, and red teamers were instructed to intervene before the model could cause any real-world harm. Based on the findings from that internal exercise, we added initial safety mitigations and granted the external red teamers access to Operator. We then asked the external red teamers to explore various ways to circumvent the model’s safeguards, including prompt injections and jailbreaks.

Since the model has access to the internet, the external red teamers were advised to avoid prompting the model to complete tasks that could cause real-world harm. In certain cases, they created test environments—such as mock websites, databases, or emails—to safely demonstrate possible exploits. Given this constraint, their findings may not fully capture the worst-case real-world risks, but still identified key vulnerabilities that informed additional mitigations which were implemented to strengthen the model’s safeguards (see the Risk Mitigation section below). Accordingly, Operator is initially being deployed as a research preview to a limited group of users to allow close monitoring of real-world usage in order to strengthen safeguards and address emerging risks before broader release.

We evaluated the Operator model according to OpenAI’s Preparedness Framework³, which grades models on four frontier risk categories: persuasion, cybersecurity, CBRN (chemical, biological, radiological, and nuclear), and model autonomy. The Operator model is trained on top of a GPT‑4o base model, whose frontier risks are assessed in the GPT‑4o system card¹, and inherits the risk level for the persuasion and cybersecurity categories (“Medium” and “Low” risk respectively).

The net-new frontier capability increase for Operator is visual browsing via keyboard and cursor. The two evaluations in our framework that computer-use could plausibly impact are biorisk tooling for CBRN and autonomous replication for model autonomy. We adapted these two evals for the computer-use setting and found the pre-mitigation Operator model to be “Low” risk in both categories, consistent with the GPT‑4o model.

We observed that Operator struggled to properly perform optical character recognition (OCR) and interact with long DNA sequences using only screenshots and a graphical user interface. Random-looking strings like DNA present issues for Operator’s OCR system. It is possible that one factor for its poor performance is that molecular biology tasks stand far outside its training distribution. This 1% qualifies as “Low” risk, matching GPT‑4o’s “Low” risk level, as detailed in OpenAI’s Preparedness Framework⁠(opens in a new window)³.

Operator users are bound by OpenAI Usage Policies⁴, which apply universally to OpenAI services and are designed to ensure safe and responsible usage of AI technology. As part of this release, we are publishing guidelines to clarify how those usage policies apply to Operator, explicitly emphasizing that Operator should not be used to:

• facilitate or engage in illicit activity, including compromising the privacy of others, exploiting and harming children, or developing or distributing illicit substances, goods, or services,
• defraud, scam, spam or intentionally deceive or mislead others, including using Operator to impersonate others without consent or legal right, falsely representing to others the extent to which they are engaging with an agent, or creating or employing deception or manipulation to inflict financial loss on others,
• engage in regulated activity without complying with applicable laws and regulations, including the use of Operator to automate decision making in high consequence domains like stock trading or other investment transactions, or
• harm others, including by creating or distributing content that is used to sexualize children or defame, bully, or harass others.

Users are also prohibited from bypassing any protective measures implemented in OpenAI services, including rate limits or restrictions and safety mitigations.

At the model level, Operator is trained to refuse certain harmful tasks. We confirmed that the model meets the same safety bar set for ChatGPT for conversational harms, even in computerusing contexts. For new, agentic harms (such as illicit activity or purchasing illicit items), Operator refuses 97% of tasks on an internal evaluation set, which consists of scenarios where the harmful prompt appears either as the initial prompt or mid-conversation. For our initial release, we have tuned the refusals to be especially cautious; Operator indeed overrefuses substantially more than GPT‑4o.

Below is an example of a refusal, as well as refusal rates on several representative risk categories. It is important to note that achieving 100% performance in evaluation does not guarantee the same level of performance in real-world deployment.

(a) Comparison of Operator and the latest version of GPT‑4o’s refusal rates on a test set across selected categories of harmful tasks

The second category of harm is if the model mistakenly takes some action misaligned with the user’s intent, and that action causes some harm to the user or others. For example, it may inadvertently buy the wrong product, causing some financial loss to the user, or at least costing the user some time to undo. The severity may range from very minor (e.g., typo in a sent email) to severe (e.g., transferring a large sum to the wrong party).

We aimed to produce a model that is aligned to the user’s intent as closely and often as possible, aiming for a low baseline model mistake rate. To quantify the rate, we ran the unmitigated model on a distribution of 100 prompts resembling tasks we project users might use Operator for (e.g., purchases, email management). We found 13 errors that caused some nuisance, although 8 of them could be easily reversed (i.e., within a few minutes). The other 5 mistakes were, to some degree, irreversible or possibly severe, including:

• an email sent to the wrong recipient
• two instances of email labels incorrectly bulk-removed
• an incorrectly dated reminder for the user to take their medication, and
• an incorrect item ordered for food delivery

With these baseline rates in mind, we aimed to reduce the impact and risk of model mistakes, primarily through confirmations, which reduced the risk by approximately 90%. Confirmations and additional mitigations like proactive refusals and watch mode are described below.

To further reduce the chance of model mistakes causing harm, we aim to have the model ask the user for confirmations before finalizing actions that affect the state of the world (e.g., before completing a purchase or sending an email). This ensures that even if the model has made a mistake, the user has a chance to intervene before it has an effect. On an evaluation set of 607 tasks across 20 categories of the aforementioned risky action policy (see Policy Creation above), the post-mitigation model asks for confirmation with an average recall percentage of 92%, which measures the fraction of the time a confirmation is needed. We believe that checking with the user on these high-risk actions with this frequency significantly reduces the risk of harm from model mistakes.

Below are two examples of Operator asking for confirmation:

In this early stage, we decided to proactively refuse certain high-risk tasks like banking transactions and making high-stakes decisions, as per the risky task policy described in the Policy Creation section above. On a synthetically generated evaluation set, Operator refuses these tasks with a recall of 94%.

On certain websites, the impact of mistakes may be higher. For example, on email services there may be an increased risk of Operator inadvertently sharing sensitive information. In these scenarios, we require that the user supervise Operator’s actions by automatically pausing execution when the user becomes inactive or navigates away from the page. The user can resume the conversation once they return back to the page (see Figure 1).

Figure 1: Example of watch mode warning

The final category for model mistakes is an emerging risk known as prompt injections. A prompt injection is a scenario where an AI model mistakenly follows untrusted instructions appearing somewhere in its input. For Operator, this may manifest as it seeing something on screen, like a malicious website or email, that instructs it to do something that the user does not want, and it complies.

We made the model more robust to this type of attack. To evaluate our mitigations, we compiled an eval set of 31 automatically checkable prompt injection scenarios, that represent situations to which older versions of our model were at some point susceptible. The score indicates the model’s susceptibility to prompt injection, so lower is better (although not every case is necessarily an actual concern). We evaluated our final model’s behavior on these scenarios and found the model to have 23% susceptibility, compared to 62% with no mitigations and 47% with only prompting. A manual review of these examples showed that only one truly concerning example remained, and it was caught by the prompt injection monitor, described later in this section. This example is also covered by watch mode.

Below is an example of a mitigated prompt injection:

Added March 11, 2025:

Launching the Computer-Using Agent (CUA) model in the API allows developers to deeply integrate and automate short, repetitive tasks in broader environments—ranging from internal process automation and end-to-end browser testing to consumer applications. We are initially releasing the model as a Research Preview to select developers on Tiers 3-5 to gather feedback and refine its safety and reliability.

The model is being released as computer-use-preview, given the risks associated with its use in the API:

• The model may be susceptible to inadvertent model mistakes, especially in non-browser environments that the CUA model is less used to. For example, CUA’s performance on OSWorld⁶ is currently at 38.1% indicating that the model is not yet highly reliable for automating tasks on OS. Human oversight is recommended in these scenarios.
• The ability to modify system messages in the API increases the potential for jailbreaks to enable the model to take actions that are disallowed by its policy [see Section 3.1 for actions that are disallowed].
• Since the API can be used in non-browser environments, the impact of a successful prompt injection is heightened given the potential for use on Local OS. The surface area to encounter adversarial prompt injections is also increased.
• The API opens the potential for higher-scale misuse (e.g., automated spam or fraud at greater volume).

Our red teaming exercises focused on identifying incremental risks introduced by the API, with developers testing the potential to jailbreak the model to bypass refusals, the potential for harmful mistakes on non-browser surfaces, and the model missing confirmations for sensitive tasks. Results demonstrated that existing safeguards—such as refusal mechanisms, safety checks, and confirmation prompts help to mitigate risk, but there is still potential for mistakes or developer misuse. Careful developer oversight remains essential and the model currently performs best in browser-sandboxed contexts. As noted below, we are also enhancing our monitoring for potential policy violations.

To address these incremental concerns and align with our iterative deployment strategy, we have introduced the following safety measures for the API:

• Prompt Injection and Sensitive Domain Safety Checks: We’ve carried over these Operator safety checks into the API, providing increased visibility and early warning for potentially malicious instructions.
• Containerized Starter Setup: We provide an easy-to-use Docker application for safer implementation, encouraging developers to use isolated environments.
• Enhanced Monitoring and Enforcement: We’ve expanded detection of potential policy violations, including jailbreaks, larger-scale misuse or suspicious patterns of API usage.

We recommend that developers follow best practices⁷—such as isolating their environment (e.g., via virtual machines) and regularly reviewing the model’s actions—to ensure that CUA-based applications are used responsibly and within approved guidelines.

The CUA model is still in its early stages. It performs best on short, repeatable tasks but faces challenges with more complex tasks and environments like slideshows and calendars. We will collect real-world feedback to inform ongoing refinements, and we expect the model’s quality to steadily improve over time.

We are initially deploying Operator to a small set of users. We plan to carefully monitor this early rollout, and use feedback to improve safety and reliability of our systems. As we learn and improve, we plan to slowly roll this out to our broader user base.

OpenAI plans to maintain ongoing evaluations of Operator and efforts to further improve Operator’s adherence to OpenAI’s policies and safety standards. Additional improvements in areas such as prompt injection are planned, guided by evolving best practices and user feedback.