Securing AI on Endpoints: How to Govern AI Tools, Coding Agents, and MCP Connections

Workforce AI security spent the last two years focused on the browser, watching what employees paste into ChatGPT and blocking unapproved SaaS tools. That focus made sense when AI meant a chat window but it doesn't hold up anymore.

‍

Coding agents, connected skills, and MCP servers now run directly on employee laptops with real access to codebases, credentials, and internal systems, and most security teams have no visibility into what happens on that endpoint once an agent starts acting on its own.

‍

Here is what that gap looks like in practice.

A developer on your engineering team connects Claude Code to an internal Jira MCP server so the agent can pull ticket context directly into its coding session. It works exactly as intended for three weeks. Then a routine support ticket arrives with a line of text buried in its body instructing the agent to fetch a script from an external URL and run it as part of resolving the issue. The developer never reads that line, but the agent does, pulling the script and exfiltrating the repository's .env file to an attacker-controlled endpoint before anyone notices the session ever ran.

‍

Every part of that chain looked legitimate at the time it happened. The MCP connection had gone through approval, the coding agent was one the security team had already sanctioned, and the ticket read like every other ticket sitting in the queue that week. The failure happened somewhere security teams have historically had almost no visibility into, aka where AI tools now read, reason, and act on data and system access that used to require a human in the loop.

‍

That gap is what this article addresses, walking through how security teams discover, govern, and protect the AI tools, coding agents, and MCP connections running on every laptop in the company, and what a real endpoint security program looks like in 2026.

‍

What Does Securing AI on Endpoints Mean?

‍

Securing AI on endpoints means governing and protecting every AI tool and agent that runs directly on an employee device, extending beyond the AI activity that passes through a browser tab. 

‍

That includes coding agents like Claude Code and Cursor, desktop and browser extensions for SaaS AI tools, and the MCP servers and skills those agents connect to for extended capability. 

‍

For example, with Lasso, it covers:

• Knowing which AI tools and agents exist on a device
• Controlling what they are allowed to access
• Protecting the data that flows through them
• Monitoring whether their behavior matches what they were authorized to do

‍

AI Endpoint Security vs. Traditional Endpoint Security

‍

Traditional endpoint security tools such as EDR and MDM protect the device from malware and unauthorized processes. They were not built to evaluate what a legitimate, signed application is doing on the inside. 

‍

Claude Code or Cursor running on a laptop looks like an approved application to an EDR agent. What the EDR agent cannot see is which MCP servers that tool is connected to, what data it just read into its context window, or whether the action it's about to take with the developer's own credentials matches its intended purpose. 

‍

AI endpoint security operates a layer above process and file monitoring, evaluating the intent and scope behind an action rather than simply whether a binary is malicious.

‍

Why Endpoints Have Become the Hardest AI Security Problem to Solve

‍

Security teams have felt this shift happen in the space of a year. According to Latio Tech's 2026 AI Security Market Report, 45% of security teams now name endpoint agents like Claude and Codex as their primary AI security concern, ahead of first-party agents, browser-based AI, and hosted agents combined. 

‍

Budget has followed suit, with dedicated AI security spending jumping from 8% of teams a year ago to 37% today. The report frames this shift as AI security's second era, moving from controlling unapproved activity in the browser to controlling unapproved activity on the endpoint itself.

‍

Ungoverned AI Usage Happens Both on Employee Endpoints and in Cloud Deployments

‍

Shadow AI used to mean an employee pasting data into a chat window. It now means a developer wiring an agent into internal systems without security ever seeing the connection get made. Both the sanctioned and unsanctioned versions of this activity run locally, outside the network chokepoints most DLP and CASB tools were built to monitor.

‍

AI Coding Agents Access Codebases, Credentials, and Internal Systems Autonomously

‍

Coding agents operate with the developer's own permissions, including repository access, API keys, cloud credentials, and internal tooling. When an agent is compromised or manipulated, it doesn't need to escalate privileges because it already has them. 

‍

Indirect prompt injection is the mechanism that makes this dangerous in practice, where instructions are hidden inside a file, a ticket, or a pull request description that a human would never act on, but that an agent processes as trusted context. 

‍

The market report cites the same pattern, hiding a task inside a SOC alert to redirect an AI SOC tool, as an emerging technique that direct prompt injection defenses at the model layer don't catch.

‍

Third-Party SaaS AI Tools Process Sensitive Corporate Data Without IT Review

‍

Employees connect ChatGPT, Gemini, and dozens of narrower AI tools to their daily workflows without a procurement cycle. Each connection is a new place sensitive data can leave the organization's boundary, evaluated by none of the policies that govern email or file sharing.

‍

MCP Server Connections Create Invisible Supply Chain Exposure From the Desktop

‍

This is where the risk compounds fastest. MCP servers are commonly distributed as NPM packages, and the supply chain attacks that have hit the ecosystem read like a fast-forward of everything open source security learned the hard way. 

‍

Researchers documented postmark-mcp, a package that spent fifteen versions building legitimacy before silently adding a single line of exfiltration code. A critical remote code execution vulnerability in core MCP infrastructure, tracked as CVE-2025-6514 with a CVSS score of 9.6, affected infrastructure used by hundreds of thousands of developers. 

‍

Separately, security researchers identified skills capable of poisoning an agent's persistent memory files, enabling behavioral changes that survive across sessions. Each of these attacks needed nothing more than an unmonitored connection already in place, with no user interaction required at all.

‍

What Needs to Be Secured on Enterprise Endpoints

‍

‍

Key Capabilities Needed to Secure AI on Endpoints

‍

AI Discovery and Inventory: Visibility Into Every AI Tool and Agent on Employee Devices

‍

Governance starts with an accurate inventory, and most organizations don't have one. Discovery needs to surface every AI tool and coding agent running on a device, along with the MCP servers and skills each one is connected to, without relying on employees to self-report what they've installed.

‍

MCP and Skills Security: Governance of Third-Party Tool Connections That Extend Agent Capabilities

‍

This is the capability most endpoint security programs are missing entirely, and it deserves the most attention. Every MCP server and skill an agent connects to should be treated as a third-party dependency, the same way a security team would treat a new open source package entering a codebase. 

‍

That means evaluating what a skill actually does at runtime rather than trusting its static description. Skill detonation means running a skill in a controlled environment to observe its actual network and process behavior. This catches what static analysis misses, since a skill can fetch external instructions or alter its behavior after it has already been approved. 

‍

It also means evaluating the intent behind every tool call an agent makes through an MCP connection, beyond whether the connection itself is authorized. An approved MCP server can still be used to request an unauthorized action, the way the Jira connector in the opening example was.

‍

A simplified view of what that evaluation looks like at the point of a tool call:

‍

{
  "event": "mcp_tool_call",
  "server": "jira-mcp-connector",
  "tool": "fetch_and_execute",
  "requested_action": "download_and_run(url)",
  "intent_check": {
    "declared_scope": "read ticket metadata",
    "requested_scope": "execute remote script",
    "alignment": "fail",
    "action": "block"
  }

‍

The tool call itself was permitted, but the action it requested fell outside the ticket's declared scope. Catching that distinction is what MCP governance actually requires.

‍

AI Access Control: Policies Governing Which Tools Employees Can Use and What Data They Reach

‍

Access control for AI tools should follow the same model that governs access everywhere else in the organization, where a person's role and identity determine which tools and data they are allowed to reach. A finance analyst's AI tool access should look different from a developer's, and a developer's coding agent should not have the same reach into production systems as it has into a sandbox repository.

‍

Sensitive Data Protection: Preventing Sensitive Data From Entering AI Tool Prompts

‍

Prompts are a data loss channel, and they should be governed like one. That means detecting sensitive data such as source code, credentials, and customer records before it enters a prompt, and applying that protection consistently across every AI tool employees use, sanctioned or not.

‍

Risky AI Usage Detection: Identification of Policy Violations, Shadow AI, and Unsafe Behavior

‍

Even with access control and data protection in place, teams still need a way to catch what those controls miss, such as an employee using an unauthorized tool, an agent behaving outside its historical pattern, or a usage spike that doesn't match a role's normal activity. This is where behavioral baselining earns its keep, flagging deviation rather than waiting for a hard policy violation.

‍

Content Moderation: Acceptable Use Policy Enforcement Across Every AI Interaction

‍

Acceptable use policies need enforcement at the point of interaction, rather than a policy that sits written down in a wiki nobody reads. That means applying consistent content and usage policies across every AI interaction on the endpoint, regardless of which tool the interaction happens to run through.

‍

Agentless vs. Agent-Based AI Endpoint Security

‍

‍

Latio Tech's report puts it plainly, noting that the strongest approaches support both deployment methods, using agentless coverage for immediate visibility while an agent-based approach matures alongside it. Treating this as an either-or decision is what slows most programs down.

‍

How Security Teams Are Getting AI Endpoint Governance Right with Lasso

‍

Start With Discovery Before Enforcing Any Policies

‍

Writing a usage policy before you know what's actually running on employee devices means writing a policy for the AI usage you assumed existed instead of the one that does. Discovery has to come first.

‍

Apply Sensitive Data Policies to AI Prompts the Same Way You Apply Them to Email

‍

Most organizations have mature DLP policies for email and file sharing and nothing equivalent for AI prompts, even though prompts now carry more sensitive context, source code, and internal data than either. Extending the same rigor to prompts closes an obvious and avoidable gap.

‍

Treat Every MCP Server Connection as a Supply Chain Risk Requiring Governance

‍

An MCP server should be governed the way any external dependency is, evaluated before approval and monitored continuously afterward, because approval at install time doesn't guarantee the same behavior six versions later.

‍

Build Usage Baselines Before Restricting Tools

‍

Blocking tools outright before understanding how they're actually being used tends to push usage further underground rather than eliminating it. Baselining normal behavior first gives teams something to measure deviation against, and gives employees a workable path to safe adoption rather than a blanket restriction.

‍

How Lasso Secures AI on Endpoints: Agentless and Through Your Existing Stack

‍

Delivers Full AI Endpoint Visibility Agentlessly, With No Software Installed on Employee Devices

‍

Lasso governs AI activity on employee endpoints through an agentless approach, so security teams get visibility into AI tools, coding agents, and MCP connections from day one instead of waiting on a fleet-wide software rollout.

‍

Connects to Existing Endpoint Agents and Deep Integrations to Extend Coverage Across the Full Stack

‍

Teams that already run EDR or MDM tooling can connect Lasso to that existing stack, extending endpoint coverage through infrastructure they already maintain rather than adding another agent to manage.

‍

Discovers and Inventories Every AI Tool, Coding Agent, and MCP Connection Across the Enterprise

‍

This follows the same discover, assess, protect loop Lasso applies across applications, extended to the endpoint. Every AI tool, coding agent, and MCP or skill connection gets discovered and profiled first, giving security teams a real inventory to build policy against rather than an assumption.

‍

Enforces Access Control, Content Moderation, and Sensitive Data Protection Across Every AI Interaction

‍

Once discovery establishes what's running, Lasso enforces access policy, content moderation, and sensitive data protection consistently across every AI interaction on the endpoint, whether it comes from a sanctioned coding agent or a tool IT never approved.

‍

CPU-Based Guardrails Enforce Policy at the Execution Layer Without Network Dependency

‍

Policy enforcement happens at the execution layer on the device itself, so protection holds even when an agent's activity would not otherwise pass through a monitored network path.

‍

Our Final Thoughts 

‍

On the endpoint, AI tools act directly on systems and data rather than simply generating conversational output. Coding agents run with developer credentials. MCP connections extend what those agents can reach in ways most security teams can't yet see. SaaS AI tools move sensitive data outside every existing DLP policy. 

‍

This is already the primary AI security concern for close to half of practitioners today, and the trajectory is still upward. By 2026, discovery, access control, data protection, and MCP governance form the core of what an AI security program actually has to deliver.