Glow brand name with a diamond-shaped dotted logo on the left.Symmetrical diamond shape made of smaller dark blue diamond dots on white background.
Glow brand name with a diamond-shaped dotted logo on the left.Symmetrical diamond shape made of smaller dark blue diamond dots on white background.
Home
Resources
BlogEvents & Webinars
Company
AboutCareers
Book a demo
Book a demo
Book a demo

The endpoint is where AI actually lives, and where it breaks

Agents, extensions, and MCP servers have made the endpoint the center of AI risk and turned the agent into a new kind of insider.
Ophir Arie
August 11, 2026
TL;DR
  • AI tools cluster where credentials, code, and sessions already live: the endpoint. In our telemetry, 52% of all enterprise workstations (not just developer machines) already have an AI tool installed.
  • Attack paths now chain through a webpage → an extension → an agent → an MCP server. No single security control watches the whole chain.
  • EDR was built to catch malicious. Agent activity is merely suspicious: the agent is already inside, and every action it takes looks legitimate. It's insider risk in a new form, no malice required.
  • Securing AI requires answering three questions: what's there, what can it do, and what is it allowed to decide.


Glow came out of stealth recently. We founded it on two convictions about the world.

‍
01 AI lets us reimagine endpoint protection.

The shift that let agentic engineering rebuild how software is written can rebuild the defense workflow itself: detection, triage, investigation, and response running as autonomous loops. And the endpoint is the best harness there is for agentic tools.
‍

02 AI lives on the endpoint, but needs a new security model.

For decades, the endpoint ran code under known rules: a binary executed, a signature matched or didn't. Today it hosts agents that interpret instructions, hold live credentials, and decide what to do next. That's a different security problem, and the tooling we rely on was never designed for it.

This post makes the case for the second, and introduces the layer of software it created, which most organizations cannot currently see:

The AI estate /noun/

Everything AI-related that lives on an endpoint: agents and CLIs, browser extensions, IDE plugins, MCP servers, skills, packages, and model artifacts, plus every credential, permission scope, and autonomy setting each of them has been granted.


What AI risk on the endpoint looks like today

Risk concentrates on the endpoint because everything an agent needs is already there: credentials, access, tooling, trust. None of this is theoretical: here's what the last twelve months produced.
‍

The defaults favor velocity over safety

Claude Code, Cursor, Codex, and their peers shipped fast, and central management is still catching up: almost everything meaningful, including permission modes, sandbox settings, which directories are trusted, whether human approval is required, can be changed locally, per developer, per repo.

The configuration surface is enormous, and it lives on the endpoint. Validation prompts default to "trust," so a reflexive press of Enter hands a freshly cloned repo the ability to change tool behavior and spawn servers. Sandbox and permission modes are bypassed because users experience friction. Every one of those choices is made to optimize productivity, and every one is invisible to the security team. Multiply it across every developer, every repo, and every tool, and misconfiguration stops being an edge case; it's the steady state. In one out of three organizations, we find endpoints running in exactly that state: full-bypass mode with the sandbox disabled.


And it doesn't get corrected, either. Zoom in from the machines to the configurations themselves: ~45% of agent configurations across the sample have no centrally enforced guardrails, nothing above them to override what shipped. In 40% of organizations, no central controls are deployed at all.

The extreme case is velocity with no human in the loop at all: within weeks of OpenClaw's adoption surge, researchers scanning the open internet found 40,000+ exposed instances, roughly a third of them vulnerable to remote code execution (CVE-2026-25253, a one-click RCE), with control panels leaking API keys, OAuth tokens, and full chat histories. An attacker who takes over an exposed instance inherits everything the agent was granted, which Microsoft's security team called untrusted code execution with persistent credentials.

Misconfigured agentic apps

Security researchers demonstrated what that permissive surface means in practice: a malicious repository can trigger code execution in Claude Code, Cursor CLI, Gemini CLI, and Copilot CLI with a single keypress, or none at all in CI environments. Three recent CVEs (CVE-2025-59536, CVE-2026-21852, CVE-2026-33068) let malicious repos silently change how the tool behaves on a developer's machine, including one that redirected API traffic to an attacker-controlled server by overriding the API base URL in project settings.

A decade ago, the canonical cloud breach started with a storage bucket someone opened to the world and forgot. Today's equivalent is the grant nobody reviews: the folder trusted once and forever, the bypass flag left on after a demo, the MCP server handed filesystem-wide scope, the skill installed from a registry no one audits, the OAuth grant no one remembers approving.
‍

The ecosystem is a supply chain, and it's barely vetted

Agents install skills, add MCP servers, load plugins, and inherit OAuth grants, and each of those is a software supply chain with weaker vetting than the ones we already struggle with.

The starkest example is MCP. The protocol standardizes how models discover and call tools, and deliberately leaves authentication, authorization, and transport security to whoever builds each server. Thousands of independently built servers now sit inside agents' trust chains holding real credentials, and they arrive through any channel that can move code. In our telemetry, roughly one out of five endpoints shows a suspected hardcoded secret in their agentic tool config / MCP configuration. No registry vets them. They're not fringe, either: 30% of endpoints with MCP servers installed are running at least one unofficial MCP.


Security researchers pulled 800+ malicious skills out of OpenClaw's skill registry (roughly 20% of everything hosted there), many of them delivering the Atomic macOS Stealer. A separate sweep found vulnerable AI side-panel extensions running on 10M+ devices across Chrome-compatible browsers, one of them ranked in the Chrome Web Store's top 25. It's the same failure mode VS Code extensions and open-source packages have suffered for years: impersonation, typosquatting, and post-install compromise.

‍

Why traditional controls miss this

EDR and XDR were built around a specific picture of compromise: a malicious actor on the outside gets a payload onto the machine, a process does something anomalous, a signature or behavioral rule fires. Three assumptions in that picture no longer hold.

First, the software looks different. The AI estate isn't a set of binaries; it's installed directly by employees, updated constantly, and configured per machine. Classic tooling watches processes: it doesn't understand that a markdown file in a plugin directory is executable intent, or that a JSON settings file just granted an agent shell access.

Second, the threat model is different: the agent operates as an insider. It sits inside the perimeter, trusted and credentialed, and unlike the classic insider it needs neither malice nor negligence to do damage. An over-permissioned assistant deletes the wrong directory, syncs sensitive files somewhere it shouldn't, leaks data into a context window. Destructive behavior, no attacker anywhere in the loop.

When there is an attacker, the mechanism is usually manipulation rather than malware: a prompt injection buried in a README, a webpage, or an email redirects the agent mid-task.

Either way, every resulting action executes through the user's own authenticated sessions, with the user's complete privilege set. EDR was built to find malicious activity: a signature, a known-bad binary, a behavior on a blocklist. This is merely suspicious: every individual action is legitimate, only the pattern is wrong. There's no dropped binary, no anomalous process tree, no C2 beacon. To the existing tools, it looks like the user having a productive afternoon.

For human insiders, security eventually built an answer: activity monitoring, behavior analytics, insider-risk programs that watch what trusted people actually do with their access. For agents, that layer largely doesn't exist. What an agent did in the last hour (the commands it ran, the files it touched, the grants it exercised) is scattered across terminal scrollback, per-tool logs, and API consoles nobody correlates. We monitor trusted humans more closely than the software we've given the same privileges.

Third, the attacker has upgraded too. Frontier models have made finding exploitable bugs cheap, and the easiest hunting ground is exactly the software with the least governance: plugins, packages, and extensions that are barely vetted, barely inventoried, and patched on no schedule at all. The patch model assumed defenders and attackers moved at comparable speed. That assumption is gone. When the exploit was found this morning, by a model, in software you don't know you're running, the only durable answer is to use AI to see and control everything that runs on the endpoint.

‍

How far along is your team today?
We built a five-step playbook for securing AI.
  1. Get your visibility baseline. Which AI tools are here, who uses them, how and what for, discovered from the endpoint, not the app catalog.
    ‍
  2. Standardize the ecosystem. Decide the approved set: apps, models, MCP servers, plugins, extensions.
    ‍
  3. Apply the secure posture. Set secure-by-default configurations for everything approved.
    ‍
  4. Remediate and set policy. Remove what's unapproved, then enforce, so it stays clean.
    ‍
  5. Prevent and monitor at runtime. Continuous guardrails, so the same issue can't recur.
    ‍

Most teams we meet haven't even started step 1 yet: you can't set policy on tools you haven't found.


Where this leaves us

The common framing is that risk has shifted: from malware to prompts and from binaries to agents. We think that's wrong, or at least incomplete. The old risks haven't gone anywhere. The risk surface has expanded: from what's installed to what's installed, what it's been granted access to, and how much autonomy it has.

That expansion makes the endpoint more central to security, not less. It's the one place where everything converges: where the credentials live, where the agent runs, and where its decisions become real operations against real systems.

If you can see and govern that convergence point, you can secure AI adoption. If you can't, you're inferring what your agents are doing from the damage. That's the gap we've been building for: continuous visibility into the full AI estate on every endpoint, and the ability to decide what belongs there and on what terms. More on that soon.

This isn't a future problem

It took under two years for AI tools to reach 52% of enterprise workstations, and the attackers moved just as fast: the same frontier models that write the code now hunt its vulnerabilities, faster than any patch cycle can close them.

The defense is the part that hasn't caught up, and that's why Glow exists. For the story of why this moment demands a new approach, read our founding story.

AI lives on the endpoint. Now its security does too.

Continue reading
Why We Started Glow
6 min
|
August 12, 2026
Roi Tiger
Glow brand logo with a diamond-shaped dotted design next to the word glow.
CompanyAboutCareers
ResourcesBlogNewsEvents & Webinars
ContactSupport
Company
AboutCareers
Resources
BlogNewsEvents & Webinars
Contact
Support
Glow brand logo with a diamond-shaped dotted design next to the word glow.
Glow brand logo with a diamond-shaped dotted design next to the word glow.
© 2026 Glow Security, Inc. All rights reserved.
Privacy PolicyTerms of use
© 2026 Glow Security, Inc. All rights reserved.
Privacy PolicyTerms of Use
Contact Us