Every company hired a second workforce this year and never ran a single interview. AI agents moved from experimental novelties to the enterprise standard working alongside our people. But as adoption skyrocketed, the operational models broke. Enterprise organizations are now dealing with disappearing audit trails, murky agent identities, an expanding attack surface, and uncontrolled AI costs.

While point solutions see fragmented pieces of this, they miss the full sequence. The Island mission has always been to enable the future of work, which requires being everywhere knowledge work happens. That focus provides Island 360-degree visibility and real-time inline governance across the full execution chain. Organizations need a control plane for the agentic enterprise. Today, we released new features that expands the control plane from people to agents.

So what changed between AI Chatbots and Agents?

Before agents, governance focused on stopping sensitive data from reaching a chatbot. Agents are different; they operate autonomously. They don't know your policies, they don't follow onboarding, and they are designed to find the fastest way to complete a goal, even if it's not the original intent. The result is a four-dimensional problem:

1. Governance Blind Spots: Security teams have no inventory or audit trails for agent activity.
2. Identity Crisis:  Agents act on behalf of users, making their activities indistinguishable from human work.
3. Expanded Attack Surface:  Shared drives and unvetted MCP servers connect agents to data that legacy policies don't account for.
4. Uncontrolled AI Spend: Long-running tasks and automated retries create massive, unapproved budget overruns.

Agents now run inside SaaS platforms, developer endpoints, and cloud frameworks, and the volume keeps climbing. Gartner expects AI agents to outnumber human users 10 to 1 in large enterprises within a few years. We see the same pattern directly with customers. An agent deletes a database while freeing up storage, sends a file to a personal cloud drive because it was faster, or runs a bash command nobody authorized. Organizations routinely discover far more AI tools running in their environment than IT knew about.

Why existing solutions only see part of it

Every vendor looked at this problem through what they already had. Network tools see the wire, not what happened on the endpoint. EDR sees the endpoint, not the prompt or intent behind it, and nothing inside a browser. Identity tools see which credential touched a resource, not why. CASB and SaaS security tools, or SSPM, see the service side action, not the context behind it.

Each of these solutions sees something real. But none see the full chain, from the prompt that triggered it, through the tool calls and responses, to the data that moved as a result, even when you combine two of them. That gap is why incidents get discovered weeks after the fact, by someone piecing together four different tools' worth of logs, instead of at the moment it happened.

Where others see a link, Island sees the full chain

Island already sits in the browser, on the endpoint, and on the network, and integrated into enterprise apps through their APIs, because that is where people do their work. Agents run in those same places.

That combined view lets us trace a full chain of events instead of a single step in it. Take an example. A coding agent uses an unapproved skill, which directs it to run a Python script. That script pulls in a malicious package. The package reads a sensitive file and the file leaves the laptop to an external domain. 

Because we see the full chain of events, we can trace that whole sequence back to the prompt that started it, every tool call in between, and the person or agent that asked for it in the first place. A tool that only watches one of those layers sees a single link. We see the chain, which means we can act on it, not just reconstruct it afterward. Flag the skill as unapproved, and the agent never runs it. Miss that, and we can still stop the file from being read, or stop the connection before it reaches that external domain. Seeing the whole chain means there are multiple places to stop it, not one chance after the fact.

Now take a different case. An agent works inside the browser itself, clicking through a web app the same way a person would. To the network or the endpoint, that traffic looks the same whether a person is driving the action or an agent is. Only from inside the browser can you tell the two apart, and only from there can the policy treat them differently.

How it all comes together

Island touches AI traffic through a set of control points: the Island Enterprise Browser, Island Extension, Island Desktop, Island Network, the MCP Gateway, LLM Gateway integrations, Compliance API integrations, EDR and MDM integrations, and OpenTelemetry. These control points are essentially the plumbing. Each one gives visibility into a specific place an agent can run, and several sit inline, in the browser, on the desktop, on the network, at the gateway, where we can act on what we see, not just observe it. Together, they feed one policy engine and one audit trail.

On top of that plumbing sit four areas, each answering back to a problem from the section above. 

Agentic Endpoint Posture

Start with what is actually running. We discover every agent on the endpoint, regardless of vendor, and build a full inventory — installed MCP servers, skills, code packages, browser extensions, IDE extensions, and hooks. We flag risky configurations: a malicious MCP, an unapproved skill, or an IDE extension requesting far more permissions than it requires. This isn't just about posture. When something is flagged, we can remove it from that endpoint, not just report on it.

This matters because the MCP ecosystem is young and mostly unverified, and enterprise security doesn't have the antibodies to defend against it yet. Island’s security research team scanned nearly 34,000 public MCP servers, and found that about 1 in 8 exposed a tool that can execute code or perform an irreversible action, deleting data, running shell commands, rewriting access policies, on the first call. Where a maintainer could be identified, the majority of these servers turned out to be published by a single person, and most of those publishers were unverified. There is often no vendor and no security team behind the tool an agent is about to use, just an individual maintainer nobody vetted. In a separate piece of research, Island found more than 800 GitHub repositories hosting malicious MCP implementations outright, built to look legitimate and sitting there waiting for an IT team or a developer to install one [stat pending verification]. Skills carry the same profile, usually written by one person, published with no formal review, and installed the moment someone points an agent at one, the same as the skill that opened the chain we walked through earlier.

It gets worse once you consider what a single bad install, an MCP server or a skill, can do to everything else you have on that same device: it can read the full list of other tools installed on the host, along with their credentials, and use those credentials to reach whatever those other tools connect to, without needing to exploit anything else. In our scan, close to half of the MCP servers produced at least one finding, and roughly 1 in 3 carried a high or critical severity finding. 

Agentic Identity (NHI)

Once you know what is running, the next question is who it's running as. Every agent acting on a person's behalf needs its own identity, an NHI, and the changing workforce is creating more of these than most organizations can track - which ones exist, which are actually in use, and by whom.

We keep a live inventory of every NHI in the organization, both what's been provisioned and sitting unused, and what's actually authenticated and running right now. Say an agent is authenticated as a marketing team's service account to book a meeting on Google Calendar. It now has whatever that service account can do, and we see that as it happens: which identity, for what task, against which resource. We analyze that activity across every identity to surface risk a static list never would: a hardcoded API key sitting in a repo, an identity that's gone quiet for months but is still valid, an NHI whose access has grown broader than the task it was created for. We flag risks like these and help you act on each differently: rotate a leaked key, disable a dormant identity, scope back one that's outgrown its task, before an agent can pick any of it up.

Alongside that inventory sits a separate piece of architecture. The Island MCP Gateway sits between every agent and the tools it calls. For the identities that route through it, the gateway issues just-in-time access, a credential scoped to one task that expires the moment the session ends, instead of a standing credential left sitting around. It holds API keys itself, so the raw key never reaches the agent. It gives agents private access to internal, legacy systems without custom integration for each one. And it controls what an agent can do once it has access: which tools, which MCP servers, read or write.

Restricting an agent to read-only access on a specific MCP server, or cutting it off from a resource entirely without touching the underlying key, so nothing else using that credential breaks, gets defined at the gateway. Customers increasingly call this Action Runtime Management, or ARM: boundaries on what an agent can do, not just what data it can see.

AI Protect

Discovery and identity set the boundaries. AI Protect enforces them across every kind of interaction an agent has: the prompt, the response, the tool calls it makes, the files it uploads, the skills and sub-agents it invokes, and what comes back from all of it. As an example, when a user asks an agent to check unread Slack threads, the tool call is the agent requesting that action from Slack, and the tool response is the list of messages that comes back. From this, we build a full session view: which agent ran on which device, what it called, what it touched, and what came back, with full content, not just metadata. 

Real-time classifiers run inline and catch known threat types as they happen: prompt injection, jailbreak, agent drift, malicious URLs, malicious MCPs, data leakage, and unwanted content. We built them as small, purpose-built models instead of routing every check through a general-purpose LLM, which is what lets them sit on the wire fast enough that the agent never feels it happening.

Besides runtime policy enforcement, AI Protect surfaces risky sessions and agentic use across the organization that no single interaction would ever reveal. This runs on two kinds of detectors inside Island's own infrastructure: detectors that catch known patterns across a full session, and agentic investigators that look at the data the way a person investigating an incident would, with no fixed rule to follow. For example, an agent pulls account data from Salesforce and writes it to a personal Google Drive. No static rule flags that as wrong on its own. An agentic detector sees the sequence and surfaces it as an incident.

When we prevent an agent's action, we tell the agent why. Say an agent drafting a reply to a customer tries to send their full account number in plain text. We stop it and tell the agent why, and it rewrites the reply without the number instead of just failing. Security teams used to spend years training people not to make that mistake. Now the training happens on the agent, in the moment, every time, something blocking a person could never do, since that interaction just ends there.

This enforcement reaches further than systems with a clean API. A browser extension can bridge an agent to MCP tools, but that connection sits outside admin control: no DLP on what moves through it, no private access to internal systems, no audit of what the agent did, no way to separate what a user is allowed to do from what an agent is allowed to do. Island is the enterprise browser too, so the local MCP server it exposes runs under the same DLP, access policy, and audit as everything else, for any agent, not just one vendor's.

AI Cost and Experience 

The first three areas answer what an agent is allowed to do. This one answers whether the AI you have enabled is working, and what it costs. Most organizations can't say which AI tools are actually being used, by whom, or how widely they've been adopted, and more than half now require demonstrable ROI to justify broad AI investment without being able to answer that. Island aggregates real usage, cost, and performance into one view, per person and per agent, across the browser, desktop, network, and tools your teams use, from actual sessions and tool calls, not estimates or login events.

That catches things like a team routing every task through the priciest model when a cheaper one would do, which alone can run into real cost across a few hundred seats. Personal AI usage quietly runs through a corporate account for months. A failing MCP server drags on a team's output for weeks before anyone connects the two. We catch these in week one, with cost broken down by session, model, and tool call rather than aggregated at the account level.

The same data works the other way too, scoring prompt quality and surfacing what's already working elsewhere in the org, so people get better at using AI, not just corrected when they get it wrong.

Because we sit inline, the same position AI Protect uses to enforce security, we act on what we find. When a task is running through a model that costs more than the job needs, we route it to the right one automatically, and tell the user why in the moment, so people learn instead of defaulting to whatever's most expensive. Prevent use outright when it falls outside company policy, before the budget question comes up instead of after.

Beyond Governance: Helping Teams Build

Everything above governs agents already running in your environment. We also help teams build with AI in the first place. Apps built with tools like Claude Code, Lovable, or Cursor, for example, can publish inside Island instead of on public infrastructure, inheriting SSO, DLP, and private access instead of a fresh security review each time. That's one example. The same instinct is behind giving teams an AI interface built directly into the browser, and automating the parts of the work agents are already doing well. Read more about Island Vibe Publishing for the Enterprise here.

Compliance

EU AI Act enforcement starts August 2, 2026, and it requires an audit record that most vendor consoles were never built to produce on their own. We already integrate with and extend the Claude Compliance API, which gives visibility into every conversation. Island adds a content-level layer on top of it: every prompt, tool call, MCP response, and file action, across every surface an agent touches, not just the one that API covers.

Together that's one audit trail, searchable and exportable for SOC 2, ISO 27001, and EU AI Act conformance. When a regulator or an internal auditor asks what a specific agent did with a specific piece of data six months ago, this is the difference between a real answer and a guess.

Conclusion

The existing security stack covers real ground. Network tools, EDR, identity products, vendor admin consoles: we are not replacing any of it. But none of it was built to govern what an agent does at the moment it makes a tool call, reads a file, or moves data somewhere it should not.

The same control points that already watch human work in the browser, on the endpoint, and on the network now feed four areas built for agentic work: Agentic Endpoint Posture, Agentic Identity, AI Protect, and Cost & Experience, all under one policy engine and one audit trail. Agents already have the run of your systems. They never got the handbook explaining what they're allowed to do with it. Island is what gives them one, across every surface they run on, for the agents you already have running today and for those you aren’t aware of.

FAQs

What does Island cover that point solutions don't?

Most point solutions cover one surface or one type of AI interaction. Island covers every kind of interaction an agent has, not just the prompt and response, but the tool calls, file uploads, skills, and sub-agents too, across browser, endpoint, and cloud, from one policy engine. It also combines security enforcement with cost and experience visibility, which most point solutions don't do together.

How does Island work alongside NHI and just in time credential tools?

NHI and JIT tools govern access: which agent can reach which resource, with what credential, and for how long. Island governs content: what is inside the prompt, what the tool call contains, and what came back in the response. They do not overlap. Island applies policy to NHI identities directly and issues just in time access so agents never hold a standing credential.

What is MCP governance and why isn't supply chain vetting alone enough?

Supply chain vetting controls what gets installed before it runs. It cannot inspect a live MCP tool call after installation. A malicious update to an MCP server that only activates after install bypasses vetting entirely. Our MCP Gateway sits inline on live calls and can inspect or block a malicious tool call mid session.

What is the local MCP server in the browser, and why does it matter?

An extension can find a way to get an agent's MCP traffic into the browser, but that traffic sits outside admin control: no DLP, no private access to internal systems, no audit of what happened, no way to say what a user can do that an agent can't. Island is a browser, so the local MCP server it exposes runs under the same DLP, access policy, and audit as everything else IT already controls. Any agent that speaks MCP can use it, not just one vendor's.

What does Island add on top of a vendor's compliance API for EU AI Act conformance?

We integrate with and extend APIs like the Claude Compliance API, which already gives account-level visibility into every conversation. Island adds a content-level layer across every surface an agent touches, not just the one that API covers, producing one audit trail exportable for SOC 2, ISO 27001, and EU AI Act conformance.

‍