--- title: "Anomity Joins OpenAI Daybreak Blue | Anomity Blog" description: "Anomity's OpenAI organization is approved for Daybreak Blue: what the tier changes, what it leaves in place, and what the approval does not reach." url: "https://anomity.ai/blog/anomity-openai-daybreak-blue/" source: html --- Anomity Joins OpenAI Daybreak Blue Contents - What Daybreak Blue is - What Blue deliberately leaves in place - Approval is not activation - What it covers for us - Where it fits with our other programs - How Anomity covers what a provider approval cannot see - Frequently asked questions 0% 6 min read Share - X.com - LinkedIn - Email - Copy URL - Copy markdown [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Anomity Joins OpenAI Daybreak Blue ![Anomity robot illustrating Anomity Joins OpenAI Daybreak Blue] Company # Anomity Joins OpenAI Daybreak Blue Anomity Research Anomity Research · Oct 22, 2026 · 6 min read Share: Copied TL;DR - Anomity's OpenAI organization has been approved for Daybreak Blue , the defensive tier of OpenAI's Trusted Access for Cyber program. The access is held at the organization level , through organization approval, not granted to individual engineers one by one. - Daybreak Blue gives reduced refusals on supported mainline models , including GPT-5.5, GPT-5.6 Sol, GPT-6 Sol and GPT-6 Luna, for verified defensive work: vulnerability triage, secure code review, malware analysis, detection engineering, incident response and patch validation. It gives no access to cyber-specialized models ; those sit in Daybreak Red , which needs separate approval. - Blue does not switch safeguards off. OpenAI's usage policies and its Cyber Abuse Policy still apply, Astra and GPT-6.1-Sol keep standard safeguards on Blue, the approval does not include Zero Data Retention, and it may never be extended to customers or customer-facing traffic. - Approval alone changes nothing. Daybreak ships off by default : a workspace owner enables it for approved roles and groups, an API organization owner enables it per project, and Codex users turn on a per-request toggle. - For us it covers the research team's dual-use analysis behind our advisories and the Skill Risk Index. It is not in the product path and changes nothing about how Anomity handles customer data. - It joins the Anthropic Cyber Verification Program , Claude for Startups and the NVIDIA Inception program , and our signature on OpenAI's open letter on collective cyber defense. Anomity's OpenAI organization has been approved for **Daybreak Blue**, the defensive tier of OpenAI's **Trusted Access for Cyber** program. The access is held at the organization level: it comes from organization approval, and members inherit it through the organization rather than through individual grants. We wrote about Daybreak when OpenAI expanded it, from the angle of a security team governing it: [the security agent on your analyst's laptop has your analyst's permissions](https://anomity.ai/blog/openai-daybreak-defensive-agent-governance/). This post is the other side. What the Blue tier actually changes, what it deliberately leaves in place, what it covers for us, and what an approval like this does not reach. ## What Daybreak Blue is Daybreak is OpenAI's program for qualified enterprises and cybersecurity practitioners doing authorized defensive work. It exists for the same reason Anthropic's [Cyber Verification Program](https://anomity.ai/blog/anomity-anthropic-cyber-verification-program/) does: at the level of a prompt, much of defense reads exactly like offense, and a model that cannot tell who is asking refuses both. Daybreak supplies the missing fact, an approved operator, and adjusts the safeguards to match. It has two tiers above standard access. Access What it gives Intended for **Standard** Mainline models with standard safeguards. No cyber-specialized models. Secure SDLC and AppSec work: threat modeling, secure code review and patching, general blue teaming. **Daybreak Blue** Reduced refusals on supported mainline models, including GPT-5.5, GPT-5.6 Sol, GPT-6 Sol and GPT-6 Luna. Astra keeps standard safeguards. No cyber-specialized models. Vulnerability triage, secure code review, malware analysis, detection engineering, incident response and patch validation. **Daybreak Red** Cyber-specialized models such as GPT-5.5-Cyber, plus reduced refusals on more mainline models, including Astra. Separate approval, stronger verification, extra access controls. Authorized penetration testing, red teaming, exploit validation or development, and controlled vulnerability research. OpenAI calls Blue the recommended starting point for most security teams, and it is the right tier for what we do. Red is the tier for building and validating exploits, which is not our work, and it is open only to approved business and enterprise organizations with its own onboarding. ## What Blue deliberately leaves in place The most common misreading of programs like this is that approval turns the safety training off. It does not, and OpenAI's own documentation says so plainly. Under Daybreak Blue: - Usage policies still apply , including OpenAI's Cyber Abuse Policy, which disallows dual-use activity carried out with malicious intent, without authorization or in excess of it. - Not every model changes. Astra and GPT-6.1-Sol keep standard safeguards on Blue; reduced refusals on them are a Red-tier feature today. - Some requests are still refused. OpenAI notes that safeguards can still apply after approval, even on Red. - No Zero Data Retention. Trusted access and data retention are separate arrangements. - Internal use only. Daybreak may not be resold, proxied, embedded, or extended to customers, external users, customer-facing workflows or downstream product traffic. - Authorized targets only. Systems the organization owns, operates, or is explicitly authorized to test or analyze. That shape is the right one. It moves one boundary, between default-refused and allowed, for one organization, and keeps a floor under everyone else. ## Approval is not activation The detail security teams should notice is that an approved organization sees no change at all on the day it is approved. Daybreak ships **off by default**, and it is turned on per surface: - ChatGPT and Codex workspaces: a workspace owner enables Daybreak for approved users and groups, using custom roles. OpenAI recommends keeping it off in the workspace default and on only for the intended role. - API: an organization owner enables it for each approved, non-default project, and requests can set access_programs.cyber explicitly in the Responses API. - Codex App: a Daybreak toggle in the advanced model picker turns reduced refusals on for a request; it is off until switched on. - Codex CLI: /daybreak in an interactive session, or daybreak=true in headless commands and configuration. Two exceptions in OpenAI's documentation deserve a line in any internal runbook. On surfaces that have no Daybreak toggle, Daybreak is on by default for all supported requests. And on workflows pinned to Codex CLI versions older than the release that introduced the switch, it is also on by default. In other words, the per-request control exists only where the client is new enough to offer it. Knowing which machines run Codex CLI, and in which pipelines, is part of knowing where Daybreak is actually live, which is the same inventory question we covered in [rolling out OpenAI Codex across a fleet](https://anomity.ai/blog/rolling-out-openai-codex-fleet-governance-guide/). There is a second path to watch. Individuals can apply for Daybreak Blue on their own, with an eligible paid plan, Advanced Account Security and a FIDO2 hardware key. That is a good bar for a personal account. It also means a security engineer can hold Blue on a personal ChatGPT account that the organization's role controls never touch, which is the same corporate-versus-personal account question behind [what employees paste into consumer AI tools](https://anomity.ai/blog/shadow-ai-data-exposure-what-employees-paste/). ## What it covers for us Anomity publishes security research, and that is where dual-use analysis shows up in our work: deciding whether a flaw in agent or MCP infrastructure is actually reachable before we publish a severity, reconstructing what a malicious agent skill's payload would do, and writing the detections that catch it. It shows up again in the [Skill Risk Index](https://anomity.ai/skills/), where the hard calls are whether a pattern in a public skill is a real attack signal or a documented installer. Daybreak Blue covers that analysis on OpenAI models, as the Cyber Verification Program covers it on Claude. What it does not cover matters as much. Under OpenAI's rules Daybreak is internal-only, so it is not in the product path, and nothing about the product changes: Anomity collects metadata only, never source and never prompts, redacts secret values on the endpoint before anything leaves the machine, and is SOC 2 Type II attested. ## Where it fits with our other programs Daybreak Blue is our second provider-side cyber approval, after Anthropic's [Cyber Verification Program](https://anomity.ai/blog/anomity-anthropic-cyber-verification-program/) in June 2026. It sits alongside two startup programs, [Claude for Startups](https://anomity.ai/blog/anomity-claude-for-startups/) and the [NVIDIA Inception program](https://anomity.ai/blog/anomity-nvidia-inception-program/), which buy something different: early sight of the surfaces our customers will have to govern. And Anomity is a signatory of OpenAI's open letter, A call for collective action on cyber defense. Daybreak is where that letter turns into day-to-day practice. ## How Anomity covers what a provider approval cannot see Daybreak is a well-built control, and it governs what one approved organization may ask one provider's models, through the surfaces that provider controls. It does not see the endpoint those requests come from: the Codex CLI session running with an analyst's full permissions, the MCP servers and skills loaded into it, the secrets in its config, the local model runtime someone switched to after a refusal, or the personal account in a browser tab. As we argued in [autonomous security agents are agents too](https://anomity.ai/blog/autonomous-security-agents-are-agents-too/), a security tool earns no exemption from that inventory. That is the layer Anomity covers. The Endpoint Sensor inventories Codex CLI, the Codex App and every other agent, MCP server, extension, plugin, skill, secret, hook, CLI and local LLM runtime on Windows, macOS and Linux endpoints. The Browser Sensor shows which AI services are used and whether with a corporate or a personal account. Cloud discovery covers the AI applications holding OAuth grants in Google Workspace and GitHub. On agents that expose a hook, including Codex CLI, Anomity decides allow, deny or log before an action runs, and every decision lands in a 90-day audit trail. To see where Daybreak-capable tools already run across your fleet, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What is OpenAI Daybreak Blue? Daybreak Blue is an access tier inside Daybreak, OpenAI's Trusted Access for Cyber program. OpenAI calls it the recommended starting point for most security teams. It gives approved organizations and individuals reduced refusals on supported mainline models, including GPT-5.5, GPT-5.6 Sol, GPT-6 Sol and GPT-6 Luna, for verified defensive work in authorized environments: vulnerability triage, secure code review, malware analysis, detection engineering, incident response and patch validation. It does not include cyber-specialized models. What is the difference between Daybreak Blue and Daybreak Red? Blue lowers refusals on mainline models for defensive work. Red adds cyber-specialized models such as GPT-5.5-Cyber, reduced refusals on more models including Astra, and is intended for authorized offensive testing: penetration testing, red teaming, exploit validation or development, and controlled vulnerability research. Red requires a separate approval, stronger verification and access controls, and is available only to approved business and enterprise organizations. Blue approval does not include Red. Is Anomity's access organization-wide or per person? Organization-wide. Our Daybreak access comes from organization approval, and member access is managed at the organization level rather than through individual controls. Inside the organization, Daybreak is still off until a workspace owner enables it for the roles and groups that should have it. Does Daybreak Blue remove OpenAI's safeguards? No. OpenAI is explicit that Daybreak does not remove all safeguards or all refusals, and does not reduce refusals on every model by default. Usage policies, the Cyber Abuse Policy and other access controls continue to apply. On Blue, Astra and GPT-6.1-Sol keep their standard safeguards, and some clearly dual-use requests can still be refused. Can Daybreak be used in a product or for customers? No. OpenAI limits Daybreak to approved internal use. It may not be extended to third-party customers, external users, customer-facing workflows or downstream product traffic, and it may only be used on systems the approved organization owns or is explicitly authorized to test. That is why Daybreak covers our research work and not the Anomity product. How is Daybreak turned on once an organization is approved? Per surface. In a ChatGPT or Codex workspace, a workspace owner enables Daybreak for approved users and groups, and OpenAI recommends keeping it off in the workspace default. API organization owners enable it per approved project, and requests can set access_programs.cyber explicitly in the Responses API. In the Codex App, a toggle in the advanced model picker turns it on for a request; in Codex CLI, /daybreak in interactive sessions or daybreak=true in headless use. OpenAI notes two default-on cases: surfaces with no Daybreak toggle, and workflows pinned to Codex CLI versions older than the one that introduced the switch. Does this change how Anomity handles customer data? No. Daybreak covers internal research use only and has no bearing on the product. Anomity is SOC 2 Type II attested, collects metadata only, and redacts secret values on the endpoint before anything leaves the machine. No customer data is involved in Daybreak in any way. How does Anomity help security teams that use Daybreak? Daybreak governs what an approved organization may ask OpenAI's models. Anomity covers where those requests come from: it inventories Codex CLI, the Codex App and the other agents and CLIs on each managed endpoint, with their MCP servers, skills, hooks and secrets; the Browser Sensor shows whether ChatGPT is being used with a corporate or a personal account; and on Codex CLI, Anomity's managed hooks decide allow, deny or log before an action runs. That is the layer a provider-side approval cannot see. ## Related posts [Insights ### OpenAI Daybreak: The Security Agent on Your Analyst's Laptop Has Your Analyst's Permissions Daybreak gives approved defenders a scanning agent across ChatGPT, GitHub, CLI and a desktop app. Local scans inherit OS permissions with no approval pause. Anomity Research · Sep 18, 2026 · 5 min](https://anomity.ai/blog/openai-daybreak-defensive-agent-governance/) [Insights ### OpenAI's Agents API: The Harness Moved to the Vendor, the Governance Did Not OpenAI's Agents API puts the Codex harness behind one API call. Sandboxing is now a config value, MCP servers are a field, and sessions run for days. Anomity Research · Sep 18, 2026 · 6 min](https://anomity.ai/blog/openai-agents-api-managed-harness-governance/) [Company ### Anomity Joins the NVIDIA Inception Program Anomity is now a member of the NVIDIA Inception program: the platform we have built, the traction behind the milestone, and what membership gives us. Anomity Research · Oct 2, 2026 · 5 min](https://anomity.ai/blog/anomity-nvidia-inception-program/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Anomity Joins OpenAI Daybreak Blue", "description": "Anomity's OpenAI organization is approved for Daybreak Blue: what the tier changes, what it leaves in place, and what the approval does not reach.", "datePublished": "2026-10-22", "dateModified": "2026-10-22", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Anomity Research" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/anomity-logo.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/anomity-openai-daybreak-blue/", "relatedLink": [ "https://anomity.ai/blog/openai-daybreak-defensive-agent-governance/", "https://anomity.ai/blog/openai-agents-api-managed-harness-governance/", "https://anomity.ai/blog/anomity-nvidia-inception-program/" ] }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/anomity-openai-daybreak-blue.png", "width": 1200, "height": 630 }, "articleSection": "Company", "wordCount": 1151, "timeRequired": "PT6M", "inLanguage": "en", "url": "https://anomity.ai/blog/anomity-openai-daybreak-blue/", "keywords": "OpenAI Daybreak Blue, OpenAI Daybreak, Daybreak Blue, Trusted Access for Cyber, OpenAI, Company news, Defensive AI, Codex, Agent Governance" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is OpenAI Daybreak Blue?", "acceptedAnswer": { "@type": "Answer", "text": "Daybreak Blue is an access tier inside Daybreak, OpenAI's Trusted Access for Cyber program. OpenAI calls it the recommended starting point for most security teams. It gives approved organizations and individuals reduced refusals on supported mainline models, including GPT-5.5, GPT-5.6 Sol, GPT-6 Sol and GPT-6 Luna, for verified defensive work in authorized environments: vulnerability triage, secure code review, malware analysis, detection engineering, incident response and patch validation. It does not include cyber-specialized models." } }, { "@type": "Question", "name": "What is the difference between Daybreak Blue and Daybreak Red?", "acceptedAnswer": { "@type": "Answer", "text": "Blue lowers refusals on mainline models for defensive work. Red adds cyber-specialized models such as GPT-5.5-Cyber, reduced refusals on more models including Astra, and is intended for authorized offensive testing: penetration testing, red teaming, exploit validation or development, and controlled vulnerability research. Red requires a separate approval, stronger verification and access controls, and is available only to approved business and enterprise organizations. Blue approval does not include Red." } }, { "@type": "Question", "name": "Is Anomity's access organization-wide or per person?", "acceptedAnswer": { "@type": "Answer", "text": "Organization-wide. Our Daybreak access comes from organization approval, and member access is managed at the organization level rather than through individual controls. Inside the organization, Daybreak is still off until a workspace owner enables it for the roles and groups that should have it." } }, { "@type": "Question", "name": "Does Daybreak Blue remove OpenAI's safeguards?", "acceptedAnswer": { "@type": "Answer", "text": "No. OpenAI is explicit that Daybreak does not remove all safeguards or all refusals, and does not reduce refusals on every model by default. Usage policies, the Cyber Abuse Policy and other access controls continue to apply. On Blue, Astra and GPT-6.1-Sol keep their standard safeguards, and some clearly dual-use requests can still be refused." } }, { "@type": "Question", "name": "Can Daybreak be used in a product or for customers?", "acceptedAnswer": { "@type": "Answer", "text": "No. OpenAI limits Daybreak to approved internal use. It may not be extended to third-party customers, external users, customer-facing workflows or downstream product traffic, and it may only be used on systems the approved organization owns or is explicitly authorized to test. That is why Daybreak covers our research work and not the Anomity product." } }, { "@type": "Question", "name": "How is Daybreak turned on once an organization is approved?", "acceptedAnswer": { "@type": "Answer", "text": "Per surface. In a ChatGPT or Codex workspace, a workspace owner enables Daybreak for approved users and groups, and OpenAI recommends keeping it off in the workspace default. API organization owners enable it per approved project, and requests can set access_programs.cyber explicitly in the Responses API. In the Codex App, a toggle in the advanced model picker turns it on for a request; in Codex CLI, /daybreak in interactive sessions or daybreak=true in headless use. OpenAI notes two default-on cases: surfaces with no Daybreak toggle, and workflows pinned to Codex CLI versions older than the one that introduced the switch." } }, { "@type": "Question", "name": "Does this change how Anomity handles customer data?", "acceptedAnswer": { "@type": "Answer", "text": "No. Daybreak covers internal research use only and has no bearing on the product. Anomity is SOC 2 Type II attested, collects metadata only, and redacts secret values on the endpoint before anything leaves the machine. No customer data is involved in Daybreak in any way." } }, { "@type": "Question", "name": "How does Anomity help security teams that use Daybreak?", "acceptedAnswer": { "@type": "Answer", "text": "Daybreak governs what an approved organization may ask OpenAI's models. Anomity covers where those requests come from: it inventories Codex CLI, the Codex App and the other agents and CLIs on each managed endpoint, with their MCP servers, skills, hooks and secrets; the Browser Sensor shows whether ChatGPT is being used with a corporate or a personal account; and on Codex CLI, Anomity's managed hooks decide allow, deny or log before an action runs. That is the layer a provider-side approval cannot see." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Anomity Joins OpenAI Daybreak Blue", "item": "https://anomity.ai/blog/anomity-openai-daybreak-blue/" } ] } ```