Glow emerged from stealth this week arguing that detection after execution is too late. We agree, and we have been making that argument for eighteen months. Here is what the company does, where its model reaches, and where the file boundary remains unaddressed.
On 22 July 2026, an AI-native endpoint security company called Glow emerged from stealth with 180 million dollars in funding at a 1.2 billion dollar valuation. Founded in 2025, headquartered in Palo Alto with its principal engineering presence in Tel Aviv, the company employs roughly 100 people and had already signed enterprise customers in healthcare, retail and financial services while still operating quietly.
The funding is notable. The thesis behind it is more interesting, because it is a thesis the security industry has been circling for several years without committing capital to at this scale.
The short version
A tier-one investor syndicate has priced the prevention-first security thesis at 1.2 billion dollars. That validates a category rather than a single company, and it raises a question every enterprise buyer should now be asking: if prevention is the right answer, which entry paths does your prevention layer actually cover?
What Glow is building
Glow’s argument is that traditional endpoint security was designed for an era when enterprise software changed slowly. That world is gone. Employees install AI tools continuously, browser extensions proliferate, AI agents execute code autonomously, internal software changes weekly, and attackers now use AI to accelerate exploitation. The company’s public positioning goes further, asserting that security teams should assume adversaries have access to frontier-model capabilities and that risks previously tolerable can now be exploited at machine speed.
Its product thesis follows directly from that premise: control everything that runs on the endpoint, and decide what may execute before it executes rather than detecting malicious behavior afterward. Glow describes specialized AI agents that continuously map the environment, analyze risk in real time, and enforce policy automatically, determining which software is allowed in and which should be removed. A context and reasoning engine is said to make that prevention adaptive.
One data point from the launch is worth every security leader’s attention regardless of what they think of the product: Glow reports that regular AI usage on corporate devices rose from 15 percent to 45 percent in a single year. Whatever else is true, the endpoint is now where AI enters the organization.
The company has not published detailed technical architecture, so any description of its internals is inference from marketing language rather than sourced fact. What can be said from public information is that the operating model resembles application control and allowlisting, augmented with AI-driven context and automation. Where conventional endpoint detection follows a sequence of malware executing, behavior being detected, an alert firing and analysts investigating, Glow’s model is closer to software appearing, AI evaluating risk, policy deciding, and execution being permitted or prevented.
Why this matters beyond one funding round
For most of the last decade, the prevailing enterprise security architecture has been detection-centric. Network detection and response, endpoint detection and response, extended detection, security information and event management, orchestration and automation, and managed detection services. Each layer contributes real value, and collectively they have meaningfully reduced attacker dwell time.
The structural limitation was never quality. It was sequence. These technologies largely begin operating after an adversary has introduced malicious content into the environment. That was an acceptable trade when the interval between initial access and lateral movement was measured in hours. It is a harder trade now. CrowdStrike’s 2026 Global Threat Report recorded average eCrime breakout time falling to 29 minutes, with the fastest observed at 27 seconds, and found that 82 percent of detections in 2025 involved no malware at all.
Prevention has always been the theoretically correct answer. The practical objection was that prevention at enterprise scale blocked legitimate business. Glow’s bet is that AI resolves that objection by supplying the contextual judgment that made blanket allowlisting unworkable. Whether the product delivers on that is an open question, and we will return to it. But the strategic point stands independently of Glow’s execution: capital is now flowing toward preventing execution rather than observing it.
The boundary of execution control
Here is where the analysis gets specific, and where enterprise buyers should think carefully about coverage.
Execution control governs what software is permitted to run. It does not inspect what is inside a document that an already-permitted application will open. Those are different questions, and the second one is not a subset of the first.
Consider what that means operationally. A signed, approved, allowlisted copy of Microsoft Word or Adobe Acrobat is precisely the kind of software any well-configured policy engine permits. It is legitimate, it is necessary, and blocking it would halt the business. Now consider a weaponized DOCX or PDF crafted to exploit a parser vulnerability in that permitted application. That file never presents itself as software requesting execution. It presents itself as data being consumed by trusted software. The policy engine has nothing to adjudicate, because from its vantage point nothing unusual is being asked.
Stated plainly
Execution control cannot see inside the file. That is not a deficiency in any particular vendor’s design. It is a boundary of the category. Recognizing where a control’s coverage ends is how defense in depth is supposed to work.
A worked example
The SHADOW#REACTOR campaign documented by Securonix in January 2026 illustrates the layering from both directions, which is why it is a useful teaching case rather than just another advisory.
That campaign chains an obfuscated VBS launcher executed through wscript.exe, a self-healing PowerShell downloader, plain-text payload staging designed to slip past scanners looking for recognizable binaries, a .NET Reactor protected in-memory loader, and a final handoff to MSBuild.exe as a living-off-the-land binary, ultimately delivering Remcos RAT and full remote control of the compromised machine.
A well-implemented execution control layer would plausibly break that chain at the policy stage, because the wscript to PowerShell to MSBuild parent-child sequence is exactly the kind of anomalous execution pattern such a model is designed to interdict. A file-boundary control breaks the same chain earlier, neutralizing the delivered lure at ingress before wscript.exe ever runs it.
Two independent breaks in a single kill chain is a materially stronger defensive position than either control provides alone. That is the substance of defense in depth rather than the slogan version of it, and it is the right way to evaluate any new preventive layer: not whether it replaces something, but where its coverage begins and ends relative to what you already run.
Where the coverage lines fall
The distinction is clean enough to tabulate. Execution control governs what runs. Content analysis, disarm and reconstruction governs what enters.
| Attack surface | Execution control | CADR |
|---|---|---|
| Executables, installers, applications | Covered | Not in scope |
| Browser extensions and local AI agents | Covered | Not in scope |
| Loose script files on the endpoint | Covered | Covered (redundant) |
| Macros and OLE objects inside documents | Not in scope | Covered |
| PDF JavaScript, launch actions, malformed objects | Not in scope | Covered |
| Nested, spoofed and password-protected archives | Not in scope | Covered |
| Exploit payloads targeting file parsers | Not in scope | Covered |
| Hidden prompt injection in ingested documents | Not in scope | Covered |
| Which AI tools are approved for use | Covered | Not in scope |
Note the third row. There is genuine overlap on loose script files, where both controls have a legitimate claim. In a defense-in-depth architecture that redundancy is a feature rather than waste. The rows above and below it are where coverage is exclusive.
The AI governance question neither layer closes alone
The most consequential gap is one the industry has barely started discussing, and it sits precisely at the intersection of these two models.
Enterprises deploying AI copilots, retrieval-augmented generation systems and autonomous agents face two distinct exposures. The first is the tooling itself: which AI applications employees install, which browser extensions are approved, whether agents may execute code locally. That is an endpoint governance problem, and it is the problem Glow has positioned itself to solve.
The second exposure is the content those tools ingest. AI systems routinely process contracts, policies, engineering documents, spreadsheets and entire knowledge repositories. Any of those documents may carry hidden prompt injection, invisible text, manipulated metadata or annotation abuse crafted to manipulate the model rather than the machine. OWASP ranks prompt injection as the leading risk to large language model applications and identifies indirect injection through externally supplied content, including files, as a distinct attack class. Academic work has demonstrated PDFs functioning as concrete carriers, with adversarial payloads placed beyond the visible canvas or inside metadata fields.
These payloads contain no executable code. They trigger no behavioral heuristic. Conventional antivirus disregards them entirely, because they are not malware in any traditional sense. They are instructions aimed at a machine reader.
Two halves of one problem
Governing the AI tooling does not sanitize what the tooling reads. Sanitizing documents does not govern which tools are approved. An organization solving only the first still has poisoned documents flowing into approved copilots. An organization solving only the second still has unapproved tools consuming clean documents. The loop closes only when both are addressed.
What we would still want to know
Intellectual honesty requires noting what remains unestablished about any newly emerged platform, and this applies to Glow no differently than it would to us.
Performance metrics at launch are self-reported from early customer engagements, and no independent benchmarks exist. Several operational questions matter enormously in practice and cannot be answered from public information: how the model distinguishes legitimate but uncommon software from malicious software at enterprise scale, what false-positive rate it achieves in production, how transparent and auditable its automated enforcement decisions are, how it handles highly customized internal and line-of-business applications, which operating systems are fully supported, and how it integrates with existing detection ecosystems rather than displacing them.
Glow is showcasing at Black Hat USA in Las Vegas from 3 to 5 August 2026. That will be the first real opportunity for the security community to pressure-test the technology in public, and we will be watching with genuine interest rather than competitive anxiety.
The takeaway for security leaders
Prevention-first architecture is no longer a contrarian position. It is a funded category with serious capital and serious operators behind it, and that is good for everyone building in this space, including those of us who have been arguing the case for some time.
The right response is not to ask which single vendor solves prevention. It is to map your preventive coverage honestly across every path by which content enters your environment, and to notice where the map has blank regions. Execution control closes a large and important one. The file boundary, where weaponized documents and AI-targeted payloads arrive inside formats your permitted applications will happily open, is a different region entirely.
FileDNA Content Analysis, Disarm and Reconstruction (CADR) addresses that specific boundary. It analyzes each inbound file’s structure without executing anything, removes active and executable content that has no legitimate place in the intended format, and reconstructs a clean, fully usable document. It does not depend on recognizing the threat, waiting for a signature, or detonating anything in a sandbox. It is not a replacement for endpoint controls, identity controls, patching or detection, and we would not position it as one. It closes the file-borne entry path, which remains one of the most reliable delivery mechanisms available to adversaries.
Layered correctly, controls that break different links in the same chain are worth considerably more than the sum of their individual claims. That principle is what the last decade of detection investment taught the industry. It applies with equal force to the prevention era now taking shape.
Sources: