Daybreak and Project Glasswing integration research

Checked against provider documentation on 2026-10-25. This is an implementation reference for pentest-mcp, not evidence that any operator, API project, workspace, or client engagement has been granted access. Each provider checks access independently. A successful CLI sign-in or API key alone does not establish the right program grant.

What this checkout has exercised: The managed Pentest MCP path ran gpt-daybreak-blue-latest at xhigh in an isolated assessment container against the explicitly authorized local Faxbot loopback health endpoint. The model discovered the MCP catalog, invoked real Nmap and ProjectDiscovery HTTPX through Pentest MCP, received a real scope denial for a malformed research-note target, imported 40 worker records, and returned a complete used/skipped coverage table. A separate Daybreak container with a separate home/work directory and no assessment MCP produced a report-evidence-v4 draft from six bounded evidence records with four cited observations and zero candidate findings. Local Codex and Claude CLI assessment profiles now work without an API key; OpenAI and Anthropic API profiles remain report-only. SSH assessment remains disabled until remote scope seeding and evidence import exist. Daybreak access remains optional: local-agent can use ordinary local Codex or Claude, while approved-provider records the separate external-provider route. Managed assessment and real acceptance

Provider programs and usable interfaces

Route	Verified interface	Access boundary	What to record in an engagement
OpenAI Responses API	POST /v1/responses with model and access_programs.cyber	OpenAI approval and provisioning for the specific identity/service, workspace or API organization and project, model, and surface	Organization/project identifier, model requested and returned, requested and returned access_programs.cyber, request ID, timestamp, evidence IDs, token usage, errors. Never log the bearer token.
Codex CLI	codex exec supports noninteractive runs, JSONL events, and JSON Schema final output	Uses the approved Codex identity and product surface. Daybreak access is not implied by choosing a model name.	CLI version, selected model and access status, sandbox/permissions, command arguments after secret redaction, exit status, event/turn IDs, final output digest.
Codex Security CLI	npx @openai/codex-security scan supports repo/path/diff/working-tree targets, --knowledge-base, scan prompts, saved findings and coverage, JSON and SARIF export	Codex Security access; Daybreak capability depends on the approved account/project and provider. Local scans run with the operator's OS permissions and do not pause for approval.	Scan manifest, repository revision, target paths, scope document hash, coverage, findings, validation state, run status, CLI/package version, and exported artifact hashes.
OpenAI models on Amazon Bedrock	Codex Security CLI --provider amazon-bedrock --model ... with AWS credentials	Separate Daybreak approval, AWS provisioning, region/model permission; Red's gpt-5.6-cyber additionally needs separate US government approval	AWS account/profile reference (no credentials), region, Bedrock model ID, access failure if any, scan artifact hashes.
Claude Code CLI	claude -p with --model, --output-format json or stream-json, optional --json-schema	CVP grant for the specific approved person/workspace/provider, plus the corresponding authorized work.	Session ID, model ID, tier, workspace, tool permissions, input/evidence hash, result and structured output, usage/cost metadata, exit status.
Claude API / provider platforms	Claude Messages API with a verified model ID; Claude Mythos 5.1 is claude-mythos-5-1 on the Claude API, Google Cloud, and Microsoft Foundry, and anthropic.claude-mythos-5-1 on Bedrock	Anthropic CVP grant and workspace assignment; Bedrock CVP currently requires eligibility for Enterprise Frontier Safeguards	Provider, model ID, workspace/grant, request ID, usage, output provenance, error or safety intervention.

Sources: OpenAI Daybreak API guide, OpenAI Models and Trusted Access, Codex noninteractive mode, Codex Security CLI reference, Claude Code programmatic use, Claude Code CLI reference, Claude Mythos 5.1 model page, Anthropic CVP Help Center.

OpenAI Daybreak details

Verified. Daybreak Blue and Red are access programs, not a generic entitlement granted by placing “Daybreak” in a prompt. For the Responses API, access_programs.cyber can be standard, daybreak_blue, or daybreak_red. The API project must be enabled for both the program and model. An explicit incompatible selection or missing grant fails. The response can report the selected program; capture that returned value instead of inferring treatment from the request. Daybreak API guide

Model request	Program request	Documented requirement
gpt-6-sol	daybreak_blue	Daybreak Blue organizational and project access plus model access.
gpt-6.1-sol or gpt-6-astra	daybreak_blue	Daybreak Red approval and project enablement for reduced refusals, despite the daybreak_blue request value. Both models reject daybreak_red.
gpt-5.6-cyber	daybreak_red	Daybreak Red organizational and project access plus model access.

The documented errors are 400 invalid_access_program, 400 unsupported_access_program, and 403 access_program_not_enabled. Preserve these as access failures in the log; do not silently retry with a different program or claim a Daybreak run occurred. The OpenAI API's -latest aliases can resolve to a different model, so record the response model. Daybreak API guide

Verified, material client boundary. OpenAI says enterprise Daybreak access is for the approved organization's authorized internal work and should not be extended to external clients, third-party customer systems, or downstream products without clarification with the OpenAI representative. This must be a provider-grant check before a Faxbot or other client scope is sent to Daybreak when Faxbot is not the approved organization's own internal system. Approval is tied to the approved identity, workspace or API organization/project, model, and product surface. Daybreak does not automatically include Zero Data Retention. Models and Trusted Access

Verified. Codex Security CLI supports local evidence artifacts such as scan-manifest.json, findings.json, coverage.json, and report.md; a completed scan's 0 exit code does not establish full coverage. --knowledge-base accepts architecture/policy documents, and --scan-prompt-file can focus the scan. export emits CSV, JSON, or SARIF; exported reports can contain source excerpts and vulnerability details. The CLI's MCP mode exposes only read-only metadata (info), so a pentest-mcp integration must invoke the CLI itself rather than expect a scan MCP tool. Quickstart, CLI reference

Verified Bedrock exception. The Codex Security CLI reference documents openai.gpt-daybreak-blue-5.6-sol and openai.gpt-5.6-cyber in us-east-2 on Amazon Bedrock. The latter requires separate U.S. government approval even after Daybreak Red approval. The documented Bedrock support version 0.1.31 lacks cost estimates and --max-cost for these models. Verify the installed CLI's --help and version before selecting flags; current CI guidance also documents a separate --cyber-access-program flag for direct OpenAI-provider scans. Codex Security CLI reference, CI guidance

Verified. OpenAI's recommended configuration calls for approved targets, actions, time limits, independent filesystem/network controls, action review, isolated testing, credential protection, and audit logs. Codex Auto-review does not automatically protect custom MCP tools or external harnesses; pentest-mcp must enforce the engagement scope itself at each tool boundary. Recommended configuration

Not established by these sources. gpt-daybreak-blue-latest appears in some Codex-host model inventories, but the cited public Daybreak API guide does not document it as a portable Responses API ID. Do not use it as the default for an external API adapter. An account's Daybreak toggle or access to gpt-6.1-sol also does not prove that a particular unattended codex exec invocation received Daybreak treatment. The run should log a provider-reported program value where available or mark program status unverified.

Project Glasswing / Anthropic CVP details

Verified. On October 6, 2026 Anthropic integrated Project Glasswing into the expanded Cyber Verification Program (CVP). Existing Glasswing members transition to Specialized Access for current models; the other tiers are Defense Access and Red Team Access. Defense covers vulnerability analysis, incident response, and malware analysis; Red Team adds authorized penetration testing and red teaming; Specialized is reserved for a limited set of organizations testing particularly consequential systems. CVP models include Claude Opus 5.5, Sonnet 5.5, and Mythos 5.1, subject to grant/provisioning. Anthropic CVP announcement, CVP Help Center

Verified. Individual applicants can receive Defense Access only. Red Team and Specialized are organization tiers. CVP can be used through first-party Claude/Claude Code/API, Google Cloud, and Microsoft Foundry; Bedrock CVP is currently limited to customers eligible for Enterprise Frontier Safeguards. Anthropic grants must be assigned to the relevant Console workspaces for API traffic. Third-party platforms support Defense and Red Team grants only, not Specialized. CVP Help Center, workspace grant assignment

Verified, material client boundary. A CVP grant covers security work on the grant holder's own code/products/infrastructure. Customer-owned systems or code and customer deliverables require separate managed-service approval for each offering. Anthropic says customer-facing products are not yet open for applications; a product where the customer triggers or configures a scanner is a separate category from a managed service where only approved staff operate the model and the client receives finished deliverables. The product should require an explicit “provider permits client work” attestation per engagement and should not represent a basic CVP/Glasswing grant as authorization for arbitrary client reports. CVP Help Center: Building client-facing products

Verified credential and infrastructure requirements. CVP Defense currently permits an interim API key only if kept in a secrets/password manager, assigned to one identity or workload, and rotated at least every seven days; by December 15, 2026 it requires phishing-resistant MFA and short-lived identity credentials, with static API keys disallowed. Red Team and Specialized already require short-lived credentials and phishing-resistant MFA. Agentic offensive work under Red Team or Specialized requires an outbound allowlist enforced off the host and logged. The tiers also prescribe incident reporting, access attribution, credential revocation, and controls for gateways. Accordingly, “set ANTHROPIC_API_KEY” alone is inadequate Glasswing setup guidance. CVP Security Requirements

Verified CLI behavior. claude -p is noninteractive. --output-format json includes result/session/usage metadata, --output-format stream-json provides events, and --json-schema returns a structured_output field when available. A denied or failed run may omit structured_output, so validate it before use. --bare avoids loading project hooks/plugins/MCP servers but also does not use subscription OAuth or keychain auth; it expects provider credentials or an apiKeyHelper. For a Glasswing/CVP run, choose the authentication method permitted by the grant and security tier, and do not accidentally load untrusted project hooks in unattended runs. Claude Code programmatic use, CLI reference

Verified model ID. claude-mythos-5-1 is the Claude API ID, and anthropic.claude-mythos-5-1 is the Bedrock ID. Anthropic lists the model as active with verification required. A reachable model API and CVP tier approval should be tested in the operator's own account; this research does not prove access for this machine or engagement. Mythos 5.1 model page

Product behavior and remaining provider work

Pentest MCP now implements the separate scope/provider policies, fixed profiles, durable MCP receipts, evidence-bound report drafts, analyst publication gate, and server-side scope enforcement below. Native OpenAI and Anthropic API tool loops, provider-side grant verification, off-host egress enforcement, and short-lived credential automation remain deployment work.

1. Separate target authorization from provider entitlement. Require a signed client scope with authorized owner, target inventory, test windows, prohibited actions, data handling, and stop contacts. Add a distinct provider grant record: program/tier, identity/workspace/project, permitted customer-service use, permitted model/surface, expiration or recheck date. A model cannot expand the target scope.
2. Use provider-specific adapters. Responses API adapter should explicitly request and verify access_programs.cyber; Codex CLI adapter should capture JSONL events and a schema-bound final output; Claude CLI adapter should capture JSON or stream JSON and reject absent structured_output. For remote SSH execution, use a pinned host/profile and fixed argv from configuration, preserve the same identity and scope constraints remotely, and never pass credentials as shell arguments.
3. Make scope context useful to security agents. Generate a narrow, human-reviewed scope packet from the engagement registry and pass it as Codex Security --knowledge-base plus scan instructions where available. Include target paths and exclusions, architecture, trust boundaries, data classes, test limits, and report audience. A repo scan should resolve and log the exact commit, working-tree state, and paths.
4. Record every boundary crossing. Append an event for model invocation, tool proposal, scope decision, human approval, execution start/end, cancellation, imported result, triage decision, finding validation, report revision, and export. Each event should include actor, engagement ID, UTC time, correlation ID, target, action, scope version/hash, provider/model/program, input/output artifact hashes, exit/error status, and redaction marker. Store independent logs outside the agent-controlled workspace when possible.
5. Treat model findings as candidates. Preserve source excerpt or scanner artifact, affected component, preconditions, reproduction status, impact, uncertainty, and reviewer decision. Do not promote an LLM assertion to a confirmed vulnerability or omit coverage gaps because a scan exited 0. Keep the source output and edited report distinct.
6. Draft reports from an evidence ledger. Generate executive and technical sections with citations to stable evidence IDs, target/revision metadata, testing limits, validation method, risk rationale, remediation, and retest state. A human reviewer signs off on findings and final client wording. Reports must state where testing did not occur.
7. Enforce limits outside prompts. The MCP server should reject out-of-scope targets and times, use scoped network egress, constrain agent tool permissions, and fail closed if the audit sink or provider-grant check fails. For Red Team/Specialized CVP, on-host-only egress controls are insufficient for agentic offensive work according to Anthropic's requirements.

Practical smoke tests for implementers

Use a fixture repository and fake provider responses before any real client target. Verify that a denied target, expired window, missing provider grant, model/program mismatch, absent structured_output, interrupted CLI run, and missing audit sink each fail without creating a confirmed finding. Then run one authorized, non-disruptive local scope through evidence import, model draft, human validation, and JSON/Markdown export; compare each report citation to its stored evidence. A real provider smoke test requires the operator's approved identity and the exact approved product surface. OpenAI recommended configuration, Codex Security CLI quickstart, Anthropic CVP requirements