Enterprises that give AI agents browser access are creating a security boundary that traditional endpoint, email, and network controls were not built to police. In a new SC Media segment, Menlo Security Chief Product Officer Ramin Farassat argues that the immediate exposure is less about the underlying model than the web pages, documents, SaaS interfaces, and connectors an agent can read and act through. Menlo’s proposed answer is Menlo Agent Runtime Security, or MARS: a cloud-hosted browser runtime intended to inspect and sanitize material before it reaches an agent.
The premise is sound, but it needs a sharper reading than the vendor pitch supplies. Browser-capable agents can encounter attacker-controlled instructions in HTML, downloaded files, search results, ticketing systems, shared documents, and internal knowledge bases. Once that agent also has permission to send messages, open records, retrieve sensitive material, write code, or invoke APIs, a successful prompt injection becomes an authorization problem with an AI system in the middle.
NIST calls this indirect prompt injection: an attacker controls a resource rather than directly submitting a prompt to the model. NIST’s recent agent-security work has shown why that distinction matters. An agent can consume hostile text from a webpage, email, code repository, or document as part of a legitimate task, then be steered toward harmful actions such as data exfiltration or downloading and running untrusted code.
Menlo is targeting the browser-facing portion of that risk. It is not, by itself, a replacement for managing what an agent is authorized to do after it has read the page.
Menlo describes MARS as a managed runtime that executes agent browser sessions in remote, disposable cloud containers. The company says it can connect agents through a proxy or Model Context Protocol integration, render pages remotely, and clean up page and file content before presenting it to the agent. Its published material also promises access controls, data masking, logging, and controls for agents reaching web applications that lack formal APIs.
This is an extension of the browser-isolation model Menlo has sold for human users. Instead of allowing an agent’s browser automation framework to load arbitrary websites directly from a workstation, server, or local developer environment, the browsing session occurs in Menlo’s cloud. The intended payoff is containment: malicious scripts, risky downloads, and browser-session artifacts should remain in a disposable remote environment rather than landing beside the agent’s credentials, code, or local files.
For IT teams, that can solve a real operational problem. A browser agent frequently needs to interact with legacy ERP, CRM, support, procurement, and line-of-business portals that were never designed around APIs. Organizations have been tempted to let agents operate those UIs directly because rebuilding every integration would take years. MARS is positioned as a controlled bridge: the agent requests an action, the remote browser interacts with the legacy UI, and policy determines what data or results the agent receives.
That is potentially useful for Windows-heavy environments where unattended automation still depends on web front ends, SharePoint-connected business applications, internal portals, and desktop-adjacent workflows. It also introduces a new service dependency. The agent is no longer simply calling an internal API; it is trusting a cloud intermediary to render sessions, apply content transformation, enforce policy, and retain audit evidence. Security teams will need to assess that intermediary with the same seriousness they apply to a privileged identity provider or secure web gateway.
Menlo says MARS removes invisible content from pages and documents, scans page segments for adversarial intent with a secondary “judge” model, and routes files through content disarm and reconstruction. Its white paper specifically identifies zero-font text, hidden layers, malicious scripts, and steganographic material as targets. Those are reasonable controls, especially for agents that ingest large amounts of web and document content at machine speed.
But removing hidden content cannot make prompt injection disappear. An attack does not need to be invisible. A webpage can show a plausible-looking block of text telling a research agent to “verify” a claim at a malicious URL. A support ticket can include a visible instruction engineered to make an agent search an internal file share. A GitHub issue can exploit an agent that has been given permission to edit repositories or post comments. In all of those cases, a sanitizer has to decide whether apparently legitimate prose is data relevant to the task or an instruction that should be rejected.
Anthropic has made the limitation unusually clear in its own browser-agent security research: no browser agent is immune to prompt injection, even where model robustness and browser safeguards have materially improved. Microsoft reaches much the same conclusion in its current agentic-AI guidance, recommending layered controls that combine input filtering with information-flow control, tool-chain review, limited privileges, and human approval for consequential actions.
Menlo’s marketing sometimes uses absolute language about stopping threats before they reach the agent. Its technical documentation is more defensible: it describes multiple stages that reduce the attack surface and block or sanitize material flagged as adversarial. Those are not the same claim. A model-based classifier can miss a novel or carefully phrased injection, and an attacker can use visible content, trusted-but-compromised internal sources, or a legitimate workflow to achieve the same end.
A browser runtime can significantly narrow the first part of that chain. It can isolate web rendering, remove known-dangerous content, prevent the direct delivery of active web code, apply destination controls, and block sensitive data from being returned to the agent. It cannot safely grant broad write privileges to an agent whose reasoning has been influenced by untrusted information.
Microsoft’s new Agent Framework guidance puts the issue bluntly: inputs from users, tools, external systems, stored context, and even model output should be treated as untrusted. Tools that send communications, modify data, make purchases, delete records, access credentials, or retrieve sensitive data should generally require explicit approval or deterministic parameter validation. Microsoft’s FIDES work goes further by labeling content by integrity and confidentiality and applying policies before a sensitive tool executes.
That is the standard MARS customers should use to judge the product. The useful question is not whether MARS detects prompt injection in a demonstration. It is whether an injected page can ever cause an unauthorized tool call, data disclosure, or credential-bearing navigation when its detection layer fails.
A defensible deployment should include all of the following controls:
Claude Code, for example, can operate in development environments where filesystem access, shell execution, source repositories, package registries, and CI/CD credentials matter more than browser isolation. A remote browser security layer can help if the coding workflow uses web research or browser automation, but it will not secure an overly permissive shell, a poisoned repository instruction, or an unsafe deployment tool. The relevant boundary is the local toolchain and the authority granted to commands.
Microsoft Copilot and Google Gemini deployments pose a different set of questions: which tenant data sources they can reach, whether extensions or connectors can perform actions, how identity and conditional-access policies apply, whether a browser assistant can read active tabs, and whether data-loss prevention rules govern both prompts and outputs. Microsoft’s own current documentation now treats agent sprawl, over-privileged agents, tool misuse, and prompt injection as separate but related risks. That is a useful model for administrators: inventory the agent first, then map its identities, data sources, tools, and action rights before adding a runtime defense.
Menlo says MARS can connect “any agentic system” through proxy or MCP integration. Its public material does not provide a detailed supported-agent matrix for Microsoft Copilot, Gemini, or Claude Code, nor does it spell out the feature differences for each integration path. It also does not publish public pricing, independently measured detection rates, latency figures, or a false-positive profile for its adversarial-content scanning. Those omissions do not invalidate the architecture, but they make a proof of concept mandatory before a production rollout.
The sensible first use case is a low-privilege, read-mostly agent that must browse untrusted public content or navigate an internal web application without an API. Give it a limited service identity, permit a defined destination list, block downloads and uploads unless necessary, mask sensitive fields, and require human approval for external messages or writes. Then test it against visible and hidden prompt injections, malicious files, compromised internal documents, and attempts to induce dangerous tool sequences.
The larger lesson from Farassat’s interview is that agent security cannot remain a model-team issue. Once an AI system reads the web and operates enterprise tools, it becomes a browser, identity, data-governance, application-security, and incident-response problem at once. MARS may reduce a meaningful part of that exposure, but the deployment succeeds or fails on the permissions that remain after the sanitized page reaches the agent.
NIST calls this indirect prompt injection: an attacker controls a resource rather than directly submitting a prompt to the model. NIST’s recent agent-security work has shown why that distinction matters. An agent can consume hostile text from a webpage, email, code repository, or document as part of a legitimate task, then be steered toward harmful actions such as data exfiltration or downloading and running untrusted code.
Menlo is targeting the browser-facing portion of that risk. It is not, by itself, a replacement for managing what an agent is authorized to do after it has read the page.
MARS moves the browser session out of the agent’s environment
Menlo describes MARS as a managed runtime that executes agent browser sessions in remote, disposable cloud containers. The company says it can connect agents through a proxy or Model Context Protocol integration, render pages remotely, and clean up page and file content before presenting it to the agent. Its published material also promises access controls, data masking, logging, and controls for agents reaching web applications that lack formal APIs.This is an extension of the browser-isolation model Menlo has sold for human users. Instead of allowing an agent’s browser automation framework to load arbitrary websites directly from a workstation, server, or local developer environment, the browsing session occurs in Menlo’s cloud. The intended payoff is containment: malicious scripts, risky downloads, and browser-session artifacts should remain in a disposable remote environment rather than landing beside the agent’s credentials, code, or local files.
For IT teams, that can solve a real operational problem. A browser agent frequently needs to interact with legacy ERP, CRM, support, procurement, and line-of-business portals that were never designed around APIs. Organizations have been tempted to let agents operate those UIs directly because rebuilding every integration would take years. MARS is positioned as a controlled bridge: the agent requests an action, the remote browser interacts with the legacy UI, and policy determines what data or results the agent receives.
That is potentially useful for Windows-heavy environments where unattended automation still depends on web front ends, SharePoint-connected business applications, internal portals, and desktop-adjacent workflows. It also introduces a new service dependency. The agent is no longer simply calling an internal API; it is trusting a cloud intermediary to render sessions, apply content transformation, enforce policy, and retain audit evidence. Security teams will need to assess that intermediary with the same seriousness they apply to a privileged identity provider or secure web gateway.
Hidden text is a real attack vector, but it is not the whole problem
Farassat’s focus on hidden instructions reflects one of the clearest forms of indirect prompt injection. A malicious page may include text styled to be invisible, place instructions in off-screen elements, use tiny fonts, insert content into an HTML attribute, or hide a prompt inside a document layer. A human sees an ordinary invoice or search result; an agent processing the document object model may see an attacker’s instruction to ignore its assigned task, disclose data, or call a tool.Menlo says MARS removes invisible content from pages and documents, scans page segments for adversarial intent with a secondary “judge” model, and routes files through content disarm and reconstruction. Its white paper specifically identifies zero-font text, hidden layers, malicious scripts, and steganographic material as targets. Those are reasonable controls, especially for agents that ingest large amounts of web and document content at machine speed.
But removing hidden content cannot make prompt injection disappear. An attack does not need to be invisible. A webpage can show a plausible-looking block of text telling a research agent to “verify” a claim at a malicious URL. A support ticket can include a visible instruction engineered to make an agent search an internal file share. A GitHub issue can exploit an agent that has been given permission to edit repositories or post comments. In all of those cases, a sanitizer has to decide whether apparently legitimate prose is data relevant to the task or an instruction that should be rejected.
Anthropic has made the limitation unusually clear in its own browser-agent security research: no browser agent is immune to prompt injection, even where model robustness and browser safeguards have materially improved. Microsoft reaches much the same conclusion in its current agentic-AI guidance, recommending layered controls that combine input filtering with information-flow control, tool-chain review, limited privileges, and human approval for consequential actions.
Menlo’s marketing sometimes uses absolute language about stopping threats before they reach the agent. Its technical documentation is more defensible: it describes multiple stages that reduce the attack surface and block or sanitize material flagged as adversarial. Those are not the same claim. A model-based classifier can miss a novel or carefully phrased injection, and an attacker can use visible content, trusted-but-compromised internal sources, or a legitimate workflow to achieve the same end.
The decisive control is still what the agent can do
Farassat’s point that exposure lives in the integrations around an AI model is directionally correct, but the word “connectors” should be expanded. The dangerous chain is not merely model-to-connector. It is untrusted content entering an agent’s context, the model deciding what it means, a tool accepting model-generated parameters, and an identity with enough privilege to perform an irreversible action.A browser runtime can significantly narrow the first part of that chain. It can isolate web rendering, remove known-dangerous content, prevent the direct delivery of active web code, apply destination controls, and block sensitive data from being returned to the agent. It cannot safely grant broad write privileges to an agent whose reasoning has been influenced by untrusted information.
Microsoft’s new Agent Framework guidance puts the issue bluntly: inputs from users, tools, external systems, stored context, and even model output should be treated as untrusted. Tools that send communications, modify data, make purchases, delete records, access credentials, or retrieve sensitive data should generally require explicit approval or deterministic parameter validation. Microsoft’s FIDES work goes further by labeling content by integrity and confidentiality and applying policies before a sensitive tool executes.
That is the standard MARS customers should use to judge the product. The useful question is not whether MARS detects prompt injection in a demonstration. It is whether an injected page can ever cause an unauthorized tool call, data disclosure, or credential-bearing navigation when its detection layer fails.
A defensible deployment should include all of the following controls:
- An agent should receive short-lived, narrowly scoped identities rather than a human administrator’s persistent browser session or broad SaaS token.
- Read-only tools should be separated from tools that send email, modify records, deploy code, purchase items, or expose protected data.
- Tool arguments should be allowlisted and validated outside the model, with explicit approval for external communications and high-impact changes.
- Retrieved web content, files, RAG results, tool output, chat history, and external connector data should all be marked as untrusted until a policy permits their use.
- Security teams should retain logs of the agent’s plan, browser navigation, tool calls, identity used, data returned, policy decisions, and final side effects.
Microsoft Copilot, Gemini, and Claude Code need separate assessments
SC Media’s segment references enterprise use of Microsoft Copilot, Google Gemini, and Claude Code. Those names should not be treated as one deployment category. They expose markedly different integration paths, privileges, local-versus-cloud execution models, browser capabilities, data connectors, and administrative controls.Claude Code, for example, can operate in development environments where filesystem access, shell execution, source repositories, package registries, and CI/CD credentials matter more than browser isolation. A remote browser security layer can help if the coding workflow uses web research or browser automation, but it will not secure an overly permissive shell, a poisoned repository instruction, or an unsafe deployment tool. The relevant boundary is the local toolchain and the authority granted to commands.
Microsoft Copilot and Google Gemini deployments pose a different set of questions: which tenant data sources they can reach, whether extensions or connectors can perform actions, how identity and conditional-access policies apply, whether a browser assistant can read active tabs, and whether data-loss prevention rules govern both prompts and outputs. Microsoft’s own current documentation now treats agent sprawl, over-privileged agents, tool misuse, and prompt injection as separate but related risks. That is a useful model for administrators: inventory the agent first, then map its identities, data sources, tools, and action rights before adding a runtime defense.
Menlo says MARS can connect “any agentic system” through proxy or MCP integration. Its public material does not provide a detailed supported-agent matrix for Microsoft Copilot, Gemini, or Claude Code, nor does it spell out the feature differences for each integration path. It also does not publish public pricing, independently measured detection rates, latency figures, or a false-positive profile for its adversarial-content scanning. Those omissions do not invalidate the architecture, but they make a proof of concept mandatory before a production rollout.
The first deployment should be narrow and auditable
MARS has been publicly described by Menlo since at least March 2026, with a dedicated technical white paper published in June. The product is more concrete than a concept-stage discussion: Menlo documents remote containers, DOM and file sanitization, secondary-model scanning, data redaction, browser access policies, and audit logging. Yet the company’s public presentation remains dominated by broad claims of scale and safety rather than operational measurements.The sensible first use case is a low-privilege, read-mostly agent that must browse untrusted public content or navigate an internal web application without an API. Give it a limited service identity, permit a defined destination list, block downloads and uploads unless necessary, mask sensitive fields, and require human approval for external messages or writes. Then test it against visible and hidden prompt injections, malicious files, compromised internal documents, and attempts to induce dangerous tool sequences.
The larger lesson from Farassat’s interview is that agent security cannot remain a model-team issue. Once an AI system reads the web and operates enterprise tools, it becomes a browser, identity, data-governance, application-security, and incident-response problem at once. MARS may reduce a meaningful part of that exposure, but the deployment succeeds or fails on the permissions that remain after the sanitized page reaches the agent.
References
- Primary source: SC Media
Published: 2026-08-07T01:33:48+00:00
Loading…
www.scworld.com - Related coverage: menlosecurity.com
Menlo AI Agent Security | Menlo Security
Secure autonomous AI agents, prevent data loss, and unlock legacy data for agentic use. Menlo AI Agent Security protects AI workflows at cloud scale.
www.menlosecurity.com
- Related coverage: menlosecurity.com
Secure AI Agents with Menlo Agent Runtime Security | Menlo Security
Secure your AI agents. Learn how Menlo MARS defends autonomous agents against prompt injection and data leaks while enabling seamless legacy web access.www.menlosecurity.com - Related coverage: info.menlosecurity.com
- Related coverage: techrepublic.com
Loading…
www.techrepublic.com - Related coverage: agenticwire.news
Loading…
www.agenticwire.news - Related coverage: docs.menlo.ai
Loading…
docs.menlo.ai - Related coverage: ortech.com.tw
Loading…
www.ortech.com.tw - Related coverage: microsoft.com
When prompts become shells: RCE vulnerabilities in AI agent frameworks | Microsoft Security Blog
New research exposes how prompt injection in AI agent frameworks can lead to remote code execution. Learn how these vulnerabilities work, what’s impacted, and how to secure your agents.www.microsoft.com - Related coverage: techspective.net
Loading…
techspective.net - Related coverage: linkedin.com
Loading…
www.linkedin.com - Related coverage: tomsguide.com
Loading…
www.tomsguide.com - Related coverage: axios.com
Loading…
www.axios.com - Related coverage: itpro.com
Loading…
www.itpro.com - Related coverage: techradar.com
Loading…
www.techradar.com - Related coverage: anthropic.com
Loading…
www.anthropic.com - Related coverage: learn.microsoft.com
Secure AI agents at scale using Microsoft Agent 365 | Microsoft Learn
How to use Microsoft Agent 365 to secure all of the AI agents in your environment.learn.microsoft.com - Related coverage: nist.gov
Technical Blog: Strengthening AI Agent Hijacking Evaluations
Large AI models are increasingly used to power agentic systems, or “agents,” which can automate complex tasks on behalf of users.www.nist.gov - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: devblogs.microsoft.com
Loading…
devblogs.microsoft.com - Related coverage: csrc.nist.gov
Loading…
csrc.nist.gov - Related coverage: nist.gov
Loading…
www.nist.gov - Related coverage: csrc.nist.gov
- Related coverage: nvlpubs.nist.gov
Loading…
nvlpubs.nist.gov - Related coverage: nvlpubs.nist.gov
Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
This NIST Trustworthy and Responsible AI report provides a taxonomy of concepts and defines terminology in the field of adversarial machine learning (AML). The taxonomy is arranged in a conceptual hierarchy that includes key types of ML methods, life cycle stages of attack, and attacker goals...nvlpubs.nist.gov
- Related coverage: linkedin.com
Loading…
www.linkedin.com