Is ransomware malware?

Yes. It is a category associated with coercive disruption, often involving encryption or other denial of access, and sometimes additional data theft.

Can a model file present a security concern?

Yes, depending on its format, loading mechanism and accompanying code. Treat provenance and execution behavior as relevant.

Is prompt injection always malware?

No. It is a different attack mechanism, although it can be combined with malicious software or unsafe tool execution.

AI Glossary / Governance, ethics and safety / Beginner

Malware

Definition

Malware is software or related executable logic deliberately designed to perform harmful or unauthorized activity. It can compromise information, interfere with services, spy on users or give an attacker control over parts of a digital system.

What it means

Malware is an umbrella term rather than one particular attack. Viruses, worms, Trojan programs, spyware and ransomware describe different behaviors or delivery patterns, and categories can overlap. Not all malware visibly damages files or displays a warning.

AI systems can be affected through the same surrounding software and infrastructure as other applications. A malicious package, compromised plugin or altered deployment artifact can affect a service even if the model itself produces ordinary-looking answers.

A mistaken prediction is not automatically malware. Nor is every prompt-injection message malware: an instruction embedded in untrusted content may attempt to redirect an AI without containing executable malicious software. Distinguishing the mechanism helps the response address the actual problem.

How it works

Malicious code must reach an environment where its behavior can take effect. It may arrive through a deceptive download, a compromised dependency or another intrusion path. Execution and the permissions available then determine what it can do.

Defensive work therefore covers trusted acquisition, software updates, suitable access limits, monitoring and response. AI workflows should also examine components loaded around models, including scripts and formats that may invoke code during processing. A familiar filename or a claim that something is only a model does not establish that it is safe to load.

When suspected malware is found, follow a suitable incident process that preserves evidence and contains impact. Removing one visible file may not address persistence, stolen credentials or changes already made elsewhere in the environment.

Three practical examples

A business reviews an AI browser extension's source and permissions before allowing it access to confidential pages.
A deployment team obtains model-related software from approved sources and checks the artifacts used in its pipeline.
An operations team investigates unexpected data transfers from a machine that hosts an AI service rather than assuming the model's normal answers prove the machine is healthy.

Think of it this way

Think of a tool delivered with a hidden mechanism that performs an unwanted action when used. The tool may still perform its advertised function, which can make the unwanted behavior harder to notice.

The analogy emphasizes concealed harmful functionality. Malware can take many technical forms, and its presence must be investigated through appropriate evidence rather than inferred from unfamiliar appearance alone.

Worked example

Downloaded is not the same as executed

In an invented incident review, a malicious installer is found on ten workstations. Logs show that it ran on three. Of those three, two made suspicious outbound connections, while records for the third are incomplete.

The team should not report ten confirmed executions or only two potentially affected machines. It has ten systems with the file, three confirmed executions and an unresolved communication question for one executed copy. Other evidence may change that assessment.

The response examines the relevant systems, permissions and possible consequences. The distinctions help prioritize investigation and communicate uncertainty. A detection count is not automatically the number of compromised accounts, exposed records or successful attacker actions.

Illustrative case study

Fictional company Cedar Design installs a free utility advertised as improving AI image generation. It performs the advertised conversion but also requests access unrelated to that task. Monitoring later identifies unexpected activity from a workstation using it.

The company follows its incident procedure, limits further exposure and reviews installation sources, account access and the available logs. It does not treat a successful antivirus scan after removal as the sole evidence that every consequence has been resolved.

The case illustrates why useful functionality and malicious behavior can coexist. A tool's apparent productivity benefit does not replace a review of provenance and permissions.

Common misconceptions and mistakes

Malware must destroy files. Theft, surveillance or unauthorized access may be its objective.
A useful program cannot be malicious. Harmful behavior can be packaged with legitimate functions.
Every software bug is malware. Bugs can cause harm without being deliberately malicious.
Deleting the downloaded file always completes recovery. Execution may have created additional changes or exposed credentials.

Business use

Businesses adopting AI tools should include them in ordinary software acquisition and endpoint-security processes. Review extensions, packages and integrations as executable components with permissions, not merely as convenient AI features.

Maintain an inventory and a workable route for reporting suspicious behavior. Test recovery arrangements for the services the business depends on. When an incident occurs, communicate what is known, what remains uncertain and which actions address the identified pathway. Avoid equating a clean-looking model response with evidence that the surrounding application is uncompromised.

Check your understanding

A downloaded AI utility works correctly but secretly performs unauthorized data transfers. Does its useful feature rule out malware?

Answer: No. Legitimate-looking functionality can coexist with deliberately harmful behavior. Evaluate the unauthorized activity and the environment it affected.

Related terms

Incident response
Least privilege
Malicious code
Trojan horse
ransomware
software supply chain

Learn next

Read software supply chain and least privilege. List the software components installed for one AI workflow, their sources and their permissions. Identify which components can execute code or access sensitive information beyond the immediate task.

Least privilege

Sources

NIST CSRC glossary, malware: https://csrc.nist.gov/glossary/term/malware. NIST SP 800-83 Revision 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops: https://csrc.nist.gov/pubs/sp/800/83/r1/final. The latter has a desktop and laptop scope; the AI examples here are original applications of the general distinction between malicious functionality and ordinary errors.

Previous: Malvar - He - Cutler demosaicking Next: Managed private cloud