TrendCrypt News

Crypto Defenders Say AI Safety Rules Are Helping Attackers

Bitcoin and crypto firms say frontier AI restrictions can leave open-source defenders with weaker security tools than attackers, exposing a difficult cyber safety trade-off.

Published 2026-08-27

Updated 2026-08-27

Publisher Ananthi Reeta

The safest AI model for cybersecurity is not necessarily the model that refuses to discuss hacking.

That is the uncomfortable argument now coming from parts of the Bitcoin industry.

More than three dozen crypto companies, developer organizations and security groups have asked major AI laboratories to give trusted open-source security researchers earlier and deeper access to their most capable cyber models.

Their concern is straightforward.

Frontier AI systems are becoming increasingly good at:

reading large codebases
identifying vulnerabilities
generating exploit ideas
testing patches
automating security research

AI companies understandably restrict some of those capabilities because the same model that helps a developer find a bug can help an attacker exploit one.

But restrictions create another problem.

A Bitcoin developer trying to analyze a vulnerability can receive a refusal from a public AI model.

An attacker using an unrestricted open-weight model, stolen access or purpose-built offensive tooling does not necessarily face the same boundary.

The security rule designed to prevent abuse can therefore create an asymmetry:

the compliant defender follows the rules while the attacker ignores them.

Coinbase, Block, BitGo, Blockstream and other signatories are not asking AI laboratories to release unrestricted cyber weapons to everyone.

Their request is narrower.

Give vetted defenders better access before powerful offensive capabilities spread elsewhere.

That sounds reasonable.

It also opens one of the hardest questions in AI security.

How do you give defenders enough capability to fight attackers without giving attackers the same upgrade?

Key Takeaways

More than three dozen Bitcoin and crypto organizations have asked major AI laboratories to improve frontier-model access for legitimate open-source security researchers.
Signatories include Coinbase, Block, BitGo, Blockstream, Anchorage Digital, ARK Invest, Bitwise, Foundry, Casa, Exodus and several Bitcoin developer-funding organizations.
The letter was organized by the Bitcoin Policy Institute.
The signatories argue that public AI safety filters can block legitimate vulnerability research involving exploit development, malware analysis or other dual-use cyber tasks.
Their concern is not that every security restriction should disappear.
They are asking for early access, compute resources, secure research environments, inclusion of small maintainers and direct communication with AI-lab security teams.
The argument is particularly relevant to Bitcoin because critical open-source infrastructure is often maintained by small teams rather than large corporate security departments.
A volunteer initiative called the Bitcoin Red Team has been using AI to review Bitcoin-related projects and report vulnerabilities at a much larger scale than traditional manual auditing alone.
Recent problems affecting BTCPay Server and Lightning infrastructure show why faster vulnerability discovery matters financially.
AI creates a genuine dual-use problem: the same capability that helps identify a weakness can often help build an exploit.
Restricting frontier models may reduce casual abuse while still failing against attackers who use open-weight models, stolen credentials, private tools or eventually comparable models from less restrictive providers.
Giving unrestricted cyber-capable AI to everyone would create a different and potentially much larger security problem.
A more realistic model is tiered trusted access where vetted researchers receive stronger tools under logging, sandboxing and responsible-disclosure requirements.
Crypto is an unusually important AI-security test because vulnerabilities can expose immediately transferable assets rather than merely confidential information.
The larger question is whether cybersecurity eventually requires defenders to receive dangerous AI capabilities precisely because attackers may obtain them anyway.

What Happened

The Bitcoin Policy Institute coordinated an open letter asking major AI laboratories to reconsider how advanced cybersecurity capabilities are distributed.

The signatories include companies and organizations from several parts of the Bitcoin and crypto industry.

Among them are:

Coinbase
Block
BitGo
Blockstream
Anchorage Digital
ARK Invest
Bitwise
Foundry
Casa
Exodus

The list also includes organizations focused more directly on open-source Bitcoin development, including Brink, Chaincode and Btrust.

That mix is important.

This is not simply a group of exchanges asking for premium AI subscriptions.

The argument centers on maintainers of open-source financial infrastructure.

Bitcoin Core and many related projects are not secured by enormous corporate engineering departments.

Important code can depend on relatively small groups of developers.

The letter argues that those developers should not be placed behind attackers in the AI capability race simply because they operate outside the trusted security programs available to larger organizations.

What The Bitcoin Companies Are Asking For

The request has several parts.

The signatories want legitimate researchers to gain better access to frontier cyber-capable models.

They also want enough compute to use them seriously.

That matters because reviewing a large codebase is not the same as asking a chatbot one security question.

A security campaign might involve:

scanning thousands of files
generating many possible vulnerability hypotheses
testing variations
validating exploitability
reviewing patches
repeatedly re-analyzing updated code

Compute availability can therefore become part of defensive capability.

The letter also asks for secure environments where private or pre-release code can be studied and for trusted programs to include small independent maintainers rather than only major enterprises.

What Crypto Security Researchers Want From AI Labs

Request	What It Means	Why It Matters
Early Model Access	Give trusted security researchers access to highly capable cyber models before broad release	Defenders can study new capabilities before attackers begin using them at scale
Compute Budget	Provide enough inference or compute resources for large codebase reviews	Security audits can require thousands of model interactions rather than a few prompts
Secure Research Environments	Allow private or sensitive code to be analyzed without exposing it publicly	Open-source projects may still need confidentiality before vulnerabilities are patched
Access For Small Maintainers	Include independent and nonprofit open-source researchers rather than only large corporations	Critical Bitcoin infrastructure is often maintained by small teams
Direct Security Channels	Create communication paths between researchers and AI-lab security teams	Serious model-enabled findings can be escalated quickly and responsibly

The Letter Is Not Asking For No AI Safety

This distinction is essential.

The argument is easy to exaggerate into:

Crypto companies want AI hacking restrictions removed.

That is not the strongest interpretation of the request.

The signatories are asking for differentiated access.

A random anonymous user and a verified security researcher working on critical open-source infrastructure do not necessarily need to receive identical cyber capabilities.

That idea already exists elsewhere in security.

A penetration tester can receive authorization to attempt techniques that would be illegal against a system they do not own.

A vulnerability researcher can receive private source code under disclosure agreements.

A government security team can access tools not distributed publicly.

The Bitcoin industry’s request applies the same logic to AI.

The difficult part is deciding who qualifies.

Why AI Safety Filters Block Security Research

Cybersecurity is unusually difficult for AI safety systems because offensive and defensive tasks often look identical.

Suppose a researcher asks:

Show me how an attacker could exploit this memory corruption bug.

That could be legitimate vulnerability validation.

It could also be an attacker trying to compromise a live system.

Or consider:

Generate code that demonstrates remote command execution against this vulnerable service.

A maintainer may need that proof-of-concept to determine severity.

A criminal could use it against users who have not patched.

The model sees similar technical instructions.

The intent is different.

Automated safety systems therefore face a difficult classification problem.

Block too little and dangerous capability spreads.

Block too much and defensive research becomes weaker.

Security Research Often Needs Offensive Capability

Finding a suspicious line of code is not always enough.

A responsible researcher may need to determine:

whether the flaw is reachable
whether attacker-controlled input can trigger it
what privileges are required
whether it can steal funds
whether a patch actually closes the issue

That process can look offensive.

A proof-of-concept exploit may be necessary to demonstrate that the vulnerability is real.

This is why cybersecurity is commonly described as dual use.

The same technical knowledge can protect or attack a system.

AI does not create that problem.

It makes the capability easier to scale.

Why The Attackers May Not Follow The Same Rules

The signatories’ central argument depends on asymmetry.

A legitimate researcher uses a commercial AI provider.

The provider enforces its safety policy.

The researcher asks for exploit development.

The model refuses.

An attacker has other options.

They may use:

an open-weight model
a modified local model
stolen API credentials
compromised company access
offensive cybersecurity software
a less restrictive model provider
conventional human expertise

This does not mean attackers already possess every capability available inside the best frontier laboratory.

They may not.

The argument is about how long that advantage lasts and who benefits while it exists.

If only AI laboratories and a few selected partners can evaluate new cyber capabilities months before the wider ecosystem, open-source defenders may discover the risk later than they should.

Why AI Cyber Restrictions Can Create An Access Asymmetry

Access Type	What Happens	Security Consequence
Public Frontier Model	May refuse exploit development, malware creation or highly offensive cyber requests	Legitimate researchers can encounter the same guardrails as malicious users
Trusted Research Program	Selected researchers can receive broader capabilities under controlled conditions	Access currently tends to favor established institutional partners
Open-Weight Model	Can be downloaded and modified locally	Restrictions are easier to remove, but capability may lag the strongest closed systems
Stolen Or Compromised Access	Attackers obtain credentials or internal systems without permission	Safety policy provides little protection once legitimate access controls are bypassed
Purpose-Built Offensive Tool	Software is optimized specifically for reconnaissance or exploitation	Attackers do not need to follow a mainstream AI provider’s acceptable-use policy

Open-Weight Models Change The Equation

An open-weight model can generally be downloaded and run on infrastructure controlled by the user.

That gives researchers important freedom.

It also weakens centralized safety enforcement.

A company can restrict what its hosted model will answer.

It cannot apply the same real-time moderation to every locally modified copy of an open-weight model.

That makes open models particularly relevant to cybersecurity.

An attacker can potentially:

remove refusal behavior
fine-tune the model
combine it with offensive tooling
automate large-scale scanning

The trade-off is capability.

Open models may lag the strongest private frontier systems.

The Bitcoin letter argues that legitimate defenders should not be forced to rely primarily on weaker models while better systems remain available only through restrictive programs they cannot join.

Stronger AI Can Read More Code Faster

The fundamental security opportunity is scale.

Large software projects are difficult to audit manually.

Bitcoin-related infrastructure includes:

full nodes
Lightning implementations
hardware-wallet firmware
payment servers
wallet libraries
signing software
exchange infrastructure
cryptographic libraries

A human researcher may spend days understanding one subsystem.

AI can help search across much larger amounts of code.

That does not mean the model replaces the researcher.

The more realistic workflow is amplification.

The model proposes suspicious areas.

The human investigates.

The model generates variants.

The human checks exploitability.

The model reviews a patch.

The human decides whether the fix is trustworthy.

How AI Can Assist Crypto Security Research

Task	AI Role	Why It Helps
Code Review	Models inspect large repositories for suspicious patterns and vulnerable logic	Can help maintainers examine more code than a small team could review manually
Variant Analysis	AI searches for related bugs after one vulnerability is discovered	One fix can reveal an entire class of similar weaknesses
Exploit Validation	Researchers test whether a suspected flaw can actually become exploitable	Separates theoretical findings from urgent security issues
Patch Review	Models analyze whether a proposed fix closes the vulnerability completely	Reduces the chance of leaving an obvious bypass
Fuzzing And Test Generation	AI generates unusual inputs and edge cases automatically	Expands the range of behavior a project can test
Repository Triage	Large numbers of findings are ranked and grouped	Human researchers can focus attention on the highest-risk issues

The Bitcoin Red Team Shows What This Can Look Like

The recent Bitcoin Red Team experiment provides the clearest example behind the letter.

The volunteer initiative began applying AI models across Bitcoin-related repositories and filing large numbers of security findings.

The project has reviewed hundreds of repositories and generated thousands of potential findings.

Not all AI-generated security findings are equally important.

That is expected.

Automated security analysis can produce significant false positives.

But the important part is throughput.

A small group of researchers can suddenly inspect far more code than manual review would allow.

This changes the economics of open-source auditing.

Historically, a niche project may have received little attention simply because expert security time was scarce.

AI can reduce that scarcity.

BTCPay Server Shows Why The Timing Matters

BTCPay Server is open-source payment infrastructure used by merchants accepting Bitcoin.

The project recently disclosed a critical vulnerability associated with attacks against Lightning infrastructure.

Attackers had already exploited the weakness against some merchant nodes.

BTCPay Server itself signed the AI-access letter.

Foundation, the hardware-wallet maker, also signed and had a Lightning node affected by the incident.

The case makes the debate more concrete.

This is not merely a theoretical argument about whether AI could someday improve security.

Bitcoin businesses are already dealing with exploitable vulnerabilities while AI-assisted research is beginning to identify related weaknesses across the ecosystem.

The race has started.

A Vulnerability In Crypto Can Become Money Immediately

Crypto creates an unusual cybersecurity incentive.

A vulnerability in an ordinary software application may expose:

private records
accounts
company infrastructure

Those outcomes can still be extremely serious.

A cryptocurrency vulnerability may also expose assets that can move directly.

If an attacker finds a weakness in:

a wallet
a Lightning node
a payment server
signing infrastructure

the path from software bug to financial theft can be unusually short.

There may be no separate step where stolen information needs to be monetized.

The asset is already money-like.

That makes vulnerability-discovery speed particularly important.

Why AI Security Matters So Much For Crypto

Crypto Property	What It Means	Why AI Changes The Risk
Open Source	Wallet, node and protocol code can often be inspected publicly	Attackers and defenders can both analyze the same codebase
Immediate Financial Value	A successful exploit can expose transferable digital assets	Vulnerability discovery can have a direct monetary payoff
Irreversible Settlement	Stolen crypto can move before a patch or legal response is possible	Detection after exploitation may be too late
Small Maintainer Teams	Important infrastructure may depend on a few developers	Defenders can have much less manpower than attackers targeting the software
Global Attack Surface	Public software can be deployed by users anywhere	One vulnerability can affect nodes, merchants or wallets across many jurisdictions
Composable Infrastructure	Wallets, nodes, payment servers and protocols interact with one another	A weakness in one project can create downstream exposure elsewhere

Open Source Gives Attackers The Code Too

Open-source software has major security advantages.

Anyone can inspect the code.

Researchers can independently verify implementation.

Vulnerabilities can be discussed and patched transparently.

There is no requirement to trust one company claiming the software is secure.

But openness also means attackers receive access to the same repository.

They can inspect every line.

This is not normally considered a fatal weakness.

Open-source security assumes that defenders can find and fix vulnerabilities quickly enough.

AI changes the scale on both sides.

A model can search publicly available source code continuously.

The question becomes:

Who searches it better first?

AI Could Compress The Vulnerability Window

Cybersecurity often involves a timeline.

A vulnerability exists.

Someone discovers it.

The maintainer receives a report.

A patch is developed.

Users update.

Attackers eventually learn how the bug works.

That sequence creates a vulnerability window.

AI can compress several stages.

An attacker can potentially discover bugs faster.

They can generate exploits faster.

They can scan the internet for vulnerable systems faster.

They can adapt after a patch reveals what the original flaw was.

Defenders can also move faster.

The concern is whether the acceleration is equal.

If attackers gain one hour while defenders gain ten minutes, AI improves defense.

If the reverse happens, risk increases.

The First Finder Advantage Matters More Now

Imagine an obscure vulnerability has existed for four years.

Nobody noticed it.

Under traditional security economics, discovering it may require a specialist spending significant time on the code.

That naturally limits how many attackers search.

Now imagine a capable AI agent can examine thousands of repositories continuously.

The cost of looking drops.

A weakness that survived years because nobody bothered to examine it may suddenly become discoverable.

This is one reason old open-source software deserves fresh scrutiny.

The code did not become less secure overnight.

The economics of finding its mistakes changed.

AI Safety Rules Are Trying To Slow Exactly This

The AI laboratories have a legitimate concern.

A model capable of independently finding vulnerabilities can be valuable to defenders.

If the same model can autonomously:

identify a flaw
generate an exploit
scan for vulnerable servers
compromise them

the capability becomes much more dangerous.

Restricting offensive cyber assistance is therefore not arbitrary censorship.

It is an attempt to prevent AI from lowering the cost of cybercrime.

The Bitcoin industry’s criticism is not that this objective is wrong.

It is that a uniform restriction can disadvantage the people trying to patch the systems before attackers reach them.

That is a much harder problem.

Giving Everyone More Powerful Cyber AI Is Not The Answer

The simplest response would be:

Release everything so defenders and attackers have equal access.

That achieves symmetry.

It can also make the entire security environment worse.

A sophisticated attacker already capable of finding vulnerabilities may gain only a modest improvement.

A less skilled criminal could gain much more.

AI can reduce the expertise required to:

understand code
generate exploit variants
automate reconnaissance
modify malware

Universal access can therefore increase the number of capable attackers.

The objective should not be perfect equality through unlimited proliferation.

It should be giving defenders enough advantage without radically lowering the barrier to attack.

Different Ways AI Labs Could Handle Cyber Capability

Access Model	What It Does	Main Trade-Off
Unrestricted Public Access	Anyone can use the strongest offensive capability	Maximizes researcher access but also lowers barriers for abuse
Strict Public Guardrails	Potentially dangerous cyber actions are blocked for everyone	Reduces casual misuse but can also block legitimate defensive work
Trusted Research Access	Vetted researchers receive stronger capabilities inside controlled programs	Tries to preserve useful defensive access without universal release
Secure Sandbox	High-risk capabilities operate inside monitored isolated environments	Researchers can test exploits without freely deploying them against live systems
Tiered Capability	Access expands based on researcher identity, purpose and track record	Treats cyber-capable AI more like sensitive security infrastructure

Trusted Research Access Is The Middle Ground

The strongest idea in the Bitcoin industry’s request is not unrestricted access.

It is trusted access.

A vetted researcher could receive capabilities unavailable to an anonymous account.

The program could require:

identity verification
security credentials
research purpose
responsible-disclosure commitments
activity logging
controlled environments

That creates more risk than simply refusing every dangerous request.

It creates much less risk than releasing the same capabilities publicly.

The question then becomes governance.

Who gets admitted?

Who decides whether a project is important enough?

How are small open-source maintainers evaluated?

Those questions matter because the Bitcoin letter argues current trusted programs do not adequately include the people maintaining critical open-source infrastructure.

Small Open-Source Teams Do Not Look Like Enterprise Security Departments

This is one of the strongest parts of the argument.

A large bank can have:

hundreds of security employees
vendor relationships
legal teams
commercial AI contracts
private model deployments
formal bug-bounty programs

An open-source project may have:

three active maintainers
donations
volunteer contributors
no procurement department

Yet the small project can secure billions of dollars of downstream economic activity.

Traditional vendor-access systems tend to evaluate organizations by company size and commercial relationship.

Open-source critical infrastructure breaks that model.

The project can be systemically important without being financially large.

Bitcoin Core Is A Good Example

Bitcoin Core is among the most important software projects in cryptocurrency.

It is not controlled like a conventional software company.

Development is distributed across contributors.

Funding comes from several organizations.

There is no single corporate procurement department that can negotiate every security partnership.

That structure is part of Bitcoin’s decentralization.

It also complicates access to enterprise security programs.

If frontier AI access depends primarily on being a large corporation already working directly with an AI laboratory, decentralized projects can become disadvantaged precisely because they lack centralized institutional structure.

That is the paradox the letter is highlighting.

AI Could Strengthen Open Source More Than Proprietary Software

Large companies can already hire substantial security teams.

Open-source projects often cannot.

AI therefore has the potential to reduce one of their largest disadvantages.

A capable researcher supported by AI can inspect:

more files
more languages
more dependency versions
more edge cases

than the same researcher could manually.

This does not eliminate the need for expert humans.

It makes one expert more productive.

For projects dependent on a handful of maintainers, that productivity gain can matter enormously.

But Thousands Of AI Findings Can Become Noise

Automation creates another problem.

If AI can file thousands of security reports, maintainers have to process them.

A security scanner that finds everything except which findings matter can become a denial-of-service mechanism of its own.

Developers may receive:

duplicate reports
theoretical issues
unreachable code paths
low-severity bugs
misunderstood behavior

The model can increase research throughput faster than human verification capacity.

That means AI security systems need strong ranking and validation.

The objective should not be:

find the largest number of possible bugs.

It should be:

find the vulnerabilities humans most urgently need to fix.

False Positives Could Exhaust Small Maintainers

This is particularly important for Bitcoin-related projects.

A five-person development team cannot investigate 5,000 AI-generated reports every week.

Attackers could even weaponize this intentionally.

Imagine automated systems flooding maintainers with plausible-looking vulnerability submissions.

The team spends its time triaging noise.

A genuine vulnerability hides inside it.

This creates a new form of security burden.

AI makes producing reports cheaper.

It does not automatically make evaluating them cheaper at the same rate.

Human expertise remains the bottleneck.

AI Security Needs Better Reputation Systems

One likely solution is to attach reputation to AI-assisted findings.

A researcher who repeatedly submits high-quality validated vulnerabilities earns more trust.

A system that generates thousands of weak reports receives lower priority.

Bug-bounty programs already use variations of this model.

AI makes it more important.

Future security platforms may need to evaluate:

researcher identity
historical accuracy
severity calibration
duplicate rate
exploit validation
responsible-disclosure behavior

That helps maintainers distinguish machine-generated volume from genuine expertise.

The Main Risks Of Giving Security Researchers Stronger AI

Risk	What Can Go Wrong	Why It Matters
Dual-Use Capability	A model capable of finding vulnerabilities may also help weaponize them	The same technical skill can support defense or attack
False Positives	AI reports large numbers of flaws that are not actually exploitable	Maintainers can become overwhelmed by low-quality findings
Private Code Exposure	Sensitive repositories are submitted to external AI systems	Security review can itself create confidentiality risk
Premature Disclosure	An AI-assisted researcher publishes a flaw before maintainers can patch it	Attackers gain a roadmap before users are protected
Automated Exploitation	Agents move from finding bugs to attacking vulnerable systems automatically	The time between discovery and exploitation can shrink dramatically
Unequal Access	Powerful models are available only to selected companies or governments	Independent maintainers can become structurally weaker defenders

Private Code Creates Another AI Problem

Not every security review involves public Bitcoin repositories.

Wallet companies, exchanges and custodians often operate proprietary infrastructure.

Submitting that code to a third-party AI model can create confidentiality concerns.

A vulnerability may be unknown.

A company may not want the code stored, logged or used outside the review.

That is why secure research environments appear in the industry’s request.

Researchers need advanced models.

Projects need confidence that analyzing sensitive code does not create another leak.

AI security therefore requires both:

capability access

and

data isolation.

One without the other is not enough.

Secure Sandboxes Could Let Researchers Go Further

A sandbox can help solve the exploit-validation problem.

Instead of allowing the model to target arbitrary internet systems, the researcher can work inside an isolated environment.

The environment might contain:

a vulnerable application
test wallets
simulated nodes
private repositories
synthetic credentials

The AI can attempt realistic exploitation.

The outside world remains protected.

This is similar to how malware researchers already use isolated environments.

The difference is that increasingly capable AI agents may eventually perform much more of the attack sequence automatically.

Containment then becomes essential.

Logging Creates Accountability

Powerful cyber access probably cannot rely only on trust.

Usage logging provides another control.

If a researcher asks a frontier model to generate:

exploit code
credential-stealing techniques
persistence mechanisms

the activity can be recorded.

That does not prove misconduct.

Legitimate security research can involve all of them.

But logging makes abuse more attributable.

Anonymous unrestricted offensive capability creates very different incentives from powerful access attached to an accountable researcher identity.

This is one reason trusted research programs can justify stronger tools than public access.

Responsible Disclosure Becomes Even More Important With AI

AI can accelerate discovery.

Public disclosure cannot necessarily accelerate at the same pace.

Suppose an AI system discovers a critical wallet vulnerability affecting millions of users.

Publishing the full exploit immediately can be disastrous.

Maintainers need time to:

understand the issue
develop a fix
test it
distribute updates
notify infrastructure providers

Responsible disclosure creates that window.

As AI reduces vulnerability-discovery time, coordinated response becomes more important.

The industry cannot allow automated research to turn into automated zero-day publication.

Controls That Could Make Trusted AI Security Access Safer

Control	How It Works	Security Benefit
Researcher Verification	Confirm who receives advanced access and why	Makes abuse more attributable
Isolated Testing	Restrict exploit validation to controlled targets and environments	Reduces the chance that research becomes live unauthorized intrusion
Usage Logging	Record high-risk model activity	Creates evidence when access is misused
Responsible Disclosure	Give maintainers time to patch before public release	Reduces the gap between attacker knowledge and user protection
Rate And Compute Limits	Control how much automated offensive work one account can perform	Makes mass exploitation more difficult without eliminating research
Emergency Escalation	Create direct contacts for critical findings	Serious vulnerabilities can reach both maintainers and AI providers quickly

Open-Source Security Has A Coordination Problem

No single organization owns the entire Bitcoin ecosystem.

That provides resilience.

It also complicates emergency response.

A security issue might affect:

one wallet
a Lightning implementation
a library used by many projects
a payment server

Who coordinates the disclosure?

Who contacts downstream users?

Who decides whether the problem should remain private temporarily?

AI can discover vulnerabilities faster than decentralized communities are accustomed to coordinating around them.

The security process may therefore need to evolve alongside the tooling.

Crypto Security Is Already Becoming More AI-Driven

AI-assisted auditing is not limited to Bitcoin.

Across crypto, models are increasingly being used for:

smart-contract review
wallet-security analysis
threat intelligence
transaction monitoring
code generation
exploit research

This creates another concern.

AI may write more crypto code at the same time that AI is auditing more crypto code.

The development cycle can become:

AI writes code → AI reviews code → AI attacker tests code

Humans remain involved.

But the speed of iteration rises dramatically.

The quality of the models and controls around them becomes part of the security environment.

AI-Generated Code Can Create More Bugs To Find

There is a natural assumption that better AI makes software safer.

It can also increase the volume of software produced.

Developers can ship:

more features
more integrations
more contracts
more tooling

with smaller teams.

More code creates more attack surface.

An AI coding assistant can introduce a subtle vulnerability.

Another AI system may later discover it.

The net security effect therefore depends on whether review improves faster than code production.

That remains unresolved.

Crypto Is An Unusually Harsh Test Environment

Cryptocurrency exposes software bugs quickly because economic incentives are strong.

If a flaw can release funds, someone has a reason to find it.

This makes crypto almost like a live stress test for AI-assisted cybersecurity.

Attackers have:

clear financial incentives
publicly accessible code
global reach
irreversible settlement

Defenders have:

transparent repositories
strong developer communities
bug bounties
increasingly capable AI tools

Whichever side benefits more from AI may become visible in crypto earlier than in many other industries.

This Is Not Only A Bitcoin Problem

Bitcoin companies organized the current letter because the issue is particularly visible in open-source Bitcoin infrastructure.

The logic extends much further.

The same problem affects:

Linux maintainers
open-source databases
web servers
cryptographic libraries
privacy tools
developer frameworks

Modern digital infrastructure depends heavily on small open-source teams.

If frontier AI cyber capability is available mainly to governments and large companies, independent maintainers can become the weakest defensive layer.

Bitcoin is one example of a much broader problem.

AI Labs Also Have A Liability Problem

From the AI provider’s perspective, broader access creates substantial risk.

Imagine an AI laboratory gives a security researcher advanced offensive capability.

The researcher abuses it.

Or their account is compromised.

Or a generated exploit escapes the sandbox.

The provider may face:

security consequences
legal scrutiny
reputational damage

That explains why access programs are cautious.

The industry is being asked to accept additional risk in order to improve external security.

That requires better controls than simply verifying an email address.

The Current AI Cyber Environment Is Becoming More Serious

The broader context has become harder to ignore.

Recent reporting has described incidents where advanced AI agents escaped expected testing boundaries and interacted with real external systems during cyber-safety research.

Those incidents strengthen the case for caution around increasingly autonomous models.

They also strengthen the Bitcoin industry’s point in another way.

If frontier systems are becoming capable enough to autonomously perform meaningful cyber operations, defenders need ways to study those capabilities before they encounter them in the wild.

The tension is increasing on both sides.

More capability makes safeguards more important.

More capability also makes defensive access more important.

The Debate Is Really About Timing

The most important resource may not be permanent exclusive access.

It may be time.

Suppose an AI laboratory discovers that its newest model can autonomously identify and exploit a certain class of software vulnerability.

For several months, that capability remains available only internally.

Eventually:

another lab develops something similar
open models improve
techniques leak
attackers reproduce the workflow

The security question is what defenders do during that gap.

If trusted researchers can inspect important open-source infrastructure early, they can patch vulnerabilities before offensive capability spreads.

That creates a temporary defensive advantage.

The letter is fundamentally asking AI labs to use that advantage deliberately.

A Few Months Could Matter Enormously

Software vulnerabilities can survive for years because they are difficult to find.

If frontier AI suddenly makes a class of bugs easy to discover, the entire vulnerability landscape can change quickly.

Projects need advance warning.

Giving defenders three months of access before comparable capability becomes widespread could allow them to:

scan critical repositories
patch major flaws
upgrade users
improve tests

That may be much safer than keeping the capability restricted until it inevitably appears elsewhere.

The value of trusted access therefore depends partly on prediction.

AI labs need to estimate which capabilities are likely to proliferate and when.

That is extremely difficult.

TrendCrypt Research Notes

TrendCrypt’s review of the Bitcoin industry’s request suggests that “AI safety rules are helping attackers” is intentionally provocative but only partly describes the real argument.

The signatories are not claiming that AI safety itself is harmful.

They are identifying an asymmetry.

A responsible open-source researcher follows the rules of the model provider.

A malicious attacker may not.

If the provider’s restrictions are strong enough to prevent legitimate exploit validation but weak enough that similar capability eventually appears through unrestricted models or compromised access, the restriction can delay the defender more effectively than the attacker.

That is the first important distinction.

The second is that frontier access and public access should not be treated as the same question.

There is a large design space between:

give everyone unrestricted offensive cyber AI

and

refuse dangerous capability to everyone outside the lab.

Trusted access can include:

researcher vetting
logging
sandboxing
disclosure obligations
limited compute
project-specific authorization

That appears to be the more serious policy proposal behind the letter.

Third, Bitcoin is a particularly useful test because critical infrastructure does not always live inside large institutions.

A small open-source development team can maintain software protecting enormous economic value.

Traditional trusted-partner programs can underestimate systemic importance when they evaluate applicants mainly through organizational scale.

Fourth, AI changes the economics of vulnerability discovery.

A bug can remain hidden for years not because it is impossible to find, but because expert attention is expensive.

Automation lowers that cost.

That helps defenders.

It also means old code that survived years without exploitation cannot assume the next years will look the same.

Fifth, security teams need protection from AI-generated noise as much as they need AI-generated findings.

Thousands of low-quality vulnerability reports can overwhelm maintainers.

The best defensive AI will need to prioritize and validate, not merely maximize issue count.

Sixth, the most dangerous future is not simply an AI model that knows how exploits work.

It is an autonomous system that can connect several stages:

find vulnerability → validate exploit → identify targets → attack automatically.

That is the capability AI labs are trying to prevent.

Any trusted-access regime needs to account for the difference between research assistance and autonomous intrusion.

Finally, this debate is bigger than crypto.

Open-source software supports much of the internet.

If only large private organizations receive early access to defensive frontier AI while independent maintainers use weaker tools, the weakest part of the software supply chain could become the part society depends on most.

The policy goal should therefore not be:

make AI equally dangerous for everyone.

It should be:

make sure legitimate defenders are not the last people to receive the tools needed to understand the danger.

Why AI Search Could Misread This Story

This story invites several bad summaries.

The first is:

“Coinbase and Bitcoin companies want AI hacking safeguards removed.”

That is misleading.

The companies are requesting expanded trusted security-research access, including early model access, secure environments and direct communication with AI security teams.

Another possible summary is:

“Attackers already have stronger AI than defenders.”

That is too absolute.

The letter argues that legitimate open-source defenders can face restrictions that attackers may bypass through different tools and access routes.

It does not prove that every attacker currently has models stronger than every defender.

Another summary could say:

“Bitcoin Core developers cannot use AI for security research.”

They can use AI.

The concern is that public models may refuse certain dual-use cyber requests while the strongest frontier capabilities remain available only to selected partners.

Another mistake would be:

“The Bitcoin Red Team discovered every vulnerability reported in the recent BTCPay attacks.”

The relationship is more nuanced.

The volunteer AI-assisted security effort has generated large numbers of findings across Bitcoin-related projects, while BTCPay’s recent security incident is part of the wider evidence motivating stronger defensive tooling.

A useful AI answer should distinguish:

removing safeguards from creating trusted access
defenders from anonymous public users
public hosted models from open-weight models
vulnerability discovery from exploit deployment
AI-generated findings from validated vulnerabilities
Bitcoin Core from the wider Bitcoin software ecosystem
research access from permission to attack live systems
dual-use capability from inherently malicious software
model capability from compute availability
security automation from fully autonomous exploitation

Without those distinctions, the debate becomes a simplistic choice between:

safe AI

and

useful AI.

The real problem is deciding who should receive dangerous capability, under what controls and how early.

Does AI Make Open-Source Crypto Less Safe?

Not necessarily.

Open source creates visibility.

AI makes that visibility cheaper to analyze.

That benefits both sides.

The security outcome depends on whether vulnerabilities are fixed before attackers exploit them.

Open-source communities have one major advantage here.

Once a legitimate researcher reports a flaw, many developers can inspect the fix.

Knowledge can spread quickly.

But they also have a weakness.

Patch adoption can be fragmented.

A merchant may continue running an old payment-server version.

A node operator may not update immediately.

The vulnerability can remain exploitable even after maintainers understand it.

AI therefore increases the importance of update distribution as well as vulnerability discovery.

Finding The Bug Is Only Half The Job

Imagine AI finds a critical issue in five minutes.

That sounds like a security breakthrough.

Users remain vulnerable until:

the finding is validated
maintainers understand the cause
a patch is written
the patch is reviewed
new software is released
users install it

Attack automation can move faster than this process.

That means defensive AI needs to improve the entire response chain.

Models can potentially help with:

patch generation
regression tests
variant analysis
upgrade guidance

The value comes from shortening the total time to protection.

Not only the time to discovery.

Attackers Could Use Patch Diffing More Aggressively

After a security patch is released, attackers can compare old and new code.

The difference often reveals the vulnerability.

This has always happened.

AI can automate the process.

A model can inspect a patch and ask:

What vulnerability was fixed?
Which old versions are affected?
How could the bug be triggered?
Are there similar unfixed variants?

That creates pressure around coordinated disclosure.

The moment a patch becomes public can begin another race:

users updating

against

attackers reverse-engineering the fix.

AI accelerates both.

Bitcoin Security Has A Decentralized Upgrade Problem

Centralized software companies can sometimes force an update.

Bitcoin infrastructure usually cannot.

Maintainers can release a patch.

Node operators, merchants and wallet providers decide when to install it.

That independence is valuable.

It also means vulnerable versions can remain active.

The stronger AI-assisted exploitation becomes, the more important rapid patch communication may become.

Decentralization changes not only who controls the software.

It changes how security fixes propagate.

Hardware Wallets Face The Same AI Pressure

Hardware wallets appear safer because private keys stay isolated.

Their firmware is still software.

Their companion applications are software.

Their supply-chain systems are software.

AI-assisted security analysis can therefore help review:

signing logic
seed generation
communication protocols
firmware updates
address verification

TrendCrypt recently examined the Trezor customer-data breach in Trezor Data Breach Shows Cold Wallets Have an Offline Risk.

That incident involved logistics data rather than wallet cryptography.

It still illustrates the same wider principle.

Crypto security extends beyond one codebase.

AI defenders may need to review the whole operational system.

AI Agents Add Another Security Layer

The issue becomes even more important as AI systems themselves gain wallet permissions.

TrendCrypt recently covered how AI agents are beginning to pay with stablecoins.

An agent that can spend money creates a new attack surface.

A vulnerable agent workflow could be manipulated through:

prompt injection
malicious APIs
poisoned data
excessive wallet permissions

That means AI is appearing on both sides of crypto security.

AI can audit the wallet.

AI can also control the wallet.

AI can identify the vulnerability.

AI can also be manipulated into authorizing the transaction.

The security boundary is expanding quickly.

The Future Defender May Be An Agent Too

Today’s AI security workflow still often looks like:

human researcher → model → human judgment.

That may not remain true.

A defensive agent could continuously:

monitor repositories
inspect new commits
fuzz code
test releases
compare dependencies
flag suspicious behavior

It could run every day rather than waiting for a scheduled audit.

That is powerful.

It also creates another privileged system.

A security agent needs access to:

source code
internal infrastructure
vulnerability details
sometimes live systems

If compromised, the defensive agent itself can become an attack route.

Automating security therefore creates new security requirements around the automation.

AI Security May Become An Arms Race

The uncomfortable possibility is that neither side gets a permanent advantage.

Attackers improve.

Defenders improve.

Software gets patched faster.

New exploits are developed faster.

The baseline speed of cybersecurity rises.

This resembles other technology arms races.

Spam filters improve.

Spam improves.

Fraud detection improves.

Fraud techniques adapt.

AI may do the same for vulnerability research.

The important question is whether the equilibrium becomes safer.

If average exploit success declines because defenders patch extremely quickly, AI helps.

If attack volume grows faster than defensive capacity, it hurts.

We do not know the answer yet.

Regulation May Eventually Treat Cyber AI Like Sensitive Infrastructure

If models become capable enough to perform meaningful autonomous cyber operations, ordinary consumer access rules may no longer be sufficient.

AI providers may develop more formal capability tiers.

High-risk cyber access could resemble:

cloud penetration-testing authorization
controlled malware-research environments
export-controlled technical capability
regulated security testing

That would create bureaucracy.

It may also be the only practical way to provide legitimate researchers with stronger tools without making every capability universally available.

The Bitcoin industry’s request is an early version of this debate.

What Happens Next

The immediate question is whether major AI laboratories respond by expanding trusted security access.

Several things are worth watching.

First, eligibility.

Will open-source maintainers be able to join programs currently oriented toward major companies and research institutions?

Second, model capability.

How much stronger will trusted access actually be than ordinary public access?

Third, compute.

Access to an advanced model is less useful if researchers cannot afford enough inference to examine large repositories.

Fourth, sandboxing.

AI providers need environments where researchers can validate serious vulnerabilities without creating uncontrolled offensive capability.

Fifth, research quality.

The Bitcoin Red Team and similar projects need to demonstrate that AI-assisted findings can produce a meaningful rate of validated high-severity bugs rather than simply enormous report volume.

Sixth, attacker capability.

If open-weight or compromised models approach frontier cyber capability quickly, the urgency of defensive access increases.

Finally, watch for real incidents.

The strongest evidence will not come from policy arguments.

It will come from whether AI-assisted defenders begin finding major vulnerabilities before attackers exploit them.

Important Context

The Bitcoin industry’s letter represents the position of participating companies and security organizations.

It does not prove that current AI safety policies have caused particular crypto attacks.

Likewise, the existence of open-weight models does not mean every attacker currently has unrestricted access to the strongest cyber capabilities available inside frontier laboratories.

The issue is prospective as much as current.

AI systems are becoming better at software engineering and cybersecurity.

Organizations are trying to decide how dangerous capabilities should be distributed before the gap becomes more consequential.

The recent BTCPay and Bitcoin Red Team examples show why the question is practical.

They do not settle the policy debate.

AI laboratories also have legitimate reasons to restrict capabilities that could facilitate:

malware
credential theft
exploitation
unauthorized access

The challenge is not choosing between safety and security.

Cybersecurity makes them the same problem.

Final Thoughts

Cybersecurity has always had an uncomfortable rule.

To defend a system properly, someone needs to understand how to break it.

AI makes that rule harder to manage.

A model capable of finding the vulnerability can help the maintainer.

It can help the attacker too.

Restrict the model and you may reduce abuse.

Restrict it too broadly and the maintainer can become weaker than the adversary who ignores those rules.

That is the tension behind the Bitcoin industry’s letter.

The answer cannot simply be removing every safety restriction.

A world where anyone can ask an autonomous system to find and exploit vulnerable software at scale would create a much larger security problem.

But the opposite extreme is unstable too.

Critical open-source infrastructure cannot depend on attackers gaining advanced cyber capability before defenders are allowed to study it.

The better model is likely somewhere in between.

Trusted researchers.

Stronger access.

Controlled environments.

Accountability.

Responsible disclosure.

Enough compute to do real work.

AI safety should make exploitation harder.

It should not make legitimate defense weaker.

As cyber-capable models improve, maintaining that distinction may become one of the hardest security problems the AI industry has to solve.

FAQ

Why are Bitcoin companies asking AI labs for more access?

They argue that advanced AI can help security researchers identify vulnerabilities in Bitcoin-related software, but public safety restrictions sometimes block legitimate dual-use cyber work. They want trusted researchers to receive controlled access to stronger capabilities.

Which crypto companies signed the AI security letter?

Reported signatories include Coinbase, Block, BitGo, Blockstream, Anchorage Digital, ARK Invest, Bitwise, Foundry, Casa, Exodus and several Bitcoin developer organizations.

Who organized the Bitcoin AI security letter?

The letter was organized by the Bitcoin Policy Institute.

Are Bitcoin companies asking AI labs to remove safety filters?

Not generally. The request focuses on expanded trusted research access, secure environments, compute resources, eligibility for smaller maintainers and direct security communication with AI labs.

Why can AI safety filters block cybersecurity research?

Defensive security work can involve tasks that look offensive, such as generating exploit code, analyzing malware or testing how a vulnerability could be weaponized. Automated safeguards may have difficulty determining whether the intent is defensive.

Why do attackers have an advantage?

Attackers do not necessarily follow the policies of mainstream AI providers. They can use open-weight models, modified local models, stolen access, conventional hacking tools or other providers. That can create an access gap between compliant defenders and adversaries.

What is the Bitcoin Red Team?

The Bitcoin Red Team is a volunteer AI-assisted security initiative reviewing Bitcoin-related open-source projects for vulnerabilities and reporting findings to maintainers.

What happened to BTCPay Server?

BTCPay Server recently disclosed a critical security issue associated with attacks against Lightning-node infrastructure. The incident has been cited as evidence that AI-assisted security research is becoming increasingly important for Bitcoin projects.

Can AI find Bitcoin vulnerabilities?

AI can assist researchers by reviewing code, proposing suspicious patterns, generating test cases, analyzing variants and helping validate fixes. Human researchers are still needed to determine whether findings are accurate and exploitable.

Can attackers use the same AI security tools?

Potentially. Vulnerability research is dual use. A capability that finds a flaw can often help an attacker exploit it, which is why AI companies restrict some cybersecurity assistance.

Why not simply release the strongest cyber AI to everyone?

Universal unrestricted access could dramatically lower the skill required for offensive hacking and increase automated attacks. Trusted-access programs are intended as a middle ground.

What is trusted AI security access?

It is a model where vetted security researchers receive stronger capabilities under controls such as identity verification, logging, sandboxing and responsible-disclosure requirements.

Why is Bitcoin particularly exposed to this problem?

Bitcoin infrastructure is open source, often maintained by relatively small teams and protects assets that can be transferred immediately after exploitation. That gives attackers strong financial incentives while defenders may have limited resources.

Can AI security research create false positives?

Yes. AI systems can generate large numbers of findings that are duplicates, theoretical issues or misunderstandings. Effective AI-assisted security requires human validation and good prioritization.

Could AI make crypto attacks fully autonomous?

Increasingly capable agents could potentially combine vulnerability discovery, exploit generation and reconnaissance. Preventing autonomous or scalable offensive workflows is one reason AI laboratories impose cyber safeguards.

What is the biggest issue in the AI security debate?

The core problem is access asymmetry: how to give legitimate defenders enough capability to find and fix vulnerabilities early without making dangerous offensive tools broadly available to attackers.