The AI Race Tax: 11 Organizations Hacked in 26 Seconds

TL;DR: GreyNoise reported that a likely Russian-speaking threat actor used AI agents to help develop and deploy exploits against PaperCut NG/MF. The operation moved from an empty workspace to remote code execution against a real victim in under four hours, then reached domain administrator access two hours later. Once the campaign launched at scale, at least 11 organizations were compromised in 26 seconds. This was not an AI system choosing its own targets or inventing its own criminal objective. Human intent directed the operation. AI supplied speed, scale, iteration, and tireless execution. For small businesses, the lesson is not to reject AI. The lesson is to stop treating AI adoption, cybersecurity, privacy, and human accountability as separate conversations.

Eleven organizations in 26 seconds.

That number should get the attention of every business owner, technology leader, school administrator, and person responsible for customer data. It should not trigger panic. It should trigger a better question: what changes when automated agents can move through a task faster than a human defender can read the first alert?

This episode of AI With Honor examines that question through several events that arrived almost on top of one another. Anthropic released a threat-intelligence report describing malicious attempts to use Claude across cyber operations, biological misuse, surveillance, influence operations, weapons development, fraud, and model distillation. Safety researchers left Anthropic and publicly argued that competitive pressure can make responsible restraint difficult for individual laboratories. GreyNoise documented an AI-orchestrated campaign against PaperCut servers that achieved speed and scale most organizations are not staffed to confront manually. Anthropic CEO Dario Amodei separately argued that the industry must find ways to pace the frontier.

These are different stories, but they share one mechanism. I call it the AI race tax.

What the AI race tax actually means

The AI race tax is the safety work that gets delayed because speed creates an immediate reward while the cost of weak controls arrives later. It includes security testing, red-team work, access controls, privacy review, retention policies, incident reporting, human supervision, evaluation, patching, and the unglamorous work of deciding what a system must never be allowed to do.

The term is not an accusation that every laboratory or business is acting maliciously. The more difficult point is that nobody has to be a villain for a dangerous corner to be cut.

Imagine several laboratories competing to produce the most capable model. Each laboratory understands that safety matters. Each also knows that slowing down alone can mean losing customers, capital, talent, influence, and strategic position. The social benefit of caution is shared broadly, but the commercial cost of delay lands directly on the company that pauses. That is a structural incentive problem.

The same pattern appears inside ordinary businesses. A team wants an AI receptionist live by Friday. Nobody has documented what customer information the system can see. Nobody has defined when the system must transfer to a human. Nobody has tested how it behaves when a caller is angry, confused, vulnerable, or asking for something outside policy. The demo works, the calendar is connected, and the team calls the project finished. The missing governance becomes someone else’s problem until the system creates a public failure.

The race tax is paid in advance through discipline or paid later through incidents. There is no version where the cost disappears.

What happened in the PaperCut campaign

GreyNoise reported that a likely Russian-speaking malicious cyber actor used artificial intelligence to develop, test, and use exploits against PaperCut NG/MF. PaperCut is print-management software used by organizations around the world, including schools and other institutions that may not have around-the-clock security teams.

The vulnerabilities were identified as CVE-2026-81578 and CVE-2026-82078. PaperCut published emergency guidance and later security maintenance releases. According to GreyNoise, the actor moved from an empty workspace to remote code execution against a real victim in just under four hours. The first domain administrator access followed in roughly two additional hours. When the full campaign launched, it compromised at least 11 organizations in 26 seconds.

GreyNoise reported hundreds of affected server instances across hundreds of identified organizations in dozens of countries. The education sector represented a significant portion of the victim set. In one reported case, a United States high school moved from initial access to full domain administrator compromise in seven minutes.

Those figures need careful language. A compromised server instance is not the same thing as a unique organization. Initial access is not the same thing as domain administrator access. The campaign did not achieve the same outcome against every target. Some defenses worked. GreyNoise specifically noted that a Cloudflare web application firewall defeated the adversary in at least one instance. Basic hardening still mattered.

That nuance strengthens the practical lesson. AI did not make defense irrelevant. It compressed the time available to respond.

AI did not choose the crime

It is tempting to describe an event like this by saying AI attacked hundreds of organizations. That wording is dramatic, but it can hide the most important fact.

A person chose the objective.

A person selected or approved the tools.

A person supplied the infrastructure and criminal intent.

A person benefited from the operation if it succeeded.

The agents accelerated research, coding, testing, scanning, adaptation, and execution. That acceleration is genuinely new and deserves respect. Work that once required a specialized human team and a long manual cycle can increasingly be performed by a smaller number of operators supervising many automated workers. The barrier to causing damage can fall even when the underlying vulnerability, criminal motive, and weakly defended server are familiar.

Keeping the human actor in the sentence is not an attempt to minimize AI risk. It is how we preserve accountability. If we blame an abstract machine for every failure, the people who configured the permissions, approved the deployment, selected the targets, ignored the warnings, or profited from the result can disappear from view.

AI changes capability. It does not erase agency.

The same tool can create two opposite outcomes

The public debate often forces AI into one of two stories. In the first, it is a miracle that will remove friction, create abundance, and solve problems that human institutions have failed to solve. In the second, it is an uncontrollable force that will destroy employment, privacy, security, and eventually human autonomy.

Both stories can be useful to people selling something.

Laboratories benefit when the public believes their systems are extraordinarily powerful and difficult to reproduce. Safety organizations benefit when risks receive serious attention and funding. Politicians benefit when a frightening issue creates urgency. Consultants benefit when a confusing market makes guidance valuable. Media outlets benefit when fear and conflict increase attention. Creators benefit when a dramatic claim earns a click.

That does not mean every warning is false or every opportunity is inflated. It means we should ask the same question of every voice, including mine: who benefits if we believe this framing?

The better approach is to inspect the mechanism.

Higher productivity can become faster service, better quality, lower prices, stronger security, and new products. The same productivity can become layoffs, a larger computing bill, weaker customer relationships, and concentrated control. The technology does not independently select the moral or business outcome. Owners, executives, developers, regulators, customers, and operators make those decisions.

That is why responsibility cannot be delegated to a model.

Small businesses have an advantage the giants do not

Small operators often assume they are permanently behind because large companies have bigger budgets, larger technology teams, and privileged access to sophisticated systems. That is only one side of the equation.

A local business with six trucks, one front desk, and an involved owner can identify a lost-lead problem on Tuesday and change the workflow by Thursday. A giant organization may need approvals from technology, legal, security, operations, procurement, and executive leadership before anyone is allowed to alter a customer-response system.

Speed is available to both, but it takes different forms.

The large organization can buy more computing power. The small business can make a clear decision quickly.

Consider a heating and air-conditioning company that receives an urgent call at 6:40 on a Saturday evening. The office is closed. The call moves to voicemail. The owner hears it Monday morning, long after the homeowner booked another company through a search result.

That business may not need an autonomous agent. It may need a simple switch: when a call is missed after hours, send an immediate text to the person on duty and create a follow-up task. That rule may recover more revenue than a complicated chatbot because it fixes the actual leak.

This is the discipline I use when auditing a workflow:

1. How does a real lead enter the business?
2. What happens during the first 10 minutes?
3. Who owns the next action?
4. Where does the lead stop moving?

Only after those answers are visible should we ask whether the right tool is a notification, a fixed automation, an AI assistant, or an agent that can make limited decisions.

A switch is not an agent

The AI market often uses the word “agent” for anything that performs more than one step. That makes buying decisions harder than they need to be.

A switch follows a known rule. If a qualified form arrives, assign it to a person, send a confirmation, and set a timer. If a call is missed after hours, alert the on-call employee. If an invoice reaches a certain age, place it in a review queue. These workflows can be extremely valuable without making independent judgments.

An agent receives a goal, examines context, chooses among possible actions, and adjusts based on results. That flexibility is powerful. It also expands the number of ways the system can surprise us.

Use a switch when the desired behavior can be written as a stable rule. Use an agent only when the task truly requires interpretation or judgment, and only after the boundaries are written down.

Before an agent touches a customer, a network, a financial process, or a proprietary data set, the business should be able to answer:

• What information can the agent access?
• What actions can it take without approval?
• What actions always require a person?
• What claims is it prohibited from making?
• What happens when confidence is low?
• Where is every meaningful action logged?
• Who reviews those logs?
• How quickly can the agent be disabled?
• What is the recovery plan if it behaves incorrectly?

If those questions have no owner, the agent is not ready for unsupervised work.

Treat a business agent like a new employee with unusually fast hands

An AI agent can work continuously, interact with many systems, and repeat a flawed action at machine speed. That makes the first days of deployment especially important.

Start with minimum permissions. Do not give broad network, inbox, file, calendar, payment, or customer-record access because it makes setup easier. Give the agent only the information and actions required for the current job.

Create approval gates at consequential moments. Drafting a reply may be acceptable. Sending it to a customer may require review. Preparing an invoice may be acceptable. Issuing a refund may require authorization. Summarizing a record may be acceptable. Changing the record may require a person.

Supervise the system closely for at least 30 days before expanding autonomy. Review failures, not just successes. Look for moments when the system reached the right answer for the wrong reason, because those are the failures most likely to remain hidden until conditions change.

Most importantly, do not let a pleasing demo substitute for operational evidence. A model can sound confident, friendly, and thoughtful while misunderstanding the goal. Agreeable language is not proof that the plan is sound. Ask the system to argue against its own recommendation. Ask what evidence would change its answer. Ask it to identify the most expensive quiet failure.

Keep the useful draft. Ignore the praise.

The security checklist changed when the clock compressed

Traditional patching schedules were built around a world where attackers, defenders, vendors, and administrators all moved at something closer to human speed. AI-assisted operations compress that cycle.

If an agent has network access to an exposed system that has not been patched, the business should not treat the issue as a routine item for a slow week. The PaperCut campaign demonstrates why. Once exploitation is proven, automated tooling can search, test, adapt, and move across targets faster than a conventional review process.

The minimum practical posture includes:

• Maintain an inventory of internet-facing systems and responsible owners.
• Apply vendor security maintenance releases quickly after testing.
• Remove public exposure that the business does not actually need.
• Use multifactor authentication where supported.
• Separate administrative accounts from everyday accounts.
• Limit service-account privileges.
• Log agent actions and administrative changes.
• Alert on unusual access, privilege escalation, and new integrations.
• Keep recoverable backups and test restoration.
• Confirm that a human can disable automated access immediately.

None of those steps are glamorous. That is precisely why they are easy to postpone. The race tax often hides in work that produces no impressive screenshot when it is done correctly.

Privacy begins before the first prompt

The easiest way to create an AI privacy problem is to wait until after sensitive information has already been entered.

Before using a system for customer, employee, health, financial, legal, or proprietary information, read the provider’s current terms and data controls. Determine whether prompts or outputs may be used for training, how long information is retained, where it is processed, who can access it, and whether the organization’s chosen plan changes those conditions.

If the answer is unclear, uncertainty is part of the risk.

Use data minimization. The system should receive the least sensitive version of the information required to complete the task. Replace identifying details when they are unnecessary. Separate experiments from live customer records. Do not assume a free consumer interface offers the same protections as a properly configured business agreement.

Convenience does not cancel confidentiality.

Should a small business run AI locally?

Running a model on local hardware can improve privacy, control, availability, and protection from unexpected product changes. It can also create a false sense of safety.

A local system still needs secure access controls, updates, monitoring, backups, physical protection, and someone who understands what is running. Hardware costs money. Power costs money. Maintenance consumes time. A model stored in an office is not private if every employee shares the same password or the computer is exposed to the internet without proper controls.

For many small businesses, a reputable hosted service with clearly understood retention terms, business-grade controls, limited permissions, and a defined data policy remains the practical choice. Local deployment becomes compelling when privacy requirements, predictable workloads, specialized models, or the need for control justify the operational burden.

This is not a religious argument for local or cloud technology. It is a fit question. The correct answer depends on the data, risk, staff, budget, and use case.

The frontier race is global

Anthropic’s September 2026 threat-intelligence report also discussed model distillation and the ways smaller laboratories may learn from the outputs of larger frontier systems. The larger point is that AI competition is not limited to two companies in one country. Models, methods, weights, research findings, employees, and operational knowledge move across borders and organizations.

That makes voluntary restraint difficult. One laboratory can adopt a strong safety practice, but the competitive system still rewards everyone else for moving quickly. This is why outside evaluation, incident reporting, shared standards, and enforceable rules remain part of the policy discussion.

Dario Amodei’s essay “We Must Pace the Frontier” argues that slowing frontier progress, even modestly, could create more time for alignment and safeguards. It is worth examining both the proposal and the incentives surrounding it. A frontier laboratory asking for rules may be advocating for legitimate safety and also supporting a framework that smaller competitors will struggle to satisfy. Both can be true.

We do not need to choose between blind trust and reflexive cynicism. We can evaluate the proposal, the evidence, the incentives, and the likely second-order effects.

What business owners should do today

Do not begin with a five-year AI strategy deck. Begin with one channel where real work enters the business.

Write one sentence defining what counts as a response and how quickly it must happen. Then inspect the last 10 real leads, requests, tickets, or customer messages. Record what happened during the first 10 minutes. Identify where each item slowed down, became ambiguous, or lost its owner.

Fix the first measurable leak with the simplest reliable intervention.

That might be a switch.

It might be a clearer assignment rule.

It might be an AI assistant that drafts a response for human approval.

It might be a carefully bounded agent.

The sophistication of the tool is not the measure of success. The measure is whether the workflow becomes faster, safer, clearer, and more useful to the human being on the other end.

AI can help a small operator move with a level of capability that once belonged only to large organizations. That is one of the most important opportunities of this period. Access to that leverage should not belong only to the wealthy or technically connected.

But leverage is not wisdom. Speed is not judgment. Fluency is not truth. Automation is not accountability.

We remain responsible for what we build, what we permit, what we ignore, and what we do when the warning arrives.

Source notes and developing information

The central PaperCut timing and victim figures discussed here come from GreyNoise’s September 9, 2026 investigation, “Agents Gone Wild: An AI-Orchestrated Global Campaign Against PaperCut NG/MF.” PaperCut’s own security advisory identifies the affected vulnerabilities and current maintenance releases. Anthropic’s September 2026 threat-intelligence report describes operations the company says it identified and disrupted. Public reporting on safety-research departures and Dario Amodei’s essay provide the broader laboratory and governance context.

These are developing events. Security counts, attribution, affected-system totals, remediation guidance, and conclusions may change as vendors and researchers publish new evidence. Organizations running PaperCut NG/MF should rely on current vendor guidance and qualified security professionals rather than an episode summary.

Primary reading:

• GreyNoise PaperCut investigation
• PaperCut security advisory
• Anthropic September 2026 threat-intelligence report
• Dario Amodei: We Must Pace the Frontier

For practical AI implementation focused on real workflows, visit Santa Clarita Artificial Intelligence, HonorElevate, or Hire AI Voice. Watch the full episode above, then audit the last 10 real leads in your business. The first valuable AI project may be hiding inside a missed call, an unclear handoff, or a task that nobody truly owns.

Common questions

Connor T. MacIvor · CalDRE #01238257 · Sync Brokerage, Inc. · DRE #02031490