Why This Is Different From Traditional AI Risk

Classic AI risk conversations tend to focus on data: leakage, mishandling sensitive inputs or generating incorrect output. Those still matter, but they are not the primary concern in environments where the workflow can take actions. The more consequential risk is that an AI-enabled system can be placed inside trusted processes—where it can reach sensitive systems, run code and interact with privileged interfaces.

In that world, the “attack surface” is not only the model. It is the entire set of integrations: tool connectors, automation permissions, identity tokens and execution environments. If an attacker can influence what the workflow does, they can potentially achieve results through legitimate pathways, rather than deploying overtly malicious software. ​​

Where AI-Enabled Workflows Break Down

There are a few weaknesses to keep an eye on here. One problem I've observed involves prompt injection, where instructions are manipulated so the system performs an unsafe action or reveals sensitive information. A related issue along these lines is indirect prompt injection, where harmful instructions are hidden inside content the system is expected to process—documents, tickets, web pages or other inputs—so the workflow follows malicious guidance while appearing to operate “normally.”

Another set of weaknesses involves permissioned action. If a workflow can misuse tools within its allowed scope, if decision-making is over-trusted during autonomous execution or if high-impact steps are not gated with validation, attackers do not need advanced malware. They can win by controlling the order and selection of actions the workflow takes. ​

Why Agents Are Such Attractive Targets In Practice

Orchestration agents centralize access by design. They commonly touch source code, infrastructure tooling, APIs, internal documents and cloud resources. Many also run continuously and hold broad privileges because they are expected to be “helpful” across many tasks.

That’s why the risk is less about whether an attacker “compromises the model” and more about whether they can steer a workflow that already has reach. In a virtualized environment, that reach can translate into privileged operations inside virtual machines and easier movement across workloads. ​

How Attackers Look For Leverage Around AI

As organizations wire AI into real tools, attackers have more places to apply pressure.

A common leverage point is the software supply chain—libraries, plugins, dependencies and other artifacts that influence what tools install and execute. If automation can fetch dependencies or run code with minimal friction, each integration effectively expands what the organization “trusts” by default.

A second leverage point involves credential exposure through normal workflows. AI-assisted development and operations can accidentally move secrets through logs, code or automation steps—or can access API tokens during execution. If an attacker can cause a workflow to retrieve or use a secret as part of an approved process, the activity can look legitimate, even when the outcome is harmful.

A third leverage point is runtime exploitation. When environments are misconfigured or vulnerabilities exist, AI-enabled execution can become a pathway to exploit conditions in runtime systems. For many security teams, the primary concern has shifted: The risk is no longer the model's output, but the workflow's ability to execute actions with approved access

Why Virtualization Raises The Stakes

Virtualization centralizes operational value. Many organizations run major portions of their business as virtual machines managed through centralized tooling and shared infrastructure. That concentration is why virtualization is efficient—and also why the blast radius can be large when a privileged workflow is abused.

AI adoption can amplify this by accelerating automated execution, increasing the number of workflows that operate with elevated privileges and expanding the use of infrastructure APIs and tokens. Even if attackers never “target the hypervisor” directly, the combination of privileged automation plus centralized infrastructure can make deeper compromise easier once persistence is established inside virtual machines. ​

What A Practical Defense Posture Looks Like

A defensible posture starts by governing what AI systems are permitted to do, not only what they can access. Organizations should explicitly define where autonomous execution is allowed, which tools an agent may invoke and what privilege boundaries must not be crossed without approval.

From there, reduce your blast radius by tightening credential scope, narrowing permissions for agent-connected identities and limiting access to management interfaces in virtualized environments. If an attacker succeeds in steering one workflow, the goal is to ensure that success does not automatically translate into broad control.

Finally, monitoring needs to capture context, not just activity. When high-impact actions can be executed via legitimate channels, defenders need to know which workflow initiated the action, which identity was used, what tool was invoked and what sequence of steps led to the change. ​

Final Thoughts

As AI agents become more integrated into operational workflows, they create new pathways to sensitive systems precisely because they are designed to be trusted and capable. The key question is not whether AI will attack your virtual infrastructure, but whether enterprises will place guardrails around AI-enabled execution before automation becomes an easy way for attackers to turn valid access into outsized impact. ​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?