Island’s Michael Leland on enterprise browsers, agentic AI guardrails, and the cloud inspection model that no longer reaches where work happens.

Interview by Confidence Staveley | AI Cyber Magazine

For most of the past decade, security teams focused their attention on endpoints, networks, and cloud access. The browser, where the majority of knowledge work actually happens, was largely treated as someone else’s problem. Michael Leland thinks that era is over.

Leland is a field CTO at Island, the company widely credited with creating the enterprise browser category. In this conversation, he makes the case that the browser is now the most consequential enforcement point in the modern enterprise, and that ignoring it is no longer a defensible position, especially as agentic AI tools move directly into that same space.

Let’s start with the premise. Why should a security leader reading this care specifically about the browser as a security surface, right now?

LELAND: Over the last decade, the majority of knowledge workers have been using a browser to access business applications and sensitive data. They’re doing so in a consumer browser. A browser that was never built for the enterprise. Not built secure by design. Not built enterprise grade. We’re depending on a platform with an enormous attack surface for the most consequential work in the organization.

We don’t make those decisions for other business tools. We choose business-appropriate applications. The same logic should apply to how we interact with applications across the web.

Organizations have tried to compensate. SASE providers backhauling traffic. Break-and-inspect. CASB solutions inspecting at points of access. The closer you get to where work actually happens, the more you can capture user intent and the more you land in the sweet spot for data protection. That happens between the user and the screen. The further you are from that point, the less visibility and enforcement you have.

Walk me through a specific scenario where traditional DLP failed and browser-level control catches it.

LELAND: Most cloud-based data protection tools backhaul your traffic, break and inspect, and try to block data from leaving the organization upstream. That worked reasonably well when all applications lived in the cloud. Something has shifted.

AI is the first technology I have seen move quickly in the opposite direction. Our first interaction with most AI tools was through a web page. In the span of a few months, those same tools made their way to the desktop. They need visibility into what is being painted on screen in the DOM, what other tabs are open in the browser. There is no way to have that visibility if you are waiting until data leaves the organization. By the time a cloud-based DLP tool can inspect, the prompt has already been sent. The horse is already out of the barn.

The only place to get full visibility into how a user is engaging with data, and how AI is engaging with data on that user’s behalf, is at the desktop. Between the keyboard and the screen, or between the file system and a locally installed AI tool. That is the only sure methodology.

What happens to the control model when an employee is working from a personal device at a coffee shop, or moves between business and personal AI accounts on the same browser?

LELAND: Context matters enormously. One of the most underappreciated risks right now is the difference between a user logged into a business AI tenant and the same user, in the next tab, logged into a personal AI tenant. If you are not tracking which tenant a user is logged into, you do not fully understand what data risk is being presented.

Gemini at a business license and Gemini at a personal license should have completely different policies governing what a user can do. Maybe you are allowed to upload business data into the business tenant. You should never be allowed to upload it into the personal tenant. Leaving that distinction to the user guarantees that at some point someone will make the wrong decision. Putting guardrails in place, and communicating them at the moment of action, removes that risk without removing the tool.

Network location and geolocation are also part of the policy engine. A user working inside a corporate network should operate under a different policy than the same user connecting from an airport Wi-Fi hotspot. For multinational organizations, what you can collect and monitor in the United States may be significantly different from what GDPR allows in Germany. Geolocation-driven policy is not optional for a global workforce.

Shadow AI seems like the new shadow IT. Seven sanctioned tools can quickly become something very different. What did you actually find when you deployed Island at a customer that thought they had it under control?

LELAND: They had gone through governance, legal review, and approval to adopt seven AI tools. They knew which tools were sanctioned and which communities of users were authorized to use them. They believed everything else was blocked.

We deployed Island on around 100 machines and the Island extension on about 2,500 more. A week later, we ran the telemetry report. The seven sanctioned tools were there, being used by exactly the users they expected. What they did not know was that a much larger population of users had downloaded and installed AI browser extensions, and in some cases full AI browsers, beta products that are nowhere near enterprise-ready, running across their environment with no visibility and no governance.

The actual number of AI tools in use: 243.

The Gap Between Sanctioned and Actual

Sanctioned AI tools after governance review: 7

AI tools actually in use across the environment: 243

What governance teams did not see: AI browser extensions, beta AI browsers, and locally installed AI tools running with no visibility and no policy enforcement.

Agentic AI tools are increasingly browser-based. Some started as web apps and have become desktop applications. What does that shift mean for browser security over the next eighteen months?

LELAND: I want to expand this beyond data security to agentic efficacy, because both matter. The original model for agentic AI was deterministic automation. Robotic process automation that looked for specific objects on the page and knew where to click, type, and scrape. Those deterministic processes break when the application they are reading from changes. SaaS applications update constantly. If a vendor changes the name of a selector or a div tag, the workflow that was looking for that specific object can no longer find it, and the process fails.

A new approach builds workflows in natural language. You describe the steps you need, leveraging skills that have already been trained, and the system builds the multi-step workflow for you. You can then add stop points: human-in-the-loop checkpoints before consequential actions. Complete all of these steps, but before you send that email or process that credit card transaction, show me what you have done. Let me validate it. Over time, as the threshold of successful AI actions climbs, you can remove that checkpoint for that specific step.

The most important thing about agentic AI in this context is guardrails. An agent will do exactly what the user would do, but at machine speed. If that agent goes off course, there are very few compensating controls to prevent it. The application data boundary concept, originally built for users, applies directly to agents. By policy, you define which applications you trust and what data can move in and out of that boundary. Identity, device posture, network location, and geolocation drive that policy dynamically.

The critical point is this: if those guardrails are in place for the user, they must also be in place for any agentic transaction initiated on that user’s behalf. If the user cannot do something, neither can the agent.

The other visibility dimension that matters here is data lineage. Understanding how data is moving, not just where users are going. Lineage spans three categories. File movement: where files are being downloaded from or uploaded to. Clipboard movement: every copy and paste action, generating a visible graph of how data is moving through clipboard behavior. And AI data movement: how agentic transactions are leveraging and moving data, including how MCP connections are being made and what is flowing across them. You cannot build the right policy without understanding the scope of what is actually happening.

If a CISO is already heavily invested in endpoints, CASB, and ZTNA, what is the honest marginal security gain from adding an enterprise browser?

LELAND: Traditional and even modern ZTNA solutions use a lightweight endpoint agent, primarily to steer traffic into a cloud architecture where it can be broken and inspected. Two problems are becoming acute with that model.

First, that architecture is too far from where work is actually getting done to have meaningful insight into AI interactions. Second, more modern protocols like QUIC and HTTP/3 do not behave well when routed through those inspection environments. As post-quantum encryption standards mature, less and less of that traffic can be broken and inspected in the cloud. The number today is somewhere around 40% of traffic that cannot be inspected through traditional methods. That number is growing.