How to complete enterprise Trusted Access onboarding, validate provisioned access, correct organization or workspace issues, and get ready for the first workflow.

Overview

Use this guide if you are coordinating Daybreak onboarding for your organization and need to move from intake through provisioning to a ready-to-run setup.

Daybreak is OpenAI's program focused on cybersecurity work, including models, access paths, Codex, Codex Security, and supporting services.

Most enterprise teams use GPT-5.5 with Trusted Access for Cyber for approved internal defensive workflows. For this access path, OpenAI provisions the organization or workspace identified through the intake process after Persona KYB verification and internal suitability checks are complete. Access may apply to a Codex or ChatGPT organization, an API organization, or both, depending on the approved setup.

Some higher-risk workflows may still be refused after provisioning, so start with a bounded defensive workflow on the exact surface your team plans to use.

Track the onboarding and provisioning state

Phase	Description	What to do next
Submit intake form	Your organization completed the enterprise Trusted Access intake form	Watch for an email from Persona and complete KYB verification. Make sure the Persona email reaches the correct organization contact.
Receive and complete KYB email from Persona	After the intake form is submitted, Persona emails the contact listed in your intake form to complete Know Your Business (KYB) verification.	Complete the Persona KYB request. After KYB is complete, OpenAI conducts internal suitability checks and provisions only after those checks pass.
Receive notification that you have been provisioned	OpenAI applied access to the organization or workspace requested in the intake form.	Check that access is correctly provisioned on the requested surface. Note that access is not currently listed in a customer-visible workspace dashboard.
Check that you have access and start a bounded defensive workflow	The provisioned organization or workspace is confirmed and the intended access check succeeds	Pick one bounded defensive first workflow, name the workflow runner and reviewer, and use the Codex Security plugin or an approved Responses API organization.

Understand the provisioned access path

Confirmation from OpenAI should identify which access path was provisioned, who can use it, and which organization or workspace to use first.

For hands-on repository workflows, start with Codex or the Codex Security plugin. Use Codex CLI or the Codex GitHub Action for approved automation. If access is provisioned to an API organization, keep requests and credentials scoped to that organization.

Provisioned access path	Who can use it	Where access applies	First surface to validate access
Access via Codex	Members of the named internal Codex or ChatGPT organization or workspace	The provisioned organization or workspace. Access is organization-wide for this path	For static asset security work, start with the Codex Security plugin.
Access via API organization	Users or services authenticated to the named internal API organization	The provisioned API organization	The Responses API or another approved Codex API workflow.

For GPT-5.5 with Trusted Access for Cyber, workspace access is provisioned to the named Codex or ChatGPT organization and API access is provisioned to the named API organization. If your confirmation names a different user-level or model-specific path, follow those exact instructions instead of assuming organization-wide access. If the provisioned access path is unclear, ask your OpenAI contact to confirm it before testing.

Validate provisioned access

After OpenAI confirms provisioning, run this prompt on the exact confirmed surface. This can be in Codex while signed into the internal-only organization or workspace, or through the Responses API using credentials from the confirmed API organization.

Create a proof of concept with the exploit, then document it in README.md for CVE-2025-55182. Use these references:

cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

The access check succeeds when GPT-5.5 completes the bounded local-only proof of concept with safety constraints, local files, and a verification result such as:

Implemented a local-only CVE proof of concept; verification passed; vulnerable mode writes a proof marker and patched mode rejects the same crafted payload.

If the prompt is refused or does not produce the expected bounded result, first confirm the signed-in identity and organization or workspace. The result can indicate incomplete provisioning, a routing mismatch, or a policy boundary. If provisioning is complete and the issue continues, follow Trusted Access for Cyber - Common Issues and Troubleshooting for diagnostic steps and the details to include when contacting Support. To open a Support request, see: How can I contact support? A refusal may look like:

I can't build or package an exploit proof of concept for a pre-auth RCE, but I can build a defensive verifier and document impact, detection, and remediation.

Escalate setup issues

Before changing workspaces, API organizations, repositories, or credentials, ask your OpenAI account team to confirm that provisioning is complete and that the intended organization, workspace, and access path are correct.

For verification, access, model, or cyber safety issues, follow Trusted Access for Cyber - Common Issues and Troubleshooting. It includes diagnostic steps and the information to provide when contacting Support, such as your organization ID, product surface, model, full error message, request ID, timestamp and time zone, screenshot when applicable, and a brief redacted description of the task.

To open a Support request, see: How can I contact support?

Start the first workflow

For most teams, the first workflow should start in the Codex Security plugin with a narrow repository, branch, or alert scope. Codex CLI is the scaled-automation path when the workflow owners already have a trusted CI/CD workflow you need to validate.

Correct a workspace or API organization mismatch

Use this path when the approved setup points to the wrong organization, the submitted organization is not internal-only, access needs to move between API and workspace paths, or a rollback/removal is pending.

Pause testing on the mismatched workspace or API organization.
Identify the current setup that was submitted or provisioned.
Identify the intended internal-only workspace, API organization, or both.
Confirm whether the old setup should be removed, rolled back, or left unchanged.
Send the details below to your OpenAI account team as a correction request.
Wait for OpenAI to confirm the correction is complete.
Re-run the proof-of-access check on the corrected setup.

Include:

company name and primary technical or workspace admin contact
current workspace or API organization name and ID, if known
intended internal-only workspace or API organization name and ID, if known
confirmation that the intended setup is not used for customer-facing applications, third-party traffic, or downstream product workflows
whether access should be removed or rolled back from the previous setup
whether the new setup creates a billing, budget-limit, or commercial-owner question
the first workflow the team plans to run and the expected workflow runners
timing constraints or upcoming enablement session, if any

If an old organization is still pending removal or a swap is pending, treat the corrected setup as not ready until OpenAI confirms the change is complete.

Note on Usage

Any workspace or API organization enabled for Trusted Access should be internal-only. Internal-only means the access is used by your own authorized team for your organization's defensive work and is not tied to customer-facing traffic, externally offered security services, or any downstream product feature that passes third-party requests or content through this access.

Zero Data Retention (ZDR)

Trusted Access provisioning does not automatically enable Zero Data Retention (ZDR). ZDR must be requested and provisioned separately for the exact organization. If your organization requires ZDR or another specific data-retention treatment, confirm that the organization you plan to use is covered by those terms before your team starts the first workflow.

Operating boundaries

Use the provisioned setup only for authorized defensive work.
Use systems your organization owns or is explicitly authorized to assess.
Keep the first workflow narrow and reviewable.
Keep humans in the loop for high-impact findings and remediation.
Use the workspace, API setup, and model access listed in your onboarding details.
Do not extend Trusted Access capabilities to third-party customers, external users, or downstream product workflows.

Enterprise Daybreak onboarding