An AI-assisted security campaign focused on the Bitcoin ecosystem, known as Bitcoin Red Team, has announced the generation of 6,700 findings across 425 projects within its initial 55 hours of operation. This output demonstrates the sheer speed with which artificial intelligence can inundate security teams with potential issues that require verification and remediation.

Of the total findings, the campaign classified 1,029 as either high or critical in severity. However, an update provided on August 6 primarily quantifies the volume of material entering the security triage pipeline, with the resulting impact on software security yet to be reported.

Crucially, the published information lacked essential context, such as audit-ready definitions for severity counts, the total number of items from which those counts were derived, and specific outcomes for individual cases. Data on the aggregate false-positive rate and the fix rate were also absent. The omission of these fields makes it impossible to calculate how many alerts were confirmed as actual vulnerabilities, how many were rejected or downgraded by project maintainers, and how many resulted in software patches.

The Scale of the AI Scan

Despite the missing data, the first 55 hours of the campaign showcase a significant capability, highlighting how AI systems can rapidly fill an ecosystem-wide review pipeline. Human involvement, including expert prompting, reproduction of findings, responsible disclosure, and maintainer communication, remained indispensable at all subsequent stages.

The campaign released two progress snapshots as its scope and workload grew:

• An initial 27.5-hour update reported 4,962 findings across 390 projects.
• By the 55-hour mark, the number of projects had increased by 35, and the findings had grown by 1,738.

This later update noted that high-or-critical findings constituted 15.4% of the total. It also clarified that three of the 24 participants involved in the campaign were bots. While the earlier report distinguished between critical and high findings, the subsequent one combined them. Both sets of figures represent the campaign's own assessments; separate evidence is needed to confirm exploitability and remediation outcomes as verified by project maintainers.

The Human-AI Partnership

Rob Hamilton, a key figure in the campaign, described Kimi K3 as the model handling the heavy analysis, while GPT Sol, Fable/Opus, and GLM 5.2 were used to support documentation efforts. He also noted that OpenAI's Cyber Harness was applied to specific components he deemed to be load-bearing.

A day later, Hamilton explained that subject-matter experts could elevate an assessment’s severity with minimal input, such as "one or two sentences of context or a small block of code." In the examples he provided, this expert input transformed middling concerns into high or critical issues. He also pinpointed operations, disclosure handoffs, and triage as significant bottlenecks in the workflow.

According to Hamilton's account, the AI models performed broad searches while human specialists were responsible for crafting prompts, interpreting the output, attempting to reproduce the issues, and determining which reports were suitable for disclosure. This division of labor effectively establishes the campaign as a human-AI hybrid review system.

Unverified Claims and Missing Metrics

The developer known as Calle stated that most critical reports were quickly verified by project owners. However, this post did not provide a denominator, a count of verified reports, a rejection count, or the status of any patches, leaving the scope and result of this verification unclear.

In its 55-hour update, BitcoinRed Team reported that 19.5% of the scanned projects contained a SECURITY.md file, and 13.1% included an email address within that file. The project corpus, the interpretation of the denominator, and the measurement methodology were not included in the thread, meaning these percentages only reflect the campaign's specific scan.

The financial costs of the operation also escalated. On August 3, Hamilton stated the effort had spent over $10,000 scanning over 100 repositories and had disclosed critical findings immediately when a proof of concept confirmed exploitability. By August 4, he reported about $20,000 in spending, with more than a dozen disclosures and 150 repositories scanned.

As the scanning efforts continued to broaden, the campaign identified outreach, handoffs, and triage as ongoing operational constraints. The published snapshots do not offer a comparable denominator for disclosures at the 55-hour mark, preventing any assessment of the relative speed of scanning versus resolution.

Context and Criticism

Hamilton later pointed to the separate Coldcard incident as a catalyst for the wider campaign, though the campaign's records do not attribute the discovery of the Coldcard flaw to this particular sprint.

For a comprehensive public accounting, it would be necessary to separate findings into categories such as reproduced, acknowledged, downgraded, rejected, and fixed, complete with clear definitions and denominators for each rate. Such a breakdown would reveal how much of the campaign's high-volume output translated into actionable security work.

Public critic JW Weatherman contended that the campaign could not triage its output. His post did not reference any specific issue, patch, or advisory linked to the campaign, thereby offering criticism without a measurable failure rate. The fundamental question remains open due to the campaign's own lack of disposition data.

For now, the 6,700 figure represents campaign-labeled findings and candidates for triage. While the sprint has powerfully demonstrated the speed of machine-assisted review, its enduring security value will ultimately depend on the proportion of findings that experts can successfully validate, disclose, and see converted into fixes.