Artificial Intelligence Without Oversight: Are We Ready for Autonomous Digital Attacks?

A dangerous capability is moving from specialist teams into private rooms.

In 2026, a person does not need to work for a state, a criminal group, or a major technology company to assemble a powerful autonomous AI system. They can buy high-end desktop hardware, download a local language model whose refusal behaviour has been reduced, connect it to an agent that can use a browser, execute commands, and access the internet, then give it a malicious objective.

The important change is not that a model can explain a security concept. The important change is that an agent can keep working. A person who cannot write code, interpret scanner output, or understand an application stack can ask a system to investigate a target, look for weaknesses, explain what it finds, and continue trying alternatives. The person provides intent; the agent can increasingly supply technical labour.

That does not mean an unskilled person can compromise every website by typing one sentence. Targets still need weaknesses. Agents make false claims. Strong defences, authentication, segmentation, monitoring, patching, and rate limits still work. But the traditional barrier—having to understand each technical stage before attempting it—is falling. A person without the knowledge to conduct a sustained attack alone can now direct software that attempts part of that work autonomously.

For skilled criminals or state-backed operators, the implication is worse: agents can multiply attention. One operator can supervise many long-running tasks, compare results, and keep probing reachable systems while people choose targets and make strategic decisions. Public reporting and provider disclosures already document agentic AI in real malicious campaigns.

This article argues that the combination of local models, reduced-refusal variants, autonomous tools, and internet reach is a growing public-security risk. It requires proportionate regulation and secure defaults—not a ban on local AI, but accountability for systems that can act.

The central claim: A local language model is not a weapon by itself. It becomes a dangerous instrument when it is given a harmful objective, autonomous tools, network reach, and enough authority to act without meaningful human control.

A private attacker can now assemble a capable system

Until recently, the most capable AI systems were mostly consumed through a provider. A person used an account, an API key, and a hosted interface. The provider could observe usage, impose limits, refuse requests, suspend an account, or change the model’s behaviour. Those mechanisms were not perfect safety controls, but they were intervention points.

Local AI removes many of those points. The model can be downloaded and run on hardware owned by the user. Prompts can stay on the machine. The operator can select the model, modify the surrounding software, choose the tools, and decide whether it has safeguards. No cloud provider necessarily sees the request or can interrupt the session.

The hardware is no longer purely theoretical. On 15 October 2026, Apple published research showing the 816-billion-parameter Muse Spark Open model running across four Mac Studio systems using MLX and RDMA over Thunderbolt. Apple reported more than 36 tokens per second under its stated test conditions. Apple’s report is not evidence that an ordinary laptop can run a frontier model or that such a model can autonomously compromise a target. It is evidence that very large local inference has moved onto desk-side hardware.

Smaller models are easier still. Tools such as Ollama, LM Studio, llama.cpp, and MLX make it straightforward to acquire, run, and integrate local models. That is valuable for privacy, research, and defensive work. It also means the technical ingredients for a private agent system are no longer limited to specialist laboratories.

A person does not need to train a model from scratch. They need hardware, model weights, an agent framework, and a goal. The cost is still meaningful at the high end, but it is far lower than building a conventional research data centre or hiring a capable technical team.

No expertise does not mean no offensive capacity

A person without cybersecurity knowledge cannot reliably judge every model result. They may not know whether a reported weakness is real, whether a tool has made a mistake, or whether an attempted action has succeeded. That remains a real constraint.

But it is the wrong comparison to ask whether such a person becomes an expert overnight. The relevant comparison is whether they can begin technical activity that they could not previously begin, keep it running longer than they could manually, and obtain explanations or next steps without understanding the machinery underneath.

An autonomous system can split an open-ended objective into smaller tasks, collect observations, interpret results, revisit failures, and maintain context. It can do this without fatigue. The user need not know every command or every protocol if the agent selects and operates the tools available to it.

This is why reduced-refusal models matter. “Uncensored” and “abliterated” are not reliable measures of quality or risk. They describe attempts to reduce a model’s tendency to refuse particular requests. A weak model with fewer refusals can still fail. Yet when a capable model is paired with an agent, the reduction of that refusal layer removes one practical barrier between malicious intent and repeated technical attempts.

The danger is not a chat response. It is a system that can turn a vague instruction into a continuing process.

From a single instruction to an autonomous campaign

Imagine the difference between two systems.

The first is a chatbot. It produces prose, code snippets, and explanations. The user must interpret the output, decide what is relevant, operate the tools, and handle errors.

The second is an agent. It is authorised to use a browser, inspect supplied information, call technical tools, keep notes, and continue working until it reaches a stopping condition. It can receive a broad objective and attempt to turn that objective into a sequence of actions.

That second system is a different category of risk. The model still makes predictions rather than possessing magical access. But its persistence changes the economics of malicious activity. It can make more attempts, test more branches, work across hours, and return only when it believes it has something useful.

For an unskilled person, this can turn harmful curiosity into active attempts against a target. For a skilled operator, it can turn one person into the supervisor of a much larger volume of work. The person remains responsible for choosing the target and the goal; the agent can increasingly perform the repetitive technical execution.

It is not necessary to claim that the agent succeeds every time. A large number of systems are already weak for ordinary reasons: exposed management interfaces, unpatched software, poor authentication, misconfigured cloud resources, insecure third-party applications, and overlooked credentials. Automation does not need to defeat a well-run organisation to be dangerous. It only needs to find enough weak systems faster and more persistently than before.

Evidence, not science fiction

The trend is supported by evidence, though the evidence has limits.

Anthropic’s August 2025 threat-intelligence report described a cybercriminal actor using Claude Code in a large-scale theft and extortion operation targeting at least 17 organisations. According to Anthropic, the system was used across reconnaissance, credential harvesting, intrusion support, data analysis, and targeted extortion communications. The report is a provider disclosure, not a global census. It nevertheless demonstrates that agentic AI has already been used beyond drafting advice.

Anthropic’s November 2025 GTG-1002 report described an espionage campaign against roughly 30 entities. The company assessed that AI carried out 80–90% of tactical operations independently, while humans retained strategic control. The same report warns that the model fabricated some findings and claimed credentials that did not work. That limitation is essential: autonomy increases scale, but it does not remove the need for validation.

Reuters reported on 19 October 2026 that agents associated with an exposed open-source multi-agent platform had attempted to compromise more than 1,200 websites; Reuters reported that more than 100 company websites were breached. Some organisations confirmed incidents or investigations, while the full impact was not independently established for every target. Reuters’ investigation should therefore be treated as reported activity, not as proof that every claimed compromise had the same impact.

Together, these cases support a narrow but serious conclusion: agentic systems can already automate meaningful elements of malicious work. Their failures do not cancel the risk. They show why an operator with enough knowledge to check and redirect the system may be especially dangerous—and why an unskilled person may still be able to initiate attempts they could not previously organise.

The problem is the assembled system, not just the model

A local model that writes text without access to anything else is not equivalent to an autonomous agent with tools. The risk rises where several elements are combined:

This is the architecture that regulation should recognise. It avoids the simplistic claim that all local AI is dangerous while acknowledging that an autonomous, high-authority agent is more than a private chatbot.

The legal gap is not simply “crime is legal now”

Unauthorised access to systems is already illegal. That remains true whether a person uses a keyboard, a script, or an autonomous model. The question is not whether a local AI agent creates a legal right to attack others. It does not.

The problem is that criminal law generally activates after harmful conduct and after investigators can identify a responsible person. It does not necessarily create a secure technical default before the harm. It does not require a locally assembled autonomous system to preserve useful audit logs, make high-impact actions visible, constrain network reach, or maintain an accountable operator.

The EU AI Act is relevant but incomplete for this scenario. The European Commission notes that personal, non-professional use by a natural person is generally outside the scope of the Act’s deployer obligations. Professional use may bring a person or organisation into scope, and Article 50 transparency obligations apply from 2 August 2026. Commission guidance sets out those distinctions. The point is not that the Act is ineffective. It is that a private, locally operated agent can fall outside parts of a framework designed around providers and professional deployment.

The same distinction matters for NIS2 and Latvia’s National Cybersecurity Law. NIS2 and Latvia’s law create important obligations for entities in scope. They are not a general control system for every home laboratory. A private person operating a local model may be outside those organisational requirements until their activity causes harm.

That is the regulatory gap: not a lack of laws against hacking, but a lack of proportionate rules for the deployment of high-authority autonomous systems before a serious incident occurs.

What should regulation target?

A good response should not prohibit mathematics, local computing, open research, or privacy-preserving inference. Such a prohibition would be impractical, harmful to legitimate users, and unlikely to stop determined criminals.

Regulation should target the combination of capability, authority, and deployment context.

1. Clear accountability for autonomous operation

A person or organisation that deploys an autonomous agent with material authority should be accountable for how it is configured and used. “The AI did it” should not remove responsibility where an operator granted the system credentials, tools, and a goal.

This does not require treating every user as a software vendor. It means that deploying an agent with broad execution or external communication power should carry duties proportionate to the risk: a named operator, records of authority, and a route to suspend the system.

2. Secure defaults for agent platforms

High-risk capabilities should not be enabled by accident. Sandboxing, constrained execution, tool allowlists, and approval for irreversible actions should be the default posture when an agent is installed for general use. A user can deliberately broaden authority, but that decision should be visible and informed.

OpenClaw illustrates the policy issue because its documentation explicitly says that sandboxing and exec approvals are off by default in its trusted single-operator posture. It also documents hardened configurations using sandboxes, restricted permission modes, allowlists, auditing, and egress control. OpenClaw’s documentation is not evidence that the platform is malicious. It is evidence that configuration choices determine the risk.

3. Capability and safety assessment for high-authority releases

Open models should not be prohibited merely because they are open. But a model or package designed to operate autonomously with broad tools should be assessed for foreseeable misuse before broad release. The assessment should ask what happens when it is connected to a terminal, browser, network, and untrusted content—not only how it behaves in a chatbot demonstration.

The purpose is not censorship of research. It is evidence. Developers, regulators, and users need to know which safeguards fail, which actions the agent can initiate, how often it produces false claims, and what controls actually constrain it.

4. Incident reporting and shared visibility

Significant incidents involving autonomous agents should be recorded in a way that lets defenders and policymakers learn from them. Today, many facts are visible only to a provider, a victim, or a researcher. Without better reporting, public debate swings between sensational anecdotes and unjustified reassurance.

A reporting regime must protect victims and avoid forcing disclosure of exploit details. It can still record the agent’s role, level of autonomy, affected authority, controls that failed, and remediation. CERTs and national cybersecurity authorities could help build that picture.

5. Legal certainty for authorised defence

Defenders need modern tools too. An organisation should be able to use a tightly controlled agent to analyse its own logs, test authorised systems, and accelerate incident response. The law should distinguish authorised defensive testing from unauthorised intrusion, while requiring that safety controls and accountability exist in both high-authority deployments.

A regulatory model for local AI use

Regulating local AI must not mean registering every model download, scanning every private computer, or treating a private offline experiment as a public threat. That would be disproportionate, technically unrealistic, and hostile to privacy, research, and legitimate open-source development.

The law should instead distinguish between private inference and autonomous, high-authority operation. The threshold is not where the model weights are stored. It is what the assembled system is permitted to do.

Tier 1: private, offline, or read-only use

A person running a local model for personal writing, translation, coding assistance, research, or document analysis should remain free to do so. Ordinary endpoint security, existing criminal law, and data-protection rules already apply where relevant. No special registration should be required merely because the model is local or because it has reduced refusal behaviour.

Tier 2: local agents used by organisations

When an organisation gives a local agent access to internal data, business systems, or employees, it should have to maintain a basic inventory: model and agent version, owner, tools, identities, data sources, network destinations, and emergency-disable route. The organisation should record what the agent can do, not only what it is intended to do.

For systems in scope of NIS2 or Latvia’s National Cybersecurity Law, a high-authority AI agent should explicitly appear in risk assessments, incident-response exercises, supplier management, and audit logging.

Tier 3: high-authority autonomous agents

A stricter regime should apply when a local agent can execute operating-system commands, change production systems, access privileged credentials, communicate externally, or operate continuously with broad network reach. At that point, the operator should be required to provide:

• a named accountable operator or organisation;
• sandboxing or an equivalent isolation boundary;
• least-privilege, dedicated identities;
• human approval for destructive, irreversible, external, or material production actions;
• immutable or independently retained audit logs;
• an emergency stop and credential-revocation process;
• a documented risk assessment and periodic test of controls.

These are not exotic burdens. They are the same controls expected of other privileged automation. The difference is that agents can select and chain actions from natural-language objectives, making the boundary especially important.

Tier 4: public distribution of autonomous agent products

A product marketed or packaged for autonomous tool use should be assessed before broad release. The assessment should not ask only whether a model produces offensive text. It should test whether untrusted content can redirect the agent, whether broad objectives lead to unsafe tool calls, whether the system can be confined, how operators can inspect its actions, and whether its safeguards can be bypassed by ordinary configuration.

Developers should publish a concise capability and safety statement: supported tools, default permissions, sandboxing posture, network behaviour, logging, known failure modes, and recommended deployment limits. Users cannot make informed choices if they cannot tell whether a product is a private assistant or a persistent automation engine with access to their infrastructure.

Incident reporting and liability

When an autonomous agent causes or materially contributes to a serious cybersecurity incident, the responsible operator should have a duty to preserve evidence and report through an appropriate channel. The report should identify the agent’s role, authority, model and configuration version, affected systems, and controls that failed. It should not require publication of exploit details or private data.

Liability should follow the grant of authority. If a person deliberately configures an agent to act against systems they do not own or have permission to test, existing criminal law should apply. If an organisation deploys a high-authority agent negligently, fails to use available safeguards, or conceals a serious incident, regulatory consequences should follow. A statement that “the model acted on its own” should not end the inquiry.

This approach regulates the dangerous deployment pattern without criminalising local computation itself. It preserves a home laboratory, a privacy-preserving local assistant, and authorised security research—while drawing a clear line around autonomous systems that can act broadly in the world.

The strongest objections—and why they do not end the argument

The case for regulation has serious counterarguments.

“Criminals will ignore it.” They may. But the same is true of many safety rules. Secure defaults, reporting obligations, and accountability can still reduce accidental harm, raise the cost of careless deployment, improve evidence after incidents, and help legitimate operators differentiate themselves from covert misuse.

“Local AI protects privacy.” Correct. Local inference can be a strong privacy measure. That is a reason to regulate authority and behaviour rather than to ban local execution. A private model that summarises personal documents is not comparable to an autonomous agent with unrestricted system and network access.

“Open source helps defenders.” Correct again. Security research and independent auditing depend on access to models and tools. The answer is not to deny defenders capability. It is to require safer deployment patterns when capability is combined with high-impact action.

“Models still make mistakes.” They do. The GTG-1002 report is direct evidence. But error does not eliminate risk; it changes the shape of it. A fallible system can still run thousands of attempts, expose data, produce convincing phishing material, or act faster than a small team can observe. It may also make mistakes that harm its owner or innocent third parties.

“Existing law is enough.” Existing law may punish a completed attack. It is not a substitute for knowing who operated a high-authority agent, whether it had a safe default, what it could access, or how investigators can reconstruct its actions.

A proportional threshold, not universal surveillance

The wrong response would be a registration scheme for every model download or every private experiment. That would be unenforceable and would create its own privacy risks.

A better threshold is based on what the assembled system can do. A local assistant that answers questions from a personal document library should not face the same burden as an agent authorised to execute commands, browse freely, use administrator credentials, contact external services, and act continuously without approval.

The more authority the system receives, the stronger the expected controls should be:

This is a technology-neutral approach. It applies whether the model is local or hosted, open or proprietary. Local operation deserves special attention because centralised enforcement may be absent, not because every local user is suspect.

Why the home-laboratory scenario matters

It is tempting to dismiss a home laboratory as a marginal case. Large criminal groups have infrastructure, money, stolen credentials, and experienced operators; a person with a few computers appears insignificant by comparison. That intuition becomes less reliable when software lets one person supervise work that is asynchronous, repetitive, and distributed across agents.

A traditional limitation on a small operator is attention. A person can only read so many outputs, try so many alternatives, and sustain concentration for so many hours. An agent does not remove the need for human intent, but it can keep a technical process moving while the person sleeps or works on something else. It can maintain notes, rerun a task after an error, and return only when it believes it has a useful result. That persistence is one reason local autonomous systems deserve attention even before they match the capability of the largest hosted models.

The local setting also changes the practical ability to intervene. A hosted provider can sometimes detect unusual activity, block an account, rate-limit an API key, or preserve operational telemetry. Those interventions are not perfect and should not be treated as a complete defence. But they are at least possible because the provider controls part of the stack. With a local model and locally controlled tools, there may be no external party with visibility or authority to interrupt a harmful workflow.

The fact that the operator is at home does not make the effect local. A machine with ordinary broadband connectivity can communicate globally. Its physical location says little about the systems it can reach or the data it can process. The policy question is therefore not whether the hardware is in a company data centre or a spare room. It is whether the system has been given the authority to take consequential action against or through other systems.

This is also a resilience issue. Local agent systems can be copied, moved, modified, and operated without a central account. A safety approach that relies only on platform moderation leaves a blind spot. That does not justify intrusive monitoring of private citizens. It does mean that high-authority agent products should carry safety features that remain useful when no provider is watching.

Secure defaults are a freedom-preserving response

Regulation is often presented as the opposite of technical freedom. In this case, the better objective is to preserve freedom to experiment while making dangerous authority harder to grant by mistake.

A secure default does not forbid an expert from deliberately configuring a system for a legitimate purpose. It asks the system to start in a state where damage is contained. An agent can be useful while it has no access to secrets, no open-ended command execution, no external network access, and no ability to make irreversible changes without approval. The owner can add permissions later, but each addition should be explicit and attributable.

This pattern is familiar in other areas of computing. A new service account does not need global administrator privileges. A new application does not need access to every document. A new firewall rule does not need to permit all traffic. These are not restrictions on innovation; they are ordinary engineering discipline. Autonomous agents should be held to the same standard because their interface is unusually flexible: natural language can be used to express goals that the system then translates into technical operations.

The most valuable defaults are practical:

• agent tools disabled until a workflow explicitly enables them;
• dedicated, minimal identities instead of shared administrator credentials;
• approval for production changes, external communication, or irreversible steps;
• network egress denied or allowlisted by default;
• logs exported to a system the agent cannot erase;
• visible configuration of model, tools, permissions, and owner;
• a local emergency stop that revokes access rather than merely asking the model to stop.

These measures do not depend on detecting whether a prompt was malicious. They reduce the impact even when detection fails. That is important because prompt injection, deceptive documents, and misleading tool output will remain hard for models to interpret reliably.

Accountability must follow authority

There is a reasonable fear that regulation of local AI could become a demand for registration, identity checks, or inspection of every private computer. That would be disproportionate and would create serious privacy and civil-liberties problems. It is also unlikely to stop criminal misuse.

The alternative is not no accountability. It is a threshold based on authority. A person who runs an offline local model to translate documents or organise personal notes should not be treated like an operator of a continuously running agent with production credentials and unrestricted network access. The relevant question is what the assembled system is allowed to do.

For high-authority deployments, accountability can be concrete rather than ideological:

• Who owns the agent and can disable it?
• Which identity does it use?
• Which tools are enabled?
• What data can leave the environment?
• Which events are recorded?
• Which actions require a second person?
• How are serious failures reported and investigated?

A framework built around those questions avoids judging a model by its political or cultural “censorship” label. It focuses on operational reality. An open model can be operated safely in a restricted workflow; a proprietary model can be dangerous if it has excessive authority and hidden actions.

This approach also gives responsible developers an incentive to compete on safety architecture. Agent platforms should be able to demonstrate that they support isolation, permissions, auditability, reversible workflows, and incident response. A product marketed for autonomy should not treat those controls as optional extras understandable only to a specialist.

What regulation cannot solve

No policy will make autonomous systems harmless. Criminals can ignore rules, run unmaintained software, use stolen accounts, or adapt around a national requirement. Model weights can be copied. Code can be modified. Enforcement across borders is difficult.

Those facts are arguments for modest, technically grounded rules, not for resignation. Seat belts do not prevent every crash; they still reduce harm. Vulnerability disclosure does not stop every exploit; it still improves collective defence. The same logic applies here. Secure defaults reduce accidents and careless deployment. Reporting improves visibility. Clear responsibility improves post-incident investigation. Legal certainty lets defenders test and harden their own systems without blurring the line with unauthorised activity.

The most important limit is epistemic: policymakers should not pretend that every alarming claim about agents is proven. A report of one campaign does not establish a universal capability. A benchmark is not a forecast. A model that works in a laboratory may fail in a complex real environment. That is why regulation should be reviewed against evidence, with input from security researchers, civil society, operators, and affected users.

But uncertainty is not a reason to wait for a catastrophic demonstration. Cybersecurity repeatedly shows that capabilities become normal before governance catches up. Once an insecure pattern is embedded across thousands of deployments, changing defaults is more expensive and politically harder.

The choice before defenders and policymakers

Defenders should continue to use automation, including local AI, where it improves privacy, speed, and security. They should not concede the technology to malicious users. A well-controlled defensive agent can help analyse alerts, explain evidence, identify missing information, and speed up authorised response.

Policymakers should ensure that the market does not reward the least accountable version of autonomy. If a product makes it easy to give a model persistent tools, broad access, and network reach, it should make it equally easy—or mandatory—to constrain and audit those powers.

The key distinction is not between humans and AI. It is between systems that remain accountable to human decision-makers and systems that are allowed to act with high authority while no one can reliably explain, stop, or reconstruct what they did.

Conclusion: regulate the power to act

The claim is not that a person can buy a computer tomorrow and autonomously compromise any system they choose. That would be false.

The more defensible claim is more troubling: a person with malicious intent can increasingly use a local model and autonomous agent to attempt technical work they do not fully understand; a skilled operator can use the same system to scale work that previously required more time and more people. Where the target is weak and the agent is granted tools, network reach, and persistence, the result can be serious.

The threat is therefore not an “uncensored” model in isolation. It is the growing availability of systems that combine model capability with independent action while escaping the account controls, monitoring, and intervention points of a hosted platform.

We should preserve the benefits of local AI: privacy, research, competition, resilience, and defensive innovation. But we should stop pretending that every autonomous agent is merely a chatbot. When software can act in the world with the authority we give it, the person who gives it that authority must remain accountable.

Sources and evidence limits

• Apple Machine Learning Research — Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio, 15 October 2026
• Reuters — How one hacker used AI agents and a few thousand dollars to break into scores of sites, 19 October 2026
• Anthropic — Detecting and countering misuse of AI, August 2025
• Anthropic — Disrupting the first reported AI-orchestrated cyber espionage campaign, November 2025
• Deng et al. — PentestGPT, USENIX Security 2024
• OpenClaw — Why OpenClaw
• European Commission — AI Act transparency obligations
• European Commission — Cyber Resilience Act
• EUR-Lex — Directive (EU) 2022/2555, NIS2
• Latvia — National Cybersecurity Law

Apple’s benchmark applies to the stated hardware, precision, model, and test conditions; it is not a general claim about ordinary computers. Anthropic’s reports describe activity visible to Anthropic and its assessments. Reuters is investigative reporting; the article distinguishes reported activity from independently confirmed impact. No cited source proves that every local or uncensored model can autonomously compromise arbitrary systems.