What changed
A group of bitcoin and crypto companies, coordinated by the Bitcoin Policy Institute, has asked major AI labs to open their advanced-model security programs to open-source defenders.
The signatories include large crypto firms, infrastructure providers, wallet companies, and nonprofit developer funds. Their shared concern is that the people maintaining important bitcoin software often cannot get into the same trusted testing channels that labs reserve for select security partners.
That matters because bitcoin infrastructure is not a toy app with a broken dark mode. It underpins systems handling very large amounts of value, and small software flaws can have expensive consequences.
The core complaint
The complaint is not that AI labs are being too cautious. It is that caution is landing unevenly.
When open-source security researchers use public models, safety filters can block prompts that look too much like malware development or offensive security work. Those same prompts may be exactly what defenders need to find a vulnerability before someone else does.
So defenders get throttled. Attackers, meanwhile, are less likely to care about guardrails, policy, or proper onboarding.
Why crypto firms think the balance is off
The letter’s argument rests on an awkward truth: offensive capability does not stay neatly inside a lab.
Even if the strongest models are restricted at first, useful attack knowledge can still spread through public releases, open-weight models, stolen access, or custom-built tooling. By the time defenders are allowed in, the advantage may already be gone.
From the crypto side, this creates a lopsided setup:
- Labs and a limited group of partners may see new offensive capabilities early
- Open-source maintainers often cannot
- Publicly available models may be weaker or more constrained
- Attackers can mix whatever tools they can get
That is not a recipe for calm sleep.
What the firms are asking for
The request is fairly practical. The signatories want access that actually lets defenders test serious systems, not just poke around for five minutes and call it research.
They are asking for:
- Early access to the strongest cyber-capable models, including before broad public release
- Enough compute budget to do meaningful security review
- Secure environments for testing private code
- Access paths for small and independent maintainers, not only large companies
- Direct communication channels with lab security teams
That last point matters more than it sounds. If a researcher finds something dangerous, a fast line to the right people beats shouting into a support inbox.
Why this is landing now
The timing appears intentional.
Recent incidents helped make the case that crypto infrastructure is not dealing with abstract risk. A critical flaw disclosed by BTCPay Server had already been exploited to drain Lightning nodes tied to merchants. Foundation, a hardware wallet maker and also a signatory, reportedly lost its own node in that same attack chain.
That gives the debate a sharper edge. This is no longer just “AI might help security someday.” It is closer to “the attack surface is moving, and defenders want better flashlights.”
AI is already being used for vulnerability hunting
One of the more interesting details here is that defenders are already testing the thesis in the wild.
A volunteer effort calling itself the Bitcoin Red Team has reportedly been using AI models to examine bitcoin-related codebases and file large numbers of findings across many projects. The flaw that led to BTCPay’s patch was found by defenders, which strengthens the argument that AI can speed up legitimate vulnerability research, not just attacks.
This is the real tension behind the story: the same capability that can help someone write an exploit can also help someone catch one earlier.
The bigger issue for AI labs
This is not only a crypto story. It is a policy design problem for AI labs.
If access programs are too narrow, the defenders of important open-source infrastructure may be excluded simply because they are not part of a large commercial security team. But a lot of critical software is maintained exactly that way: by small groups, nonprofits, and independent contributors.
That creates a strange mismatch. The software can be globally important, while the people protecting it may not fit the access template.
What to watch next
The useful question is not whether AI should be allowed into security work. It already is.
The real question is who gets the better version first, under what conditions, and with what safeguards. If labs expand access, they will need to balance model misuse risk against a pretty convincing counterpoint: defenders cannot secure high-value infrastructure with downgraded tools forever.
Takeaway
For AI adopters, this is a sharp reminder that access policy can become a security issue, not just a product decision.
If your business depends on open-source infrastructure, watch how AI labs handle vetted defensive access. The firms making this request are essentially saying: if attackers are already in the age of AI-assisted offense, defenders should not be stuck reading the manual for last year’s model.
Comments (0) No comments yet
Want to join this discussion? Login or Register.
No comments yet. Be the first to share your thoughts!