🌐 Trang này chưa được dịch sang tiếng Việt — đang hiển thị nội dung tiếng Anh.

Module 7b — Secure AI & MCP with Access (MCP Server Portals)

Goal: Bring the AI tools your people (and your AI agents) use under Zero Trust control — put internal MCP servers behind Cloudflare Access, and give users one governed MCP portal endpoint with curated tools, per-user identity, and full logging.

🧭 What's MCP? The Model Context Protocol is how AI assistants (Claude, ChatGPT desktop, Cursor, etc.) connect to external tools and data — file systems, wikis, databases, SaaS APIs. Every MCP server an agent can reach is a new door into your data. This module puts identity, policy, and logging in front of those doors.

💡 This expands Part E of Module 7. Module 7 governs users browsing to AI apps; this module governs AI agents connecting to tools.

Why secure MCP

There are two building blocks. Do them in order:

1. Secure individual MCP servers — bring each server under Access (Part A–B).
2. Create an MCP portal — aggregate servers into one governed endpoint (Part C–E).

Part A — Choose how to secure each MCP server

Cloudflare Access can front an MCP server in a few ways. Pick per server:

⭐ Recommended: for servers you control, use the self-hosted approach and let Access handle authentication. Only use the SaaS/OIDC approach when a provider-hosted server requires it.

Making Access the OAuth provider (SaaS-managed) — the short version

1. 👉 Access controls → Applications → Create new application → SaaS application.
2. ⌨️ Name it (e.g. MCP server), choose OIDC, Add application.
3. ⌨️ In Redirect URLs, enter the MCP server's callback URL (e.g. https://<mcp-host>/callback).
4. 📋 Copy the Client ID, Client secret, Token / Authorization / Key endpoints into your MCP server's config.
5. 👉 Add Access policies (who can use it) and select your identity providers. Save.

⚠️ Only enable Managed OAuth for MCP server code that validates the Access JWT (Cf-Access-Jwt-Assertion header). For third-party code you can't change, use the server's own OAuth flow.

Part B — Add an MCP server to Access

Bring each server under centralized management (this is also the prerequisite for putting it in a portal).

1. 👉 In the dashboard, go to Zero Trust → Access controls → AI controls.
2. 👉 Open the MCP servers tab → Add an MCP server.
3. ⌨️ Enter a name (e.g. Company Wiki MCP).
4. ⌨️ (Optional) set a custom Server ID.
5. ⌨️ In HTTP URL, enter the server's full URL — e.g. the Cloudflare Docs MCP server: https://docs.mcp.cloudflare.com/mcp.
6. 👉 Add Access policies to show/hide the server: users who match an Allow policy will see it in a portal; others won't.
7. 👉 Click Save and connect server.
8. 👉 If the server supports OAuth, log in when redirected — that account becomes the admin credential for this server (a portal can use it to make requests).

📺 What you'll see: Access validates the connection, pulls the list of tools/prompts/resources, and the server status becomes Ready.

⚠️ Watch out: Adding Access policies here controls visibility in portals. A blocked user could still hit the server via its direct URL — to truly enforce auth, make Access the server's OAuth provider (Part A).

✅ Checkpoint: Your MCP server shows Ready in the MCP servers tab.

Part C — Create an MCP server portal

A portal gives your users and agents one endpoint that aggregates multiple MCP servers, with only the tools you choose.

1. 👉 Zero Trust → Access controls → AI controls → Add MCP server portal.
2. ⌨️ Enter a name (e.g. Engineering AI Tools).
3. 👉 Under Custom domain, pick a domain (must be an active zone in your account); optionally set a subdomain (e.g. mcp).
4. 👉 Add MCP servers — select the servers from Part B you want in this portal.
5. 👉 (Optional) Under MCP servers, configure the tools and prompts exposed through the portal — expose only what this audience needs.
6. 👉 Set Require user auth per server:
   • Enabled (default) — each user authenticates with their own credentials to that server (least privilege, best audit trail).
   • Disabled — connected users reach the server via its admin credential (use sparingly).
7. 👉 Add Access policies defining who can connect to the portal.
8. 👉 Click Add an MCP server portal.

📺 Users now connect at https://<subdomain>.<domain>/mcp with any MCP client.

⚠️ Policy limitation: Independent MFA, purpose justification, and temporary authentication are not enforced for servers authorized through a portal. If a server needs step-up MFA, enforce it at the server's own Access application.

✅ Checkpoint: The portal appears in AI controls with your chosen servers, and the portal URL resolves.

Part D — Curate tools, prompts & aliases

The less irrelevant context you expose, the better (and safer) the AI's responses.

• 👉 Choose specific tools/prompts per portal (Part C step 5) so users get a focused toolset.
• 👉 Rename with aliases: edit a tool's or prompt's name and description at the portal or server level — without changing the upstream server. Clear names help both people and AI agents pick the right tool.
• 👉 Optimize context: portals support query-parameter options to minimize or hide tool definitions and reduce context-window usage.
• 💡 Code Mode (on by default): collapses all tools into a single code tool — the agent writes JavaScript that calls typed methods, run in an isolated Cloudflare Worker. Context usage stays fixed no matter how many tools you add.

Part E — Connect clients & agents (Managed OAuth + service tokens)

Human users / interactive AI clients — Managed OAuth

Managed OAuth is on by default for new portals. It lets non-browser MCP clients (Claude Desktop, Cursor, CLIs, SDKs) authenticate via a standard OAuth 2.0 authorization-code flow: the client gets a 401 with a WWW-Authenticate header, opens the browser to your Access login, and receives a token. Same Access policies, new transport.

• 👉 To confirm/enable: portal → ⋯ → Edit → Advanced settings → Managed OAuth → on → Save.

Bots / autonomous agents — service tokens

For machine-to-machine agents that can't do a browser login:

1. 👉 Create an Access service token (Access → Service Auth → Service Tokens).
2. 👉 Add a Service Auth policy matching that token to the portal's Access application and to each linked server's application.
3. 👉 Turn Require user auth off for those servers (the portal uses the admin credential).
4. 👉 The agent connects with CF-Access-Client-Id and CF-Access-Client-Secret headers and sees the tools of every server it's authorized for.

⚠️ Servers that still require per-user OAuth are excluded from service-token sessions (a token can't complete a per-user grant).

✅ Checkpoint: An MCP client connects to https://<subdomain>.<domain>/mcp, authenticates through Access, and sees only the curated tools.

Part F — Observability & DLP

1. 👉 Access logs record each individual tool request made through the portal — go to Logs → Access to see who/what invoked which tool.
2. 👉 (Optional, powerful) Route portal traffic through Gateway to get richer HTTP logging and DLP scanning — so sensitive data flowing into or out of MCP tools is inspected with the same DLP profiles from Module 6.

✅ Checkpoint: Tool calls appear in Access logs; if routed through Gateway, they also show in Gateway HTTP logs with any DLP matches.

✅ Module 7b complete!

You now have:

• ✅ MCP servers brought under Access (with Access optionally the OAuth provider)
• ✅ A single MCP portal endpoint aggregating curated tools
• ✅ Per-user identity (Require user auth) and service-token access for bots
• ✅ Managed OAuth for non-browser AI clients
• ✅ Request-level logging, optionally with Gateway + DLP

How this fits the bigger AI picture

Quick troubleshooting

👉 Next: Module 8 — Cloudflare WAN

Connect whole offices and data centers to Cloudflare.