Imagine the next board meeting. The conversation turns to AI. Someone asks the question that is becoming routine. “Which AI tools are running across our environment, and what data are they touching?”

Most security leaders can name their AI providers. They can list the SaaS contracts. They can describe the policy. What they cannot do is produce a defensible inventory of what is actually running at the endpoint. The browser assistants employees signed up for on their own. The IDE plugins developers installed last quarter. The local models someone downloaded over the weekend to experiment with.

That gap is where the next breach disclosure gets written.

This isn’t negligence. It’s a structural gap in the tooling. Endpoint security wasn’t built to surface AI behavior. The controls that govern data at the network layer can’t see what never crosses the wire.

Shadow IT’s faster, more concentrated successor

Shadow IT took years to surface. Employees adopted unsanctioned SaaS. Security teams built the muscle and the tools to discover it, classify it, and govern it. The risk was real. But it was diffuse. A misconfigured spreadsheet in the wrong app was rarely an existential event.

Shadow AI is a different animal.

It compresses the timeline because adoption is frictionless. An employee opens a browser tab. An engineer enables a plugin. A researcher runs a model on a workstation. No procurement cycle. No IT ticket. No installer to flag. The behavior is established before security knows it exists.

It concentrates the risk because each interaction is high-bandwidth. A single paste moves an entire contract draft, a customer file, or a block of source code into a system you don’t control, can’t audit, and can’t claw back. Shadow IT leaked at the edges. Shadow AI leaks in bulk.

Three blind spots on every endpoint

Three categories come up in every conversation with security leaders.

First, cloud and browser-based AI services. The most discussed, the least controlled. Traffic is encrypted. Destinations rotate. The data leaving is pasted by a human, not exfiltrated by malware. DLP does honest work here. It just was never built for a person pasting a contract into a browser tab.

Second, IDE-integrated AI tools. Developer assistants are powerful and popular, and often configured to send code and context to third-party providers. The data crossing that boundary is exactly the data your engineers consider most sensitive.

Third, locally running models. This category grows the fastest and hides the best. A local model doesn’t generate traffic that looks like AI usage. It looks like a process reading local files. CASB doesn’t see it. Network DLP doesn’t see it. EDR sees a process and a file open, but has no way to know what that process actually is.

Keep all of these tools. Each does honest work in the layer it was built for. The gap isn’t quality. It’s location. AI moved onto the endpoint, and the endpoint is the one place where the user, the process, the file, and the destination are visible together, before the data leaves.

Why this is a board question now

A year ago, enterprise AI was a productivity topic. Today it’s a governance topic. Regulators are formalizing expectations. The EU AI Act is rolling out phased obligations. The SEC has signaled interest in disclosure of material AI risk. HIPAA-covered entities face fresh questions about what employees submit to external models. Cyber insurers now ask explicit AI questions on renewal forms.

None of these bodies accepts “we don’t know” as an answer. They expect inventory. They expect policy. They expect evidence that controls are in place and working. The conversation has shifted from intent to demonstration.

What “good” looks like

A defensible answer has four properties.

It’s real-time, not a quarterly survey of self-reported usage. It’s endpoint-resident, not dependent on network traffic that may be encrypted, tunneled, or absent. It’s process-aware, able to tell a sanctioned tool from a local model from a browser tab. And it’s enforceable, connected to policy that can act before sensitive data leaves.

Enforceable is the word that matters. An inventory tells you what happened. Enforcement decides what happens next.

Most stacks deliver one or two of those properties. Few deliver all four. Almost none do it without bolting another sensor onto an already-crowded endpoint.

Where we stand

At Arms Cyber, we’ve spent years building a stealth-driven preemptive security platform. It hides critical data from attackers. It contains threats at the endpoint before they spread. It restores operations without the downtime. The foundation is process-level visibility. Knowing, in real time, which applications are touching which files, and why.

That foundation maps directly onto the AI visibility problem. The same sensor that keeps your data out of reach of ransomware can surface the AI activity your current stack can’t see. Same sensor. New capability. No reboots.

The tools were never wrong. The era moved. AI runs on the endpoint now, and the endpoint is where the answer lives.

We have more to share in the coming weeks. For now, the question stands. Ask it of yourself before someone else asks it of you.

When the board asks what AI is running in your environment, what’s your answer?


Bob Kruse is the Chief Executive Officer at Arms Cyber, where he leads the company’s mission to make ransomware and AI-driven attacks irrelevant. Arms Cyber’s patented Stealth Posture Management platform protects organizations across Windows, Linux, and macOS by making critical data invisible and resilient to attackers and ungoverned AI alike.