The AI You Didn’t Approve Is Already Running In Your Environment

Ask a security leader which AI vendors their organization has vetted, and most can produce a list without much effort. Procurement ran its process. Legal reviewed the contract. Somewhere there’s a spreadsheet with a risk score attached to every approved tool.

Ask a different question – which AI is actually running on the endpoints in their environment right now – and the room tends to go quiet.

That second question is the one that should keep CISOs up at night, because it’s the one almost nobody in the industry can answer with confidence. Roughly 51 percent of organizations already run AI agents in production.

Gartner projects that 40 percent of enterprise applications will embed AI agents by the end of 2026, up from just 5 percent in 2025 – an eightfold increase in a single year. Every one of those agents has to execute somewhere, and it’s executing on laptops, servers, and developer workstations: precisely the terrain where the standard security stack has the least visibility into what AI is actually doing.

This is not a hypothetical governance gap. It’s a live one, and it’s the reason I’ve been paying close attention to a new category of endpoint control emerging around AI usage – most recently from Morphisec, whose AI Usage Control module reached general availability on July 14, 2026, and which the company is demonstrating this week at Black Hat USA 2026 in Las Vegas.

Two Risks Wearing the Same Coat

For CISOs building or refreshing an AI governance program, it helps to separate the exposure into two distinct problems, because most enterprises are carrying both simultaneously and treating them as one.

The first is shadow AI.

It shows up when employees paste confidential data into a consumer chatbot, when a developer installs a local language model that never touches the corporate network, when a command-line agent or an IDE plugin reads and writes files directly on a device, or when a browser extension calls an AI service nobody on the security team has reviewed.

None of this traffic routes through a gateway, which means none of it shows up in a CASB report or a proxy log. It’s invisible by construction, not by evasion.

The second is compromised AI, and for my money it’s the more uncomfortable of the two. This is the scenario where an organization does everything right on paper: it approves an enterprise agent, grants it the permissions it needs to be useful (a heavily constrained agent is generally a useless one), and moves on. Then an attacker hijacks that agent through a poisoned prompt or a supply chain compromise.

At that point, the malicious instructions carry legitimate, organization-issued credentials into a process the organization itself approved. Nothing about the resulting activity looks anomalous, because structurally, nothing is anomalous. The agent is doing exactly what it was authorized to do – it’s just been told to do it by the wrong party.

“That’s the scenario that keeps me up at night,” Brad LaPorte, Chief Marketing Officer at Morphisec, told me. “It looks safest on paper, right up until it isn’t.”

Firewalls, identity platforms, and EDR tools were built to watch people and devices. None of them were designed to answer a more specific and more urgent question: what is this AI process permitted to reach, execute, and send?

The Attacks Are Already on the Record

Security teams have earned the right to be skeptical of vendor threat marketing, particularly anything wrapped in the word “AI.” So it’s worth being precise about what’s actually documented rather than projected.

ESET researchers identified PromptLock, a strain of polymorphic ransomware that connects to a local Ollama endpoint and generates fresh code at runtime. Every execution produces different code, which defeats static signature matching by design – and because the model call never leaves the machine, there’s nothing on the wire for a network tool to inspect.

Google Threat Intelligence tracked QUIETVAULT, delivered through a compromised npm plugin. What stands out about this case is what the attacker didn’t have to build: no custom tooling, no bespoke exfiltration framework. The malware simply weaponized the AI command-line utilities developers had already installed on their own machines, using them to recursively scan for and exfiltrate GitHub tokens and crypto wallet credentials.

Then there’s GTG-2002, in which an autonomous agent independently selected exfiltration targets, analyzed victims’ financial data, and set ransom demands ranging from $75,000 to $500,000 across 17 confirmed organizations. The agent, not a human operator, made the pricing decisions.

Not every incident on this list involves an adversary at all. In one widely discussed case, a coding agent instructed to “clean up old records” interpreted the instruction at maximum scope and deleted a production database along with every backup, in under ten seconds.

No malware.

No attacker.

Just an agent doing precisely what it was told, faster than any human could realistically intervene.

The financial and operational loss was identical either way. That’s the detail worth sitting with as you think about where this fits in your risk register: intent doesn’t change the blast radius.

Every AI tool, account, host, and MCP connector on the endpoint, including shadow AI, discovered and inventoried automatically.

Why the Existing Stack Doesn’t See This

It’s not that CISOs have been negligent about AI risk. It’s that the tools already deployed across most security stacks were architected before this problem existed, and they have a structural blind spot rather than a configuration gap.

Cloud gateways, CASBs, and enterprise browser tools can only govern traffic that actually routes through them. Local language models, command-line agents, and IDE-embedded AI assistants fall entirely outside that vantage point – not because of a missing feature, but because of where those tools sit in the network path. That’s an architectural limit. It doesn’t close with a product update or a policy change; it closes only if you move the control point.

Endpoint detection platforms are closer to the action but have a different problem. They can see the process running, but most can’t distinguish a coding assistant from an arbitrary shell script, have no per-tool behavioral baseline, no native concept of a Model Context Protocol (MCP) connector, and generally classify activity after the fact rather than intervening at the point of execution.

This is how Brad put it when I asked him about the gap: “You cannot govern what you cannot see, and right now most enterprises cannot see the AI running on their own endpoints. That AI lives below the network and beyond identity tools, outside the controls teams already own.”

That’s the gap Morphisec built its AI Usage Control module to close, and the architectural choice behind it is worth understanding regardless of which vendor a CISO ultimately evaluates.

Putting the Control Where the AI Actually Runs

AI Usage Control runs inside the Morphisec Protector – the same agent Morphisec customers already deploy for anti-ransomware protection, across Windows, Linux, and macOS. There’s no second agent to deploy, no proxy to route through, and no cloud relay in the path.

That decision matters more than it might sound, because it directly addresses the architectural limit described above. The AI creating the most risk in most environments is the AI that never crosses a network boundary in the first place. By sitting on the endpoint itself, the control works offline, it works on air-gapped systems, and – critically – it can enforce before an action completes rather than flagging it afterward.

“We built this to sit exactly where the AI runs, not where we wished it ran,” is how LaPorte explained the thinking behind that choice.

The AI Blast Radius view maps which accounts, hosts, MCP connectors, and critical resources each discovered AI tool can reach.

Available today, the module automatically inventories AI tools, accounts, agents, browser extensions, LLM services, and MCP connectors – shadow AI included – and builds that blast radius view showing exactly which accounts, hosts, and critical resources each AI tool can reach.

It maps every AI action back to a specific user, account, and device, which lets a security team enforce policy on which AI may run and for whom. It generates audit trails and enforcement logs mapped to the EU AI Act, NIST AI RMF, ISO 42001, and SOC 2 – a detail that matters a great deal to anyone who has had to defend an AI governance program to an auditor or a board. And it can terminate AI agents and tools that fall outside sanctioned policy.

To Morphisec’s credit, the company has been unusually clear about what’s shipping versus what’s still on the roadmap.

In the second half of 2026, the plan calls for granular runtime guardrails that block a specific risky action – reaching for credentials, writing to backup locations, spawning a remote execution tool – while leaving the rest of an agent’s approved work untouched.

Local anomaly detection is also planned, giving each AI tool its own behavioral baseline and flagging file operation spikes or suspicious execution chains in real time. In a category where vendors routinely blur “shipping” and “coming soon,” drawing that line clearly is worth noting.

The Privacy Trade-Off Most Governance Tools Get Backwards

There’s a second architectural decision in this product that I think deserves more attention than it usually gets, because it touches a problem CISOs in regulated industries know well.

Most AI governance tools work by inspecting content – reading prompts, uploads, and responses, then classifying risk based on what they find. That approach solves one problem and quietly creates another: the tool built to reduce risk becomes a new repository of the most sensitive text in the company, which is its own compliance headache, particularly under European privacy regulation and in organizations with active works councils.

Morphisec’s approach governs by what a tool is and where it sends data, not by what’s inside the data.

“We govern by what a tool is and where it sends data, not by what’s inside it,” LaPorte explained. “We can tell a security team that a coding agent just reached for a credential directory. We cannot tell them what anyone typed into it.”

That’s a deliberate design choice, and it turns what is often a difficult privacy conversation into a short one.

The Standard Is Catching Up to This Argument

The industry has started writing formal rules for enterprise AI, and it’s worth knowing where they stand relative to this approach. AIUC-1, an independent certification standard developed with input from more than 100 Fortune 500 CISOs, launched in 2025 and has since been integrated into the Cloud Security Alliance’s STAR registry, with early certifications earned by vendors including ElevenLabs, UiPath, and Intercom.

Notably, AIUC-1 is the first standard to require execution-level safeguards – meaning it verifies what an agent actually does, rather than simply filtering what it’s asked to do. Morphisec maps its capabilities to controls across all six of the standard’s pillars, but LaPorte is careful to draw a distinction between what certification covers and what it doesn’t.

“Standards like AIUC-1 are proof that AI trust now requires evidence rather than assurances, and that is healthy for everyone,” he said. “But certification covers the agent you buy. It cannot govern the copilots, local models, and autonomous agents your workforce actually runs on endpoints every day. Put simply: AIUC-1 certifies the AI you buy. Morphisec AI Usage Control governs the AI you run, and hands you the evidence to prove it.”

Morphisec AI Usage Control is a Morphisec product. It is not affiliated with, endorsed by, or certified under AIUC-1, the certification standard issued by The Artificial Intelligence Underwriting Company.

Brad LaPorte, Chief Marketing Officer, Morphisec.

Gartner’s own 2026 technology trends make a related wager, projecting that preemptive security will account for roughly half of all security spending by 2030.

Whether or not that specific number holds, the direction is consistent with what every CISO evaluating AI risk should already suspect: detection-after-the-fact is not going to be sufficient for a category of risk that can execute irreversible actions – deleting a database, exfiltrating credentials – in seconds.

What This Means for Your Program, Practically

I’d rather leave a CISO with something actionable than with another vendor pitch to file away, so here’s how I’d translate this into program work regardless of which product you end up evaluating.

Start with inventory, not policy.

You cannot write a sane AI usage policy before you know what AI is actually running in your environment, including the shadow AI nobody asked permission to install. That inventory needs to cover local LLMs, CLI agents, IDE plugins, browser extensions, and MCP connectors, not just the enterprise tools that went through procurement.

Map blast radius before you write allow-lists.

Once you know what’s running, the next question is what each tool can reach: which accounts, which hosts, which credentials, which critical systems. This is the same exercise your team already runs for identity and access; it just hasn’t been extended to AI processes yet.

Treat compromised AI as a distinct threat model from shadow AI.

They require different controls. Shadow AI is largely a visibility and policy problem. Compromised AI is a containment and least-privilege problem for tools you already approved, and it’s the scenario your incident response playbooks are least likely to cover today.

Get ahead of the audit trail question now.

Whatever framework your organization is tracking against – EU AI Act, NIST AI RMF, ISO 42001, SOC 2, or an internal board mandate – you will eventually be asked to produce evidence of AI governance controls, not just a policy document. Building the logging and mapping now is considerably cheaper than reconstructing it after an incident or an audit finding.

And keep asking the blunt question.

Which AI is running on our endpoints right now? If your team can’t answer that with confidence today, that answer – not the vendor landscape – is the actual gap in your program.

Worth Watching

Plenty of vendors have announced AI governance products in the past year, and most of them ask the buyer to add something first: a gateway to route through, a browser to standardize on, a new agent to deploy, a platform to consolidate onto. Coverage arrives only after the adoption project completes.

Morphisec inverted that sequence by extending an agent already sitting on millions of endpoints – using the same prevention engine that already stops ransomware – into a category most of the market is still trying to reach from the network.

For an organization already running the Morphisec Protector, adding AI Usage Control is a configuration change rather than a new deployment project, which is a meaningfully different conversation for any CISO weighing time-to-value against an already-crowded 2026 roadmap.

It’s also worth noting how closely the AI attack patterns track the ransomware attack patterns CISOs already model for: pre-encryption reconnaissance, backup deletion, living-off-the-land binary abuse, credential theft.

These aren’t new objectives. AI simply pursues them faster than human response time can match, which is part of why 44 percent of all data breaches now involve ransomware and 87.6 percent of ransomware claims involve double extortion.

Morphisec is demonstrating AI Usage Control this week at Black Hat USA 2026 at the Mandalay Bay Convention Center, and the company’s white paper, “The AI Security Gap: Why Detection Fails in the Age of Autonomous Threats,” is available through the Morphisec AI Hub for CISOs who want the fuller technical treatment.

But regardless of which vendor you ultimately look to for this control, the question underneath all of it belongs on every CISO’s agenda this year: what AI is actually running in your environment, and who – or what – is really in control of it?

 

About the Author

Pete Green is the CISO of CyberDefense Publishing and co-author of “The vCISO Playbook: How Virtual CISOs Deliver Enterprise-Grade Cybersecurity to Small and Medium Businesses (SMBs)”. With over 25 years of experience in information technology and cybersecurity, Pete is a seasoned and accomplished security practitioner.

Throughout his career, he has held a wide range of technical and leadership roles, including LAN/WLAN Engineer, Threat Analyst, Security Project Manager, Security Architect, Cloud Security Architect, Principal Security Consultant, Director of IT, CTO, CEO, Virtual CISO, and CISO.

Pete has supported clients across numerous industries, including federal, state, and local government, as well as financial services, healthcare, food services, manufacturing, technology, transportation, and hospitality.

He holds a Master of Computer Information Systems in Information Security from Boston University, which is recognized as a National Center of Academic Excellence in Information Assurance / Cyber Defense (CAE IA/CD) by the NSA and DHS. He also holds a Master of Business Administration in Informatics.



Source link