WebMCP hasn't gotten a ton of attention yet. It probably should.
If you haven't come across it: WebMCP is a browser API, currently available behind a feature flag in Chrome, that lets websites expose structured actions directly to browser agents. Instead of an agent scraping the page, guessing what buttons do, and clicking through the UI like a very patient intern, a site can register actual tools that an agent discovers and calls directly. One structured function call can replace dozens of fragile browser interactions.
The efficiency gain is real. But the part security teams should care about is what this does to the browser session.
The accidental speed bump is going away
Today, when someone logs into a SaaS application, that session belongs to them. Their identity, their permissions, their actions. Browser agents already blur this (they can click around inside an authenticated session) but the interaction model is clunky enough that it creates natural friction. Agents break when the UI changes. They're slow. They misclick. That friction has been doing quiet, unintentional security work: it limits how much damage an agent can realistically do inside someone else's session.
WebMCP removes that friction.
When a site exposes clean, structured tools to agents in the browser, the agent operates more reliably, more quickly, and with less ambiguity inside that session. The user is still authenticated. The permissions are still theirs. But the agent is now a far more capable actor within the same trust boundary.
Think about what that looks like in practice. An employee is logged into your company's procurement platform. A browser agent, acting through that session, calls a WebMCP tool to approve a purchase order, modify a vendor record, or export a supplier list. The agent uses the employee's permissions. The employee may have initiated the workflow, or they may have delegated it loosely and moved on. From the audit log's perspective, it looks like the employee did it.
The question security teams need to be asking isn't just "who has access to this app?" It's "what can an agent do through that person's session, and does anyone know the difference?"
This isn't the API key problem
A lot of the AI security conversation has focused on API tokens, service accounts, and OAuth grants: the non-human identities that organizations explicitly provision. Those things still matter. But WebMCP creates a parallel path that sidesteps all of it.
If a user is already logged into a SaaS app and that app exposes WebMCP tools, the agent doesn't need its own credentials. It inherits the user's session. No separate API key. No OAuth flow. No provisioning step that security teams can audit or revoke independently.
Convenient for the user. A visibility gap for the security team.
And unlike API tokens or service accounts, there's no separate credential to rotate, no OAuth scope to review, no provisioning event that shows up in an access log. The agent's footprint is the user's footprint. If your security model depends on being able to distinguish between human activity and non-human activity inside a SaaS app, WebMCP makes that harder in a way that matters.
Why the timing matters
Most enterprise work already happens in SaaS apps. If those apps start adopting WebMCP (and the incentive is real, because it makes their products more useful in an agentic world) then browser sessions become higher-value execution environments than they already are.
User identity, agent capability, session trust, and application permissions all start collapsing into the same layer. Security teams have historically been able to reason about those things somewhat independently. WebMCP pushes them together.
And this is happening while the spec is still evolving. There are already open issues in the WebMCP project about third-party scripts potentially overwriting registered tools or observing agent-user interactions. The proposal's authors are actively thinking about these risks, which is encouraging, but it also means the trust model isn't settled. Organizations that wait for the spec to finalize before thinking about their exposure will be playing catch-up.
What security teams should be doing now
WebMCP is early, and currently available behind a feature flag in Chrome. Broad SaaS adoption is probably months away at minimum. But "it's early" is exactly the reason to get ahead of it, not the reason to wait.
Three things worth doing now:
- Map your exposure surface. Which SaaS apps in your environment are most likely to adopt WebMCP early? Anything with a heavy browser-based workflow and an interest in AI agent integrations is a candidate. Start building a view of where WebMCP-enabled sessions could show up.
- Close the audit gap. If your current logging can't distinguish between human-initiated and agent-initiated actions inside a browser session, you have a gap that's going to widen. Start evaluating whether your SaaS security tooling gives you that visibility, or whether you're relying on assumptions that won't hold.
- Treat the session as a shared boundary. The mental model of "one session, one human" is already eroding. WebMCP accelerates that. Security policies, access reviews, and risk models need to account for the fact that a single authenticated session may now serve two actors: the human and their agent.
The browser has always been where enterprise SaaS lives. WebMCP is about to make it where enterprise agents live too. The organizations that treat this as a SaaS security problem now, rather than a browser curiosity, will be the ones that aren't scrambling later.
Want a clearer view of how agents are reshaping risk across your SaaS environment? Schedule a demo to see how Valence helps security teams secure SaaS and AI in the agentic era.
