Can MSSPs govern AI tools that never hit the Network? Arms Cyber says ‘Yes’

AI governance is moving closer to the endpoint because more AI tools now run on the devices where sensitive data lives. Arms Cyber has launched AI Policy Enforcement, a new capability that helps security teams see and control AI tools, agents, and models running on endpoints. The feature runs through the company’s existing endpoint agent, so customers do not need to roll out a separate tool to start using it.

This is bringing out a growing blind spot in security operations. Many companies already watch cloud AI tools. They may use DLP, CASB, EDR, gateways, or other controls to see when data leaves the business or when employees log into software-as-a-service tools.

But local AI is different. A model can run on a laptop or workstation. A developer assistant can work inside a coding environment. An AI agent can touch files without sending data across the network in a way that older controls can easily inspect.

That creates a simple but significant problem: security teams may not know which AI tools are running, what files they are touching, or whether those files include source code, secrets, customer data, or regulated records.

What Arms Cyber is trying to solve

Customers do not only need a list of AI tools. They need to know what those tools are doing. They also need proof that controls worked when sensitive data was involved. For regulated businesses, that proof may become more important over time. Security leaders are being asked to explain how AI is used, what data it can reach and how policy is enforced. A written policy is not enough if the company cannot show what actually happened on the endpoint.

Arms Cyber is aiming AI Policy Enforcement at three related needs: visibility, enforcement, and compliance reporting.

Josh McCarthy, chief product officer at Arms Cyber, told MSSP Alert that the product is built to cover all three.

“We cover all three governance functions. Visibility: a per-endpoint inventory of the AI agents running, the local models they're driving, and the files and actions they're reaching for. Policy enforcement: scoping what those AI processes are allowed to touch and intervening when they cross a line. Compliance reporting: because every AI-process-to-file access is recorded with full context, partners can hand customers an auditable record of which AI tool accessed which data, when, and in what sequence. This is the evidence chain that regulated customers increasingly have to produce.”

What DLP, CASB, and EDR may miss

MSSPs often help customers monitor endpoints, investigate alerts, and produce reports. If AI activity is happening on the endpoint, those providers need a way to see it clearly. But the most important customer question is: What AI tools are running on my devices, and what data did they touch?

Arms Cyber is not saying DLP, CASB, and EDR have no value. Those tools still play an important role. The issue is that they were built for different parts of the security stack.

DLP and CASB tools often focus on data leaving the company or on cloud tools being used. EDR tools focus on endpoint threats and suspicious behavior. But a local AI model or agent may not look like classic malware. It may also not send data to a cloud service.

McCarthy said that is the gap Arms Cyber is trying to cover.

“What we surface that the traditional trio misses is the local agentic layer that never crosses the network. DLP and CASB are built around egress and SaaS. They see data leaving and cloud tools logged into, which is the comparatively easy, already-watched case. EDR watches for threats, not for AI as a category, so a sanctioned-looking process quietly running a local model isn't on its radar. None of those tools see an agent loading a local model on the device, reading source code or regulated records, and acting on them entirely on-endpoint with nothing leaving the wire. That's the blind spot an MSSP can light up for every customer with one agent.”

One common use case is software development. Developers may use AI coding assistants to help write code, explain code or speed up routine work. Those tools can be useful. But development environments often sit close to sensitive data. A repo may include source code, secrets, .env files, credentials or customer records.

That creates risk if an AI assistant can reach more than it should.

McCarthy explained how Arms Cyber would handle that kind of case.

“We can step through this scenario: A developer points an AI coding assistant at a repo that also contains a secrets file and a directory of customer data. Our enforcement sits below that assistant, in between it and the file system itself, so we see the assistant's file operations as they're performed, rather than inferring activity after the fact from network traffic that, for a local agent, never happens.

Detect: the moment that an assistant process is identified as an AI agent, we capture the full context (the process, its parent, and the exact file path) and record which files it touched and in what order. That alone gives the security team something they've never had: a precise, real-time picture of what an AI tool actually consumed on that machine.
Block: because we operate at the file-access layer, policy is expressed as what an AI process is allowed to reach. You can scope the assistant to sanctioned repositories and deny it the secrets file, the .env, the credential store, or the customer-data directory outright; least privilege is enforced below anything the assistant itself can override. Planted decoy files in sensitive locations act as tripwires: if an AI process opens one, it fires a real-time alert with full process context and can trigger intervention up to terminating the process.
Log: every one of those events becomes a forensic record (which AI process, which file, when, in what sequence, etc.) usable for investigation, governance, and compliance evidence.”

Arms Cyber watches file access by AI processes and does not wait to infer risk from network traffic later. It sees the AI assistant’s file actions as they happen. For MSSPs, this makes AI activity easier to explain to customers. Instead of a vague alert, the provider can show which process acted, which file path was involved, and what policy response occurred.

How Arms Cyber sees the market

Many vendors are now moving into AI governance. Some focus on cloud AI tools. Some focus on gateways and proxies. Others come from insider risk, employee monitoring, or endpoint DLP.

Arms Cyber is trying to separate itself by focusing on local AI activity on the device.

McCarthy said the market has two main groups.

“There are two major approaches to differentiate from. The first is the network- and cloud-centric governance crowd, including AI gateways, proxies, CASB-style controls. They govern destinations: which AI site, which API. That's a comparatively solved and crowded problem, and it's structurally blind to local agentic AI because there's no destination to inspect. We're not trying to win that fight; we're addressing the part of the problem their architecture can't reach.

The second approach is the endpoint insider-risk and eDLP players moving into AI governance. Many of them get there through heavy, often privacy-invasive telemetry, such as screen capture, keystroke and copy/paste monitoring, sentiment analysis, usually via a dedicated agent. Our differentiation is the vantage point and the weight: file and process interception sitting below the AI process, delivered on the same lightweight agent that already does anti-ransomware, so governing local AI doesn't mean another rollout or a performance tax on the exact machines running these models. It's enforcement at the point of file access, not observation after the fact, and it complements EDR/XDR rather than competing with it.

Two more edges: the tripwire/decoy mechanism is purpose-built and already proven against ransomware, now repurposed to catch rogue or misused AI the moment it reaches where it shouldn't; and the stealth capabilities of our product work just as well against AI as they do against ransomware. The honest framing for the market is that we own the local, on-device agentic blind spot (a.k.a. the fastest-growing and least-governed surface) rather than re-litigating the cloud AI governance everyone else is already crowded into.”

Arms Cyber is not trying to be the gateway for every cloud AI app. It is trying to control what happens when AI runs locally and touches files directly. That may also help partners avoid some privacy concerns. Some insider-risk tools rely on broad employee monitoring. Arms Cyber is presenting its approach as file and process control, not screen capture or keystroke monitoring.

Arms Cyber’s AI Policy Enforcement launch shows how quickly endpoint security is changing. The endpoint is no longer just a place to stop malware or ransomware. It is becoming a place to govern AI, control file access, and prove what happened when sensitive data was involved. And this creates a new service opportunity as they can help customers in finding local AI tools, setting least-privilege policies, blocking risky access, and creating audit records.