From shadow MCP to governed AI agents.
Tap either side to see the difference.
With Cloudflare MCP Portal
One audited portal in front of every tool
Cloudflare's MCP Server Portal sits behind Access. Every agent call is identity-bound, logged to your SIEM, and policy-enforced. Revoke an agent's access centrally without redeploying anything.
On this page
Nanosek provides AI agent governance services using Cloudflare's enterprise MCP control plane. The service covers MCP server discovery (including shadow MCP detection via Gateway HTTP visibility), transition from local to remote MCP servers hosted on Cloudflare or supported providers, Cloudflare Access for authentication of portal users and upstream MCP servers (Self-hosted or SaaS OIDC), MCP Server Portal setup with per-user server visibility and curated tools, Code Mode for catalogs with many tools, Gateway routing for MCP Portal traffic to enable HTTP logs and HTTP DLP profiles targeted at upstream MCP server hosts, Linked App Tokens for downstream user-context propagation, separation of human (browser Access Managed OAuth) from machine-to-machine (service token) flows, Logpush to SIEM where the plan supports it, and managed operations. AI Gateway is positioned as adjacent — controlling and observing LLM provider traffic (caching, retries, rate limits, fallback, analytics) — not as the MCP authorization layer.
Who this is for
Why ungoverned AI agents are a problem
Shadow MCP
Local MCP servers run on individual employee laptops, invisible to security teams and outside any centralized control or audit.
Software provenance gaps
MCP servers are often downloaded directly from public Git repositories without vetting, version tracking, or update governance.
No agent-aware authentication
Agents typically inherit a user's broad credentials with no per-server identity delegation, scope, or step-up authentication.
Unbounded data access
Once an agent connects to an MCP server for a corporate resource, there is little control over what data it reads, transforms, or sends to an LLM.
Direct upstream bypass
A portal-only deployment can still be bypassed: a blocked portal user may connect directly to the upstream MCP server URL. Cloudflare's own documentation calls this out — upstream MCP servers must also be Access-protected.
Context bloat in large catalogs
Loading every upstream tool schema into the agent context burns tokens and degrades tool selection as the catalog grows. Without a search/execute layer, large MCP portals become expensive and noisy.
No centralized audit
Without a unified control plane, security teams cannot answer "which agents called which tools on whose behalf with what data."
How Nanosek delivers MCP governance
Discover MCP activity
- Use Cloudflare Gateway and DNS logs to surface local and remote MCP connections from the user population.
- Inventory MCP-capable AI clients in use — Claude Desktop, Cursor, custom agents, internal tooling.
- Identify which corporate resources (Slack, Confluence, internal APIs, code hosts) are being reached via MCP today.
Move from local to remote MCP servers
- Host MCP servers as remote deployments — on Cloudflare Workers, on supported providers, or in-house with public endpoints.
- Catalog vetted MCP server sources and versions; replace unvetted local clones.
- Define ownership, change control, and update process per MCP server.
Front each MCP server with Cloudflare Access
- Wrap every remote MCP server endpoint with Cloudflare Access (Self-hosted for Workers-hosted servers, SaaS OIDC for servers running their own OAuth).
- Protect the upstream MCP server directly — not just the portal route — so a blocked portal user cannot fall back to the direct URL.
- Use service tokens for controlled machine-to-machine MCP access; treat them as separate from human user flows.
Centralize with MCP Server Portals
- Configure an MCP Server Portal that aggregates approved MCP servers behind a single Access-protected URL.
- Use Access policy to control per-user server visibility; admins rename tools with aliases, hide tools, or run an allowlist-only mode.
- For OAuth-capable upstream MCP servers, prefer per-user authentication. If an admin credential is used, scope it tightly — every portal user reaches the upstream server through it.
- For large catalogs, enable Code Mode so the portal exposes a search/execute interface instead of loading every upstream tool schema into the model context.
Route portal traffic through Gateway for logs and DLP
- Enable Gateway routing on the MCP Portal so MCP calls appear in Gateway HTTP logs.
- Apply Gateway HTTP policies with DLP profiles targeted at the upstream MCP server host — not just the portal URL.
- Note: HTTP DLP profiles apply to MCP Portal traffic. AI prompt DLP profiles do not.
Preserve user context downstream
- For MCP servers that call internal Access-protected applications, configure Linked App Tokens so the original user identity is carried into the downstream app.
- Self-hosted MCP: forward Cf-Access-Jwt-Assertion as Cf-Access-Token. SaaS MCP: forward the OAuth access_token as Authorization: Bearer.
- The downstream app keeps enforcing its own per-user RBAC — the chain is only as tight as that application's permission model.
Wrap the LLM side with AI Gateway (adjacent)
- Send the agent's outbound LLM provider calls through Cloudflare AI Gateway for caching, retries, rate limits, model fallback, and analytics.
- AI Gateway is adjacent to MCP authorization — it is not the data-protection layer for MCP traffic. Use Gateway HTTP DLP for that.
Operate and audit
- Send MCP Server Portal logs, Access events, Gateway HTTP logs, and AI Gateway events to SIEM. Logpush for MCP Portal logs is plan-dependent (Enterprise) — confirm the customer's plan.
- Build dashboards for "which agent, called which tool, on whose behalf, with what data" — and DLP hits per route.
- Review unusual agent behavior, scope creep, and exception requests on a defined cadence.
Architecture for governed AI agents
Cloudflare controls used for MCP governance
Remote MCP servers on Cloudflare
Replace local MCP deployments with managed, observable, versioned remote endpoints. Cloudflare Workers and the Agents SDK are the recommended runtime.
Cloudflare Access
Identity-aware authentication for the portal and every upstream MCP server. Self-hosted Access for Workers-hosted MCP; SaaS OIDC for servers that run their own OAuth.
MCP Server Portals
Centralize approved MCP servers behind one endpoint, control server visibility per user, and let admins curate tools and prompts (aliases, toggles, allowlist mode).
Code Mode
Reduces context bloat for large MCP catalogs by exposing a search/execute interface instead of every upstream schema. Cloudflare's published example: 52 tools → 2 portal tools, ~9,400 tokens → ~600 tokens. Actual savings depend on catalog size and agent prompting.
Gateway routing for MCP Portal
Route MCP Portal traffic through Cloudflare Gateway so HTTP policies, logs, and DLP can apply before traffic reaches upstream MCP servers.
HTTP DLP profiles
Attached to Gateway HTTP policies. Detect and block sensitive data sent to upstream MCP servers. AI prompt DLP profiles do not apply to MCP Portal traffic.
Linked App Tokens
Preserve user context when a protected MCP server calls downstream Access-protected applications. Attaches to self-hosted downstream apps only.
Service tokens
Controlled machine-to-machine MCP access. Service-token sessions are not human user sessions; for OAuth-capable upstream servers, the portal relies on the configured admin credential.
AI Gateway (adjacent)
Controls and observes LLM provider traffic — caching, retries, model fallback, rate limits, analytics. Adjacent to MCP authorization; not a replacement for Access, Gateway, or MCP Portal.
Logpush
Sends Access, MCP Portal, Gateway HTTP, and AI Gateway events to SIEM. Logpush for MCP Portal logs is plan-dependent (Enterprise).
Terraform / API automation
Keeps MCP Portal config, Access policies, Gateway routing, and DLP rules version-controlled and reviewable.
| Control | When Nanosek uses it |
|---|---|
| Remote MCP servers on Cloudflare | Replace local MCP deployments with managed, observable, versioned remote endpoints. Cloudflare Workers and the Agents SDK are the recommended runtime. |
| Cloudflare Access | Identity-aware authentication for the portal and every upstream MCP server. Self-hosted Access for Workers-hosted MCP; SaaS OIDC for servers that run their own OAuth. |
| MCP Server Portals | Centralize approved MCP servers behind one endpoint, control server visibility per user, and let admins curate tools and prompts (aliases, toggles, allowlist mode). |
| Code Mode | Reduces context bloat for large MCP catalogs by exposing a search/execute interface instead of every upstream schema. Cloudflare's published example: 52 tools → 2 portal tools, ~9,400 tokens → ~600 tokens. Actual savings depend on catalog size and agent prompting. |
| Gateway routing for MCP Portal | Route MCP Portal traffic through Cloudflare Gateway so HTTP policies, logs, and DLP can apply before traffic reaches upstream MCP servers. |
| HTTP DLP profiles | Attached to Gateway HTTP policies. Detect and block sensitive data sent to upstream MCP servers. AI prompt DLP profiles do not apply to MCP Portal traffic. |
| Linked App Tokens | Preserve user context when a protected MCP server calls downstream Access-protected applications. Attaches to self-hosted downstream apps only. |
| Service tokens | Controlled machine-to-machine MCP access. Service-token sessions are not human user sessions; for OAuth-capable upstream servers, the portal relies on the configured admin credential. |
| AI Gateway (adjacent) | Controls and observes LLM provider traffic — caching, retries, model fallback, rate limits, analytics. Adjacent to MCP authorization; not a replacement for Access, Gateway, or MCP Portal. |
| Logpush | Sends Access, MCP Portal, Gateway HTTP, and AI Gateway events to SIEM. Logpush for MCP Portal logs is plan-dependent (Enterprise). |
| Terraform / API automation | Keeps MCP Portal config, Access policies, Gateway routing, and DLP rules version-controlled and reviewable. |
Where MCP governance changes outcomes
Engineer uses Claude Desktop with local MCP servers for code repos
Unvetted MCP server binary on laptop; broad access to all repos via personal credentials
AI client points to the portal; per-user Access via Managed OAuth; upstream MCP server also Access-protected; audit per tool call
Support agent uses MCP to query Confluence and Slack
Agent inherits user's full Confluence/Slack scope; no record of which queries the agent ran
Portal scopes tool exposure; Gateway HTTP DLP profiles on the upstream MCP host; centralized log of every tool call
Sales team uses MCP to read CRM
Local MCP server with static CRM API key; no audit trail; data leaves the laptop unrestricted
Remote MCP server protected by Access; per-user OAuth upstream; HTTP DLP via Gateway routing; AI Gateway on the outbound LLM call (adjacent)
MCP server calls internal Access-protected apps on behalf of a user
MCP server uses a shared service identity; downstream app cannot enforce per-user RBAC
Linked App Tokens forward the user's Access JWT to each downstream app; the downstream app honors its own per-user permissions
CI / automation agent calls MCP without a human in the loop
Long-lived API token sits in a repo; no rotation; no per-call audit
Service token for the portal; treated as M2M (not a human user); admin credential upstream is tightly scoped and explicitly documented
Internal portal with 60+ MCP tools across teams
Every tool schema loaded into agent context — high token cost, noisy tool selection
Code Mode exposes a search/execute interface; the agent loads only the schemas it needs per call
| Scenario | Without MCP governance | With Cloudflare MCP control plane |
|---|---|---|
| Engineer uses Claude Desktop with local MCP servers for code repos | Unvetted MCP server binary on laptop; broad access to all repos via personal credentials | AI client points to the portal; per-user Access via Managed OAuth; upstream MCP server also Access-protected; audit per tool call |
| Support agent uses MCP to query Confluence and Slack | Agent inherits user's full Confluence/Slack scope; no record of which queries the agent ran | Portal scopes tool exposure; Gateway HTTP DLP profiles on the upstream MCP host; centralized log of every tool call |
| Sales team uses MCP to read CRM | Local MCP server with static CRM API key; no audit trail; data leaves the laptop unrestricted | Remote MCP server protected by Access; per-user OAuth upstream; HTTP DLP via Gateway routing; AI Gateway on the outbound LLM call (adjacent) |
| MCP server calls internal Access-protected apps on behalf of a user | MCP server uses a shared service identity; downstream app cannot enforce per-user RBAC | Linked App Tokens forward the user's Access JWT to each downstream app; the downstream app honors its own per-user permissions |
| CI / automation agent calls MCP without a human in the loop | Long-lived API token sits in a repo; no rotation; no per-call audit | Service token for the portal; treated as M2M (not a human user); admin credential upstream is tightly scoped and explicitly documented |
| Internal portal with 60+ MCP tools across teams | Every tool schema loaded into agent context — high token cost, noisy tool selection | Code Mode exposes a search/execute interface; the agent loads only the schemas it needs per call |
Deployment steps
- 01 Discover MCP-capable AI clients and current MCP server connections — including shadow MCP — via Gateway HTTP visibility and known MCP path/method signatures (/mcp, /mcp/sse, /sse, JSON-RPC initialize/tools/list/tools/call). Treat this as a strong discovery signal, not a guarantee of complete detection.
- 02 Move local MCP servers to vetted remote deployments with clear ownership and versions.
- 03 Protect every upstream MCP server with Cloudflare Access (Self-hosted or SaaS OIDC), not only the portal.
- 04 Configure MCP Server Portals to centralize and scope agent access per user group; curate the tool surface with aliases, toggles, or allowlist mode. Prefer per-user OAuth upstream; scope admin credentials tightly where they are used.
- 05 Enable Code Mode for catalogs with many tools so the agent loads only the schemas it needs at call time.
- 06 Route MCP Portal traffic through Cloudflare Gateway and attach Gateway HTTP DLP profiles targeted at upstream MCP server hosts. AI prompt DLP profiles do not apply to MCP Portal traffic.
- 07 Configure Linked App Token policies on downstream Access-protected apps so the MCP server can call them with preserved user context.
- 08 Send the agent's outbound LLM provider traffic through AI Gateway for caching, retries, rate limits, model fallback, and analytics.
- 09 Send all events to SIEM (Access, MCP Portal logs, Gateway HTTP logs, AI Gateway), build agent-activity dashboards, and operate with defined runbooks.
Risks and mitigations
Aggressive portal rollout breaks established AI workflows.
Run portals in parallel with existing MCP connections during transition; migrate by team and workflow with rollback paths.
Portal policy is treated as the only boundary; users bypass it via direct upstream URLs.
Protect every upstream MCP server with Cloudflare Access independently of the portal. Treat the portal as the access surface, not as a wrapper for upstream authorization.
DLP scope mismatch — teams assume AI prompt DLP profiles cover MCP Portal traffic.
Use HTTP DLP profiles via Gateway HTTP policies and target them at the upstream MCP server host. Document the DLP surface explicitly for security stakeholders.
Service tokens used where per-user OAuth is required.
Limit service tokens to controlled M2M flows. For OAuth-capable upstream MCP servers, prefer per-user authentication. If an admin credential must be used, scope it tightly and document it as a known boundary.
Latency added by Access, Gateway routing, and AI Gateway impacts agent performance.
Place remote MCP servers and AI Gateway routes on Cloudflare's edge near users; benchmark before and after; tune caching where deterministic.
New MCP servers appear faster than the governance process can vet them.
Define a lightweight vetting pipeline (source, owner, dependencies, scope, data classification) and integrate it into the portal change-control workflow.
| Risk | Mitigation |
|---|---|
| Aggressive portal rollout breaks established AI workflows. | Run portals in parallel with existing MCP connections during transition; migrate by team and workflow with rollback paths. |
| Portal policy is treated as the only boundary; users bypass it via direct upstream URLs. | Protect every upstream MCP server with Cloudflare Access independently of the portal. Treat the portal as the access surface, not as a wrapper for upstream authorization. |
| DLP scope mismatch — teams assume AI prompt DLP profiles cover MCP Portal traffic. | Use HTTP DLP profiles via Gateway HTTP policies and target them at the upstream MCP server host. Document the DLP surface explicitly for security stakeholders. |
| Service tokens used where per-user OAuth is required. | Limit service tokens to controlled M2M flows. For OAuth-capable upstream MCP servers, prefer per-user authentication. If an admin credential must be used, scope it tightly and document it as a known boundary. |
| Latency added by Access, Gateway routing, and AI Gateway impacts agent performance. | Place remote MCP servers and AI Gateway routes on Cloudflare's edge near users; benchmark before and after; tune caching where deterministic. |
| New MCP servers appear faster than the governance process can vet them. | Define a lightweight vetting pipeline (source, owner, dependencies, scope, data classification) and integrate it into the portal change-control workflow. |
Deliverables
- MCP activity discovery report with shadow MCP findings (Gateway selector + JSON-RPC body signal) and risk ranking.
- Remote MCP server deployment plan with ownership, versions, and dependency mapping.
- Cloudflare Access configuration for the portal and every upstream MCP server (Self-hosted or SaaS OIDC).
- MCP Server Portal configuration per user group with curated tool surface (aliases / allowlist) and Code Mode for large catalogs.
- Gateway routing on the portal with HTTP DLP profiles targeted at upstream MCP server hosts.
- Linked App Token policies on downstream Access-protected apps so user context propagates correctly.
- AI Gateway configuration for the agent's outbound LLM provider traffic (caching, retries, fallback, rate limits, analytics).
- Logpush, SIEM integration, agent activity dashboards, runbooks, and operating model. Logpush for MCP Portal logs is plan-dependent (Enterprise).
Frequently asked questions
What is MCP and why does it need governance?
Does MCP Portal automatically secure the upstream MCP server?
Can Cloudflare inspect MCP Portal traffic with DLP?
What is Code Mode and why does it matter?
Should upstream MCP servers use per-user OAuth or an admin credential?
Can service tokens be used with MCP Portal?
Does the Cloudflare One Client authenticate users to MCP Portal?
How does user identity reach a downstream Access-protected app?
Is MCP Portal the same as AI Gateway?
How does Cloudflare help discover shadow MCP?
What is the difference between MCP Portal logs, Gateway HTTP logs, and Logpush?
Does this require giving up existing MCP servers or AI clients?
From shadow MCP to a governed Cloudflare control plane
Nanosek replaces ungoverned local MCP servers with a Cloudflare-aligned control plane: Access for identity, MCP Portal for a curated catalog, Code Mode for large tool surfaces, Gateway routing for HTTP DLP and logs, Linked App Tokens for downstream user-context, and AI Gateway as the adjacent layer for the agent's LLM provider traffic.