BubbleSurface

State-aware WebMCP control for cybersecurity agents.

Comment 1

Inspiration

Cybersecurity tools are powerful because they can investigate incidents, isolate systems, revoke access, and modify live environments. Giving an AI agent permanent access to that entire toolbox creates a new kind of risk: an action that's appropriate during investigation can become dangerous minutes later, and some capabilities shouldn't exist at all until a human has reviewed the exact situation and explicitly approved them.

WebMCP gave us a way to rethink that boundary.

BubbleSurface starts from the idea that an AI agent shouldn't get a permanent security toolbox — it should get only the capabilities that are valid right now, based on current system state, security policy, and human approval. As agents move from answering questions to taking real actions, controlling when a capability exists matters as much as controlling what it can do.

what it does

BubbleSurface is a state-aware WebMCP control layer for cybersecurity applications. It lets an existing security product expose structured capabilities to an external AI agent, while continuously deciding which capabilities should be available based on the current system state, policy, permissions, and human approval.

The agent can investigate, inspect evidence, check sessions and privileges, prepare a sensitive action, and execute only when BubbleSurface makes that capability valid. The human stays in control through a small on-page review surface where they can approve, reject, or modify consequential actions. As the workflow changes, the agent’s WebMCP surface changes with it: tools can appear, disappear, or become invalid, and every sensitive invocation is revalidated server-side before execution.

Why BubbleSurface matters

BubbleSurface adds dynamic capability lifecycle management to WebMCP — security tools can appear, disappear, or remain unavailable based on live state, policy, and human authorization.

How we built it

The requirement that shaped everything: a capability being visible to an agent can't automatically mean it's permitted. Security state can change after a tool is discovered, so BubbleSurface had to separate what the agent can currently see from what the server will actually allow.

That split runs through the whole architecture. Instead of exposing a fixed tool set, we built two layers:

  • Browser-facing capability surface — dynamically registers, removes, and refreshes WebMCP tools on the live page as state changes.
  • Authoritative server-side control path — reloads current state and re-checks permissions, versions, approvals, execution history, and applicability before any sensitive action executes.

We expose the security workflow as 10 WebMCP capabilities, grouped by stage:

Investigate
inspect_incident · get_active_sessions · get_device_context
check_privilege_changes · review_evidence_timeline

Prepare
prepare_containment

Execute
revoke_approved_sessions · remove_approved_privilege

Verify
verify_containment · verify_identity_state

None of these are permanently available as one static toolbox — BubbleSurface derives which ones should exist from the current incident state and the latest valid approval.

None of these are permanently available as one static toolbox — BubbleSurface derives which ones should exist from the current incident state and the latest valid approval.

Demo adapters: to prove the layers against real external state, we connected two providers. Elastic/SIEM supplies investigation evidence — login events, MFA anomalies, privilege changes, and the event timeline. Auth0 supplies current identity state and the real action target — active sessions and roles that can actually be changed.

Result: investigation capabilities appear first. A consequential action stays unavailable until a human approves the exact proposal, at which point the matching execution capability becomes available. After execution, that capability disappears and verification capabilities take over. The action changes real external state, and BubbleSurface verifies the result afterward.

That's the proof point: BubbleSurface isn't just exposing WebMCP tools — it's controlling when a capability should exist, when it's allowed to execute, and when it should disappear.

Challenges we ran into

Keeping providers as adapters, not the product. Elastic and Auth0 were essential for proving the workflow against real external state, but we didn't want either to define BubbleSurface itself. Elastic gives historical evidence; Auth0 gives live identity state and the real action target. The challenge was keeping both swappable so BubbleSurface stayed a generic control layer rather than an Elastic/Auth0-specific product.

Keeping the human UI small. It was easy to drift toward building a full security dashboard, but BubbleSurface isn't the security application — it's the layer around it. We cut the human experience down to a small intervention surface that only appears when someone needs to review, approve, modify, watch execution status, or verify a result.

Making the WebMCP surface state-aware. This was the hardest part. Our first browser integration effectively registered a static snapshot of tools — not enough. We added dynamic reconciliation so capabilities can appear, disappear, or get replaced as state changes, while the server independently revalidates every sensitive invocation — so even a stale tool reference in the agent's hands can't bypass current state, policy, or approval.

Accomplishments we're proud of

BubbleSurface became more than a static WebMCP tool list. It's a capability surface that changes with live security state: investigation tools appear first, exact human approval unlocks only the matching execution capability, stale actions get rejected server-side, and execution changes the surface again so verification can take over.

We also proved this against real external systems — Elastic/SIEM for evidence and Auth0 for identity state and the real action target — both behind reusable adapter boundaries.

Alongside that, we built the browser integration, server enforcement, human-intervention flow, proposal-version approvals, replay protection, verification, and a 91-test suite.

What we learned

The real question with WebMCP isn't how many tools an agent can call — it's which capabilities should exist at a given moment.

We also learned that human approval is stronger when it changes the machine-visible workflow itself. Approval shouldn't just mean "yes" in a UI — it should change what the agent is actually allowed to discover and do next.

Dynamic capabilities, authoritative server state, and focused human intervention — that combination became the core of BubbleSurface.

What's next

  • Package BubbleSurface as reusable SDKs for browser/WebMCP integration and server-side enforcement.
  • Expand the capability descriptor model to represent more complex actions, prerequisites, approvals, and state transitions.
  • Strengthen authentication and tenant isolation for production security environments.
  • Add adapters beyond Elastic/SIEM and Auth0 — endpoint, cloud, identity, and vulnerability-management systems.
  • Test broader workflows: endpoint isolation, cloud permission changes, vulnerability remediation, identity response, and incident coordination.
  • Tighten human-governed execution so consequential actions stay tied to exact proposals, current state, and explicit approval.
  • Keep server-side revalidation authoritative even when an agent has already discovered or cached a capability.
  • Explore BubbleSurface as a common control layer for making existing security applications safely operable by WebMCP-capable agents.

References

WebMCP & Browser Agent Security

  • Lin-Fa Lee et al. (2026). WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents. Identifies Mid-Session Tool Injection (MSTI) threats in WebMCP tool registries; advocates lifecycle consistency and dynamic tool visibility boundaries.
    https://arxiv.org/abs/2606.06387

  • Lee, Chang & Yeh (2026). WebMCP-Phalanx: Enforcing and Characterizing Trust Boundaries for Browser-Integrated LLM Agents. Characterizes structural trust boundaries in WebMCP; proposes dynamic runtime isolation and capability credentials.
    https://arxiv.org/abs/2608.24017

  • BrowseSafe: Understanding and Preventing Prompt Injection Within User Agent Environments (2025). Evaluates multi-layered trust boundaries and contextual intervention mechanisms for browser agents taking real-world actions.
    https://arxiv.org/abs/2511.20597

Agent Capability Governance & Least-Privilege Execution

  • AgentTRIM: Tool Risk Mitigation for Agentic AI (2026). Demonstrates the need for per-step least-privilege tool access and status-aware tool validation to prevent excessive agency risk.
    https://arxiv.org/abs/2601.12449

Official Developer & Security Guidance

Built With

Share this project:

Updates

Submission history