The AI Tools Your Team Uses Could Be Your Next Security Gap
In the last week of February 2026, an autonomous AI bot worked its way through seven of the most widely-used software repositories on GitHub. It didn’t need a human behind a keyboard to do it. Within a week, it had compromised at least four of those repositories, deleted 178 software releases from one of them, pushed a malicious file to a popular developer tool marketplace, and reset tens of thousands of public stars on another. The bot, which named itself “hackerbot-claw” and identified itself in its profile as “an autonomous security research agent,” was gone before most of the affected organizations had fully assessed the damage.
If you’re a small business owner and none of those words mean much to you yet, that’s fine. The technical details matter less than what this incident represents: a documented, real-world example of AI being used offensively, at scale, against software infrastructure that millions of businesses and individuals depend on. The question isn’t whether attacks like this will affect companies like yours. It’s whether you have any visibility into how the AI tools your team is already using could be part of the problem.
Most small businesses don’t, and that’s not a criticism. Evaluating the security implications of every AI tool an employee signs up for is not something a five-to-fifty-person business is equipped to do internally without dedicated IT support. That’s precisely the kind of gap that managed IT services are built to fill.
What Hackerbot-Claw Actually Did
GitHub is the platform where most of the world’s software gets built. Developers store their code there, collaborate on it, and use automated processes to test and deploy updates. When you update an app on your phone, there’s a reasonable chance that update was built and delivered through a GitHub-connected pipeline somewhere upstream.
Hackerbot-claw was designed to exploit a specific weakness in those automated pipelines. Many repositories on GitHub use a feature called GitHub Actions to run automated tasks when someone submits a code change. If those workflows aren’t configured carefully, a bad actor (or in this case, a bad bot) can submit a seemingly routine code change that quietly runs a malicious command in the background with elevated permissions. This vulnerability class has a name in the security community: “Pwn Request.” It’s been documented for years. Hackerbot-claw found it at an industrial scale, using five distinct attack techniques across its seven targets, including injecting malicious functions into code, encoding commands inside filenames, and injecting shell commands through branch names.
Across at least four repositories, including projects from Microsoft, DataDog, and the Cloud Native Computing Foundation, the bot achieved what’s called remote code execution, meaning it ran its own commands on the target system. It used that access to steal authentication tokens and exfiltrate data to a server it controlled.
The most significant damage went to Aqua Security’s Trivy, a widely-used, open source security scanner with over 32,000 GitHub followers and real-world adoption across thousands of organizations. Using a stolen Personal Access Token, the bot deleted 178 of Trivy’s published releases, renamed the repository, wiped its public star count, and pushed a malicious artifact to the Open VSIX marketplace, a distribution point for developer tools. Aqua Security’s team caught it, restored the repository, and released a clean version, but the window of exposure was real.
One detail worth noting: the bot also attempted to use what’s called prompt injection against an AI code reviewer running on one of the targeted repositories. It replaced the project’s configuration file with instructions designed to manipulate the AI into approving unauthorized changes and posting fake approval comments. That attempt failed. The AI detected the manipulation, identified it as a supply chain attack, and refused to proceed. This is significant not because AI systems are infallible, but because it illustrates how the threat landscape has shifted. AI systems are now being used to attack other AI systems. That’s not a hypothetical anymore. It happened in February.
Why This Should Change How You Think About the AI Tools on Your Network
Here’s the uncomfortable parallel for small businesses. Hackerbot-claw didn’t compromise Trivy by finding a sophisticated, obscure flaw. It found a misconfiguration in an automated workflow, one that had been publicly documented for years, exploiting it faster and more systematically than any human attacker could have managed alone. Speed and scale are what AI-enabled attacks add to threats that already existed.
Your business network almost certainly has AI tools running on it right now. Some of them were approved. Some weren’t. An employee signed up for an AI writing assistant three months ago and connected it to their Google Drive. Someone on the team installed an AI browser extension that reads page content. Your accounting software added an AI feature in its last update and enabled it by default. Each of these tools has permissions. Some of those permissions are broader than they need to be.
The CrowdStrike 2026 Global Threat Report documents an 89% year-over-year increase in AI-enabled attacks in 2025. The same report found that ChatGPT was mentioned in criminal forums 550% more than any other individual AI model, a reflection of how broadly the technology has been absorbed into the threat landscape. These aren’t projections. They’re measurements of what already happened last year.
Shadow AI, meaning employees using AI tools that were never reviewed or approved by anyone, is now a standard feature of most workplaces. A Salesforce survey found that 55% of workers using AI on the job said they were using tools not officially sanctioned by their employer. That alone is worth taking seriously, but there’s a layer to it that most small business owners haven’t thought through.
Free and personal-tier versions of popular AI chat tools, the kind an employee signs into with a personal Gmail account on a work laptop, frequently use conversation data to train or improve their models by default. That means whatever gets typed into the chat window, client names, project details, internal financials, personnel information, may not stay internal. It can become part of a training dataset controlled by a third party under the terms of service your employee agreed to without reading. Paid enterprise tiers of these same tools typically disable training on customer data, but that distinction only matters if someone is paying attention to which version is actually running on your network.
For businesses in industries with compliance obligations, healthcare, legal, finance, and insurance, this isn’t just an IT concern. It’s a liability. HIPAA doesn’t have a carve-out for data shared with an AI chatbot, and neither does most client confidentiality language in professional services contracts. If a staff member pastes patient intake notes or a client’s financial summary into a free AI tool to get help drafting a document, the compliance exposure is real regardless of intent.
AI coding assistants used by small development shops or IT contractors can introduce subtle vulnerabilities into code without anyone catching them in a normal review. Third-party AI plugins added to platforms like Slack, Microsoft 365, or a CRM can serve as supply chain vectors if the plugin developer is ever compromised. An AI tool with read access to your file system, your email, or your calendar has access to things you’d never hand to a stranger walking through the front door.
None of this requires a nation-state actor targeting your business specifically. Automated tools scan for misconfigured systems indiscriminately. The ones that find something interesting follow up.
A Note for Homeowners
If you don’t run a business and the GitHub details don’t apply to you, here’s the part that does. The software on your phone, your laptop, and your smart devices is built on layers of other software, most of which you never see. When a piece of that foundational software gets compromised, even briefly, malicious code can flow downstream into updates that reach your devices weeks or months later.
You don’t have to be a developer or ever visit GitHub to be affected by a supply chain attack. You just have to run software that eventually traces back to a compromised component. The Trivy repository that Hackerbot-claw hit is a security scanner used by organizations that build software you may use. The attack was caught quickly in this case, but the category of risk is real, documented, and growing.
The most effective thing a home user can do is keep software updated. Security patches close known vulnerabilities, including those introduced by supply chain compromises that were discovered and fixed upstream. An unpatched device running software that’s two years out of date is precisely the kind of endpoint these attacks eventually reach.
What Comes Next
The Hackerbot-claw incident is a useful moment to ask a few concrete questions about your own business.
- Do you have a current inventory of every AI tool running on your network, including browser extensions, SaaS integrations, and AI features built into platforms you already use? If not, start there.
- Do you know what permissions each of those tools has? File access, email access, API connections to other services, all of it represents exposure worth knowing about.
- Do you have any policy, even an informal one, for how employees are expected to evaluate and request new AI tools before installing them?
- Are the accounts connected to your AI tools using multi-factor authentication, and are API keys scoped to the minimum access those tools actually need?
- When did you last look at what third-party plugins or integrations are active in your productivity platforms?
If you can’t answer most of those questions without digging around, you’re not behind the curve. You’re in the majority. Assessing what AI tools are running on your network, what access they have, and whether they’re introducing risk is exactly the kind of structured conversation that Bristeeri’s managed IT clients are already having. It doesn’t require enterprise-grade tooling. It requires someone asking the right questions with enough technical context to act on the answers.
The argument isn’t that AI is dangerous and you should stop using it. The argument is that AI is powerful, it’s already on your network, and it deserves the same scrutiny you’d apply to any other piece of software with access to your data.