Notifications
Clear all
Topic starter
11/07/2026 8:23 pm
TL;DR: Remote MCP deployments let AI agents complete multi-step, tool-using workflows, including impersonation, browser automation, and authenticated booking flows, according to Stytch’s episode with Cloudflare. The governance issue is not the demo itself but the fact that agent identity, tool scope, and execution timing now need controls built for runtime action, not chat.
NHIMG editorial — based on content published by Stytch: Agent ready episode 3 with Cloudflare, deploying remote MCP at the edge
Questions worth separating out
Q: How should security teams govern remote MCP tools that can act on behalf of users?
A: Treat each remote MCP tool as a delegated identity surface with its own approval scope, logging requirements, and failure mode.
Q: Why do remote MCP workflows create new identity risk compared with normal API integrations?
A: They let an agent choose tools at runtime and chain them inside an authenticated session, which collapses the boundary between integration and execution.
Q: What do security teams get wrong about agent authentication and tool authorization?
A: They often assume a valid login is enough to trust the workflow.
Practitioner guidance
- Classify every MCP tool as a privileged identity surface Document which tools can read data, impersonate users, request secondary verification, or change state.
- Separate authentication from action authorisation Require distinct controls for proving the caller, allowing tool invocation, and approving state-changing steps such as booking or submission.
- Limit agent-facing tools to deterministic inputs and outputs Use narrow schemas, predictable responses, and single-purpose endpoints so the agent cannot improvise unsafe action chains.
What's in the full article
Stytch's full blog post covers the operational detail this post intentionally leaves for the source:
- Walkthrough of the remote MCP server code path, including tool initialisation, schema handling, and browser automation bindings.
- Demo sequence for the tennis booking workflow, including authentication handoff, SMS verification, and retry handling.
- Implementation details for Cloudflare Workers, KV storage, and browser rendering in the hosted MCP setup.
- Practical guidance on keeping tools deterministic and avoiding tool soup when building agent-ready workflows.
👉 Read Stytch's blog on deploying remote MCP at the edge for agent workflows →
Remote MCP at the edge: what it means for agent identity controls?
Explore further
11/07/2026 8:53 pm
Remote MCP is turning agent identity into a live authorisation problem: When an LLM can invoke tools, browse pages, and complete booked transactions, the security question shifts from model safety to delegated access control. The old assumption that the system is only generating content no longer holds once it can act inside authenticated sessions. Practitioners should treat every remote MCP path as an identity plane, not an integration convenience.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can organisations keep agent-driven browser automation from becoming over-privileged?
A: Use narrow browser tools, explicit schemas, and session logging so each action is understandable and reviewable. Do not give a general-purpose browser full authority to complete any task the agent invents. The safer pattern is a constrained executor with clearly bounded actions and visible outcomes.
👉 Read our full editorial: Remote MCP at the edge exposes new agent identity controls
