The Watch

The Provenance Gap You Didn't Know You Had

OpenAI's Daybreak program has crossed a threshold that demands immediate attention: it is now generating closed-loop security patches at industrial scale — 30M+ commits scanned, 30K+ codebases analyzed, 70K reviewer-confirmed fixes, and 500K auto-detected issues patched — into projects that sit in virtually every enterprise software bill of materials.

The affected projects are not obscure: cURL, Go runtime, CPython, Sigstore, and pyca/cryptography. These libraries underpin TLS, code signing, package verification, and cryptographic operations across your stack. AI-authored commits are landing in them today.

This is not a supply-chain attack. It's worse — it's legitimate code from a non-human author flowing through your dependency tree with no provenance distinction.

Why Your Current Controls Miss This

Three layers of defense fail simultaneously:

• SCA tooling (Snyk, Dependabot, Grype) tracks CVEs and license metadata — not commit authorship provenance. There is no flag for "AI-generated upstream patch."
• SLSA attestations verify build integrity but have no field for distinguishing human-authored from AI-authored source contributions.
• Code review policies apply to your repos, not to upstream commits already merged by maintainers who accepted Daybreak PRs.

The Dual-Use Symmetry Problem

The same model class powering Daybreak's defensive patches — fixing memory safety bugs, catching crypto misuse — can by construction identify exploitable variants of those same bugs. OpenAI's GPT-5.5-Cyber claiming CyberGym SOTA makes this explicit rather than theoretical. The patch-generation pipeline and the exploit-generation pipeline share architecture, training data, and capability.

What To Do Now

Your auditors will ask about AI-authored code provenance within two quarters. Programs that move now control the narrative rather than reacting to it.

1. Inventory your dependency on the five named libraries. Map which services and pipelines consume them.
2. Implement commit-attribution monitoring: Daybreak PRs carry attribution metadata. Surface it in your dependency review dashboards.
3. Require 2-human sign-off on any Daybreak-tagged change merged into forks or vendored copies of critical-path libraries (crypto, TLS, identity).
4. Draft a position on AI-authored upstream code for your next audit cycle. Frame it as a SLSA provenance extension.

Cross-Source Corroboration: A New Concentration Point

Two independent intelligence streams today confirm the same structural shift: SpaceX Colossus 2 has quietly become a foundational compute substrate for the AI ecosystem. The customer list is striking in its concentration:

The total approaches $28B/yr in annualized compute revenue, funded in part by a $20B bond issuance this week. For context, this positions SpaceX alongside AWS, Azure, and GCP as a fourth major AI compute provider — but with no published SOC 2 history, no security pedigree documentation, and no sub-processor disclosure obligations in most current customer MSAs.

Your Anthropic or Google AI contract may now traverse SpaceX infrastructure without triggering any notification clause in your current agreement.

The Cursor Acquisition Changes Developer Security Posture

SpaceX acquiring Cursor creates an immediate concern for any engineering team using the tool. Developer prompts, code context, and repository contents flowing through Cursor now route to a SpaceX subsidiary running on SpaceX infrastructure. This is vertical concentration — the compute provider owns the application — with no SOC 2 history on either layer.

The 90-Day Volatility Factor

Both sources flag the 90-day out clauses. SpaceX is a newly public company that reportedly shed $600B in value over three days. Vendor financial stability and compute continuity are non-trivial questions. If SpaceX exercises an exit clause against a customer, your AI vendor's inference capacity could degrade within a quarter.

TPRM Response

Most third-party risk management questionnaires ask about primary cloud providers. Almost none ask about Tier-2 compute sub-processors. This gap is now material.

The Polymarket Case: Anatomy of a Kit-as-a-Service Campaign

The Wall Street Journal documented a working brand-impersonation operation against Polymarket. It reads as a template for attacks against any brand with a lowercase 'l' in its domain. The mechanism is trivial. Swap 'l' (lowercase L) for 'I' (uppercase I). In sans-serif fonts, which dominate email clients and browsers, the two characters are visually identical.

The reason this matters beyond one phishing domain is the operational stack underneath it:

• Homoglyph domain registration (T1583.001). The 'l' to 'I' swap.
• Paid sockpuppet amplification. 'Clipper' networks paid only when posts hit 60%+ US audience.
• Fabricated social proof. Operators claimed roughly $900K in winnings against actual exposure of about $166K in losses.
• Wallet-connect phishing. Credential capture via a legitimate-looking authorization prompt.

The kit is rented. Operators don't write it. Blocking Polymarket lookalike domains addresses one campaign. The kit resurfaces under another brand within days.

Why Brand-String Blocklists Fail

Detection teams commonly maintain lists of known brand impersonation domains. That approach catches the current campaign and misses the next one. The durable detection signals are these:

1. Kit signatures. HTML structure, JavaScript fingerprints, drainer wallet addresses.
2. Homoglyph pattern detection. Algorithmic scanning for confusable character substitutions across every domain in the portfolio.
3. Clipper network behavioral patterns. Coordinated amplification from accounts with specific age, follower, and engagement ratios.

Immediate Defensive Check

If the brand protection team cannot produce a homoglyph monitoring report for the primary domains within one hour, that is the gap. Run dnstwist or equivalent against the top 10 domains, explicitly testing 'l' ↔ 'I', 'rn' ↔ 'm', '0' ↔ 'O', and Cyrillic lookalikes. Register or file takedowns on high-risk variants resolving to live infrastructure.