Thales Finds Companies Fear AI Risks More Than Familiar Cyber Threats

Thales found a striking reversal: 69% of surveyed organizations named AI’s fast-changing ecosystem as their leading generative AI security concern. Familiar threats such as malware, phishing, and ransomware remain active, but enterprises now face a system they are deploying themselves.

The finding does not mean AI already causes more breaches than ransomware or malware. It shows that companies fear uncertainty around AI adoption more than any single established attack type. Security teams understand phishing controls. They have less confidence in systems that can access data, generate code, and trigger business actions.

That distinction matters because AI risk crosses several established boundaries. It combines cybersecurity, privacy, legal exposure, model reliability, and operational control. The central conflict is no longer AI adoption against resistance. It is business deployment speed against an organization’s ability to govern what it has already installed.

The Survey Reveals a Shift in Enterprise Fear

Companies are not replacing old cyber fears with AI. They are recognizing that AI can amplify several risks at once.

The data threat report surveyed more than 3,100 technology and security professionals across 20 countries and 15 industries. S&P Global Market Intelligence 451 Research conducted the research for Thales.

Among respondents, 69% selected the fast-moving AI ecosystem as their leading security concern related to generative AI. Model integrity followed at 64%, while trustworthiness ranked next at 57%.

The phrase “fast-moving ecosystem” covers more than model releases. It includes model providers, plugins, data services, development frameworks, agents, and the infrastructure connecting them. Each component can change independently, creating a chain of dependencies that security teams do not fully control.

That differs from a familiar malware incident. A security team can identify a malicious file, isolate an endpoint, and investigate its path. An AI system can behave incorrectly without carrying malware or showing a traditional indicator of compromise.

A model might expose confidential information because a user entered it into an unapproved service. An agent might retrieve data beyond the requester’s intended scope. AI-generated code might introduce a vulnerable dependency without triggering an immediate alert.

These outcomes can resemble ordinary cybersecurity failures. However, their causes often sit outside the traditional security operations center. Procurement, legal, engineering, data science, compliance, and business teams all influence the system.

The survey also found that 73% of respondents were investing in AI-specific security tools. Some received new budgets, while others redirected existing security spending. The figure confirms that concern has already moved into purchasing and planning decisions.

Yet additional software does not automatically resolve unclear ownership. A monitoring product cannot decide which business data an agent should access. It also cannot define acceptable model behavior for every customer, employee, or regulated workflow.

Traditional attack categories remained prominent in the same research. Malware held the top position among observed attack types, phishing moved into second place, and ransomware ranked third.

That context limits the headline’s meaning. AI is the largest emerging concern around generative AI adoption, not proof that established threats have disappeared. Companies must protect two overlapping environments rather than choose between them.

The shift is still important. Security leaders now treat AI as an enterprise risk domain, not simply another application requiring endpoint protection. Its failures can originate inside approved workflows and spread through trusted access.

Why AI Security Risks Escape Familiar Controls

AI changes the unit of risk from a predictable application to a system that interprets instructions and selects actions.

Conventional enterprise applications usually offer defined functions. Users enter structured data, select permitted actions, and receive bounded results. Security teams can map those functions to identities, permissions, databases, and audit records.

Generative AI accepts open-ended instructions. Its output depends on the prompt, retrieved information, model behavior, system configuration, and connected tools. Small changes anywhere in that chain can produce different results.

An AI agent adds another layer. An agent is software that uses a model to plan tasks and call tools with limited human intervention. Those tools can include email, code repositories, customer databases, calendars, and financial systems.

This architecture creates risks that perimeter defenses were not designed to answer. A valid employee can give a risky instruction through an approved interface. The model can then use authorized connections in an unintended way.

Prompt injection illustrates the problem. A malicious instruction can appear inside a document, webpage, or message that an AI system processes. The instruction attempts to redirect the model from its intended task.

No stolen password is required when the agent already has access. The attacker instead targets the model’s interpretation layer. That turns ordinary business content into a possible control channel.

Data retrieval creates a similar challenge. Retrieval-augmented generation lets a model use selected organizational information while producing an answer. The model does not need to contain the information in its original training data.

However, retrieval quality depends on permissions and metadata. A search index that ignores document-level access rules can expose material that the user could not open directly. The response can hide that access failure behind natural language.

This matters for companies building internal assistants over contracts, meeting records, support tickets, or engineering documents. A useful assistant needs broad context. Every added source also increases the consequences of weak permissions.

Employees create another exposure through shadow AI, meaning AI services used without organizational approval or oversight. Staff may paste source code, customer records, or business plans into public tools to save time.

The behavior is difficult to control with policy alone. Workers often see an AI chat box as a temporary workspace rather than an external data processor. The interface feels less risky than uploading a file to an unknown website.

The AI oversight findings cited a survey in which 78% of employees reported using AI tools at work. Within that group, 58% acknowledged providing sensitive company information to large language models.

Self-reported figures do not measure confirmed data loss. They still show why AI risk begins with authorized users, not only outside attackers. Adoption can outrun formal review because the tools are easy to access.

The challenge extends to software development. AI assistants can propose code faster than teams can review it. A generated function may work in testing while containing insecure defaults, weak validation, or an outdated dependency.

Security scanners can catch known patterns, but they cannot guarantee that generated logic matches the business requirement. Human review remains necessary, especially when code handles authentication, payments, or regulated information.

Model output also creates integrity risk. A system can produce false content with high confidence, a behavior commonly called hallucination. The result becomes dangerous when another application treats it as verified input.

A mistaken summary is inconvenient. A mistaken access decision or financial instruction has operational consequences. The same model behavior carries different risk depending on the tools and authority surrounding it.

That is why AI security cannot be reduced to model accuracy. The relevant question is what happens when the model is wrong, manipulated, or given excessive access.

The Real Conflict Is Deployment Speed Against Control

Executives want measurable AI gains now, while security teams inherit systems whose permissions and failure paths remain unclear.

The pressure begins above the security organization. Boards and executive teams expect CIOs to find productive AI uses, reduce operational friction, and avoid falling behind competitors.

Business teams can start an AI pilot within days. Building a complete inventory, permission model, evaluation process, and incident plan takes longer. That timing gap creates the article’s main conflict.

A 2026 Logicalis survey found that more than one-quarter of CIOs considered AI a significant risk. Respondents ranked it alongside malware, ransomware, and phishing, according to CIO security findings.

The same research found that two-thirds considered employee training on AI risk management insufficient. It also reported that 94% of CIOs faced a cybersecurity skills shortage.

Those findings reveal a capacity problem, not simply a technology problem. Organizations are adding an unfamiliar class of systems while existing security teams already lack enough specialized workers.

Responsibility can also become fragmented. The CIO may own technology strategy, while the CISO owns security. Legal teams oversee intellectual property and regulatory exposure. Data officers manage governance, and business units select use cases.

An AI failure can touch every group without fitting neatly inside one department. When ownership remains ambiguous, approvals become inconsistent and incident response slows.

Established cybersecurity programs offer a useful contrast. Organizations have spent years defining processes for vulnerability management, endpoint protection, identity, backups, and recovery.

Those controls remain essential. AI systems still run on ordinary cloud services, applications, and user accounts. A compromised identity can expose an AI workflow just as it exposes other software.

However, AI adds decisions that traditional controls cannot make alone. A firewall cannot determine whether a generated recommendation contains unacceptable bias. Endpoint software cannot assess whether a model cited the correct internal policy.

This does not justify creating an isolated AI governance bureaucracy. Separating AI completely from cybersecurity would duplicate controls and create new gaps.

The stronger approach starts with existing identity, data classification, software review, and incident management. Teams can then add model evaluation and agent-specific controls where ordinary processes fall short.

Identity deserves particular attention because agents act through credentials. Each agent should have its own identity, limited permissions, and a documented owner. Shared accounts make accountability difficult.

Permissions should match the smallest set of actions required for the assigned task. An assistant that summarizes support cases does not need authority to delete records. A coding agent does not need unrestricted production access.

Organizations also need a current inventory. Teams cannot govern models, plugins, and data connections they do not know exist. Procurement records alone will miss browser tools and employee-created integrations.

An inventory should record the model provider, business owner, data sources, connected tools, intended users, and decision authority. It should also note whether outputs receive human review.

For knowledge-heavy work, companies can reduce exposure by keeping source material within approved systems. A controlled AI knowledge base can preserve access boundaries while helping teams retrieve relevant context.

That choice does not eliminate AI risk. It provides a clearer data path than copying sensitive material among unrelated consumer services. Clear ownership and permission enforcement still determine the result.

The goal is not to block every experiment. Excessively broad restrictions can drive employees toward unsanctioned tools. Governance works better when approved options remain useful and accessible.

What the Headline Does Not Prove

Surveyed concern measures perceived exposure, not the actual frequency or financial impact of AI incidents.

The headline invites a simple conclusion: AI has become more dangerous than ransomware, malware, or phishing. The available evidence does not support that claim.

Thales asked respondents about concerns related to generative AI and separately reported observed attack categories. Those measurements answer different questions and cannot form a direct risk ranking.

A concern survey captures uncertainty, attention, and expected consequences. Incident data measures events that organizations detected and classified. Neither automatically represents total loss.

Respondents may rank AI highly because its boundaries remain unclear. A familiar threat can feel more manageable even when it causes greater measurable damage.

Novelty can also influence answers. Security leaders receive frequent questions about AI from boards, customers, regulators, and employees. That visibility can elevate perceived risk without showing higher incident volume.

Vendor-sponsored research requires additional care. Thales sells cybersecurity and data protection products, giving the company a commercial interest in AI security spending. S&P Global Market Intelligence 451 Research conducted the survey, but readers should still examine its framing.

This does not invalidate the findings. It means the percentages should support a narrow conclusion: enterprises report high concern and are directing resources toward AI-specific security.

The data also comes from multiple countries and industries. A bank using agents for customer transactions faces different consequences than a manufacturer testing an internal writing assistant.

Aggregate percentages can hide those differences. Risk depends on data sensitivity, automation level, user population, regulatory duties, and the model’s authority to act.

Companies should therefore avoid copying a universal AI security checklist. A low-impact drafting tool does not require the same controls as an agent that changes customer accounts.

Another uncertainty involves incident classification. An attacker might use AI to write a phishing message, but the organization may record the event as phishing. AI assisted the attack without becoming the reported category.

The reverse can also occur. A conventional permissions mistake inside an AI application might receive an AI label because the new interface made the failure visible.

Researchers need consistent definitions before comparisons become reliable. They must distinguish attacks using AI, attacks against AI systems, and failures caused by approved AI use.

NIST’s agent security analysis found broad agreement that fundamental cybersecurity practices remain relevant. Respondents also said those practices need adaptation for agent security.

That is a more useful framing than declaring traditional cybersecurity obsolete. AI inherits familiar infrastructure risks while adding new paths for instruction, access, and autonomous action.

There is also a danger in shifting budgets too quickly. Companies still need patching, multifactor authentication, backups, email security, and tested recovery plans. AI controls cannot compensate for neglected foundations.

Attackers frequently exploit known weaknesses because those methods remain effective. Adding an AI monitoring layer above weak identity controls can create the appearance of progress without reducing basic exposure.

Executives should ask how each investment changes a measurable outcome. Useful measures include unauthorized data access, high-risk agent actions, policy violations, and time required to contain an AI-related incident.

Security teams should test claims from vendors under realistic conditions. A product that detects obvious prompt injection may fail against instructions hidden in business documents or encoded across several steps.

Red-team exercises can expose these weaknesses. An AI red team tests how a system responds to manipulation, unsafe requests, excessive permissions, and unexpected data.

Testing must include the complete application rather than the model alone. A safe model can become dangerous when connected to broad tools. A weaker model can remain low risk inside a tightly limited workflow.

Human review is also not a universal answer. Reviewers can become a rubber stamp when systems generate too many decisions or when deadlines reward speed.

The right control depends on consequence. Low-risk content can use sampling. High-impact actions should require explicit approval, independent validation, or a technical limit that prevents autonomous execution.

AI Governance Is Moving Into the Boardroom

AI risk has become a governance question because technical controls cannot resolve unclear accountability or conflicting business incentives.

Public disclosures show how quickly the issue has expanded. The Conference Board found that S&P 500 companies mentioning AI risks rose from 12% in 2023 to 83% in 2025.

Its governance research also found that 58% identified cybersecurity and data breaches as their most significant AI-related risk. Fewer than 10% of surveyed executives said their companies were fully prepared for AI regulation.

Risk disclosures do not confirm that incidents occurred. Companies use filings to describe possible material threats, and legal caution can encourage broad language.

Still, the change signals that AI has moved beyond innovation teams. Boards must now consider oversight, escalation, and management accountability.

The board’s role is not to approve individual models. Directors need to verify that management understands where AI affects products, operations, employees, and customers.

They should also know which deployments can make consequential decisions. An assistant that drafts internal text differs from an agent that updates prices, moves money, or changes access permissions.

Management reporting should connect technical signals to business impact. Model test scores mean little without an explanation of the decisions the system supports.

A useful report might show how many AI systems can access confidential data. It could identify agents with write permissions, unresolved high-risk findings, and exceptions awaiting review.

Boards should also examine concentration risk. Several internal applications may depend on one model provider, identity service, or retrieval platform. A single failure can then affect multiple business functions.

Third-party dependencies complicate assurance. An enterprise may secure its own application while relying on a provider that changes model behavior, retention terms, or integration features.

Contracts can establish notification, audit, and data-handling duties. They cannot prevent every technical change. Teams still need monitoring and contingency plans.

Regulation adds another source of pressure. Different jurisdictions classify AI systems by purpose, sector, and potential harm. A multinational company may face overlapping privacy, cybersecurity, consumer protection, and AI-specific requirements.

Compliance should not become the sole definition of safety. A system can satisfy documentation requirements while retaining excessive permissions or producing unreliable decisions.

Conversely, a technical team can reduce immediate security risk without addressing legal duties around transparency, discrimination, or intellectual property.

That intersection explains why AI fear has surpassed any single familiar threat in some surveys. The risk is not one attack method. It is a governance problem spanning the technology’s full lifecycle.

Organizations need clear gates before deployment, but they also need continued review. Models, data, users, and integrations change after an initial approval.

Monitoring should detect unusual tool calls, unauthorized retrieval, abnormal data movement, and changes in output quality. Logs must show which identity initiated each action and which sources influenced it.

Incident plans should include AI-specific scenarios. Teams need procedures for disabling an agent, revoking credentials, preserving prompts, and identifying affected data.

They must also determine when an unreliable output becomes a reportable incident. That decision may involve security, privacy, legal, and operational leaders.

Training should reflect employee roles. General warnings about confidential data are easy to ignore. Developers, sales teams, analysts, and executives encounter different failure modes.

A developer needs guidance on generated code and dependencies. A salesperson needs rules for customer data. An executive needs to recognize deepfake impersonation and manipulated decision material.

Effective governance therefore makes safe behavior easier. Approved tools should offer enough value that employees do not need unofficial alternatives for routine work.

Three Signals Will Show Whether Enterprise Defenses Are Catching Up

The next phase will be measured through agent permissions, verified incident data, and evidence that governance changes deployment decisions.

The first signal is narrower agent access. Enterprises should begin reporting how many AI agents have unique identities, limited permissions, and human approval for consequential actions.

This measure goes beyond counting approved applications. It tests whether companies understand the authority they are granting to software.

Progress will be visible when organizations replace shared credentials and unrestricted connectors. Failure will appear through agents that inherit broad employee or administrator privileges.

The second signal is better incident classification. Security reports need to separate AI-assisted attacks, attacks against AI systems, and failures caused by internal AI use.

Reliable categories would let companies compare frequency, severity, and control effectiveness. They would also test whether current fear matches observed harm.

A rise in reported incidents would not automatically mean defenses failed. Better detection often produces higher numbers before it produces lower losses.

The third signal is whether governance changes real deployments. Policies matter only when they restrict data, reduce authority, delay unsafe releases, or require additional testing.

The strongest evidence will come from documented scope changes. A company might remove an agent’s ability to send messages, limit retrieval sources, or retain human approval for financial actions.

A weaker signal is the creation of another oversight committee without operational authority. Governance that cannot change a launch decision will struggle to control business pressure.

Companies should also watch how cyber insurers and regulators treat AI-connected incidents. More specific requirements would force organizations to document controls and distinguish claims from tested capability.

The essential lesson is not that AI has defeated cybersecurity. It is that enterprises are connecting probabilistic systems to valuable data and trusted business tools faster than controls are maturing.

That imbalance explains the fear. Malware, phishing, and ransomware are dangerous, but their operating patterns are familiar. AI introduces uncertainty inside workflows that companies actively want to expand.

Security leaders now need to preserve basic cyber hygiene while adding model evaluation, agent identity, data controls, and cross-functional accountability. Neglecting either side creates an avoidable gap.

For technology buyers, developers, and knowledge workers, the practical question is direct: does an AI tool receive only the information and authority needed for its task?

Ask that question before the next integration goes live. Record the answer, test the boundary, and decide who can stop the system when it behaves unexpectedly. That evidence will matter more than another broad promise that an organization uses AI responsibly.