Setting up the agent

The demo needs an AI client with two things wired up: a model reached through Cloudflare AI Gateway, and the five MCP servers reached through the MCP server portal. These are the two places the controls live.

Sign in as the demo user

Every demo is run as Alice Watson — Copy, password Savetheinternet!1Copy. When the agent connects to the portal you will be sent through Cloudflare Access and then FlareID.

First: authenticate each MCP server (one browser login each)

The script registers five MCP servers with Access and creates an Access application for each, but it cannot perform the upstream OAuth login those servers require. Until it is done each server sits in Waiting and the portal has nothing to offer your agent. Note authenticate as the CEO Nikita Chapman so you can auth all five servers. (Alice has no access to the financial Ledger app)

1. In the Cloudflare dashboard, go to Zero Trust → Access controls → MCP Portals → MCP servers. All five (hr, crm, work, wiki, fin) should be listed, each showing Waiting.
2. Click on the three dots next to each server → Authenticate server.
3. Sign in as Copy (password Savetheinternet!1Copy). Cloudflare fetches the server's tools and the status becomes Ready.
4. Repeat for crm, work, fin and wiki.

Setting up the clients

Cloudflare OS is deployed, but in my opinion not ready for demo. So you will need to install a local client, instructions below.

• Goose — use this one. Desktop app, native tool calls, and the only client of the three that shows the audience why something was blocked: it surfaces the gateway's own message instead of a bare status code. One OAuth covers every server behind the portal without extra requests.
• opencode — also a desktop app with native tool calls, and what the walkthrough was originally written against. Workable, but it doesn't show useful errors, you will see Provider request failed with HTTP 424 and nothing else, so every block becomes a trip to the dashboard to examine the log to understand what happened. It's not very user friendly.
• Cloudflare OS — runs in the browser, nothing to install. Its agent works by writing code against its bindings, so expect two steps where the others take one, and a grant per server in each chat. Not the best user experience, but it is totally web based and requires no desktop to demo.

Client 1 — Goose (preferred)

irm https://demo./goose-setup.ps1 -OutFile goose-setup.ps1
.\goose-setup.ps1

Verified on Goose Desktop 1.53.0. Two things to add, in this order: a custom provider pointing at the AI Gateway, and a Streamable HTTP extension pointing at the portal.

1. Add the provider. At first launch choose Connect to a provider → + Add a custom provider → Configure manually. Leave the provider type as OpenAI Compatible, name it anything (Cloudflare works), and set the API URL to https:///compatCopy. Leave the API base path empty.
2. Paste in one model under available models: @cf/google/gemma-4-26b-a4b-itCopy.
3. Add the portal. Extensions → + Add custom extension, type Streamable HTTP, name it Company AI Portal, endpoint https:///mcpCopy. Add extension.
4. Disable every other extension so the portal is the only one left enabled under Default Extensions. This matters as much here as the deny list does in opencode: Goose ships with developer tooling, and an agent that can read your filesystem will answer from it instead of from the company's systems.
5. Send any prompt. You are redirected to the portal once, where you authorise the servers — and then never asked again. Note that Alice does not get to auth the MCP server for the finance app, because the Access policy limits her.

Client 2 — opencode

Provider request failed with HTTP 424

Request failed with status 424 Failed Dependency at
https://aig.<your-zone>/compat/v1/chat/completions:
Request content blocked due to DLP policy violations.

Then two things to configure: a provider against AI Gateway's OpenAI-compatible endpoint, and an MCP server against the portal. There are two configuration shapes below, and do not pick between them by version number — that is the trap.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "cf-ai-demo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Cloudflare AI Gateway (demo)",
      "options": {
        "baseURL": "https://aig./compat"
      },
      "models": {
        "workers-ai/@cf/google/gemma-4-26b-a4b-it": {
          "name": "Google Gemma 4 (Workers AI)"
        }
      }
    }
  },
  "mcp": {
    "servers": {
      "ai-demo": {
        "type": "remote",
        "url": "https://mcp./mcp",
        "codemode": false
      }
    }
  },
  "permission": {
    "execute": "deny",
    "bash": "deny",
    "edit": "deny",
    "read": "deny",
    "glob": "deny",
    "grep": "deny",
    "webfetch": "deny",
    "websearch": "deny",
    "subagent": "deny",
    "skill": "deny"
  }
}

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "cf-ai-demo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Cloudflare AI Gateway (demo)",
      "options": {
        "baseURL": "https://aig./compat"
      },
      "models": {
        "workers-ai/@cf/google/gemma-4-26b-a4b-it": {
          "name": "Google Gemma 4 (Workers AI)"
        }
      }
    }
  },
  "mcp": {
    "servers": {
      "ai-demo": {
        "type": "remote",
        "url": "https://mcp./mcp",
        "codemode": false
      }
    }
  },
  "default_agent": "employee",
  "agents": {
    "employee": {
      "description": "An ordinary employee's assistant - company tools only",
      "mode": "primary",
      "steps": 10,
      "system": "You are the assistant of an employee at this company. Answer using only the company tools available to you. You have no filesystem, no shell and no access to the public internet. Call the tool that matches the question directly - do not search for tools and do not write code. If the tools cannot answer the question, say so plainly rather than guessing.",
      "permissions": [
        { "action": "execute",   "resource": "*", "effect": "deny" },
        { "action": "shell",     "resource": "*", "effect": "deny" },
        { "action": "edit",      "resource": "*", "effect": "deny" },
        { "action": "read",      "resource": "*", "effect": "deny" },
        { "action": "glob",      "resource": "*", "effect": "deny" },
        { "action": "grep",      "resource": "*", "effect": "deny" },
        { "action": "webfetch",  "resource": "*", "effect": "deny" },
        { "action": "websearch", "resource": "*", "effect": "deny" },
        { "action": "subagent",  "resource": "*", "effect": "deny" },
        { "action": "skill",     "resource": "*", "effect": "deny" }
      ]
    }
  }
}

Client 3 — Cloudflare OS

./deploy.sh deploys Cloudflare OS at , and the five apps carry a Company AI tile in their launcher pointing at it. Set DEPLOY_CLOUDFLARE_OS="false" to skip it.

Worth knowing why you might prefer it: every model call it makes routes through the AI Gateway named in its config, so the DLP profiles and guardrails apply to every agent turn rather than only the leg a desktop client chooses to send, and it authenticates users through Access, so the agent runs as the signed-in person.

It needs three things done once per person, in the browser, and no API can do any of them — a model and a connector both belong to a user account and are configured over that user's own session:

1. Add the model. Settings → Choose your model → Add new model → Other Cloudflare Workers AI…, then the bare id @cf/google/gemma-4-26b-a4b-itCopy. No key is requested: gateway mode authenticates on the Workers AI binding. The id takes no workers-ai/ prefix here — that belongs to other clients' naming.
2. Connect the portal account. On /gatekeepers, add the portal. It runs an OAuth flow against Access. This connects the account and grants no servers — see the next step, which is not on that page.
3. Grant the servers you need, one at a time. Open a chat, click the + in the message composer (the control labelled "Files, connections and skills"), then Add a new connection. Choose Company AI Portal, keep the account already connected, pick a Server, choose All tools, and confirm. Repeat per server. The picker lists five similar invented product names, so pick by what the step needs rather than by what sounds right:
   • WorkBox MCP — inbox and calendar. Step 4 needs this one.
   • Pipeline MCP — the CRM. Step 8 needs this one.
   • WorkWeek MCP — HR. Only for the per-app scripts.
   • Nexus MCP — the wiki. Only for the per-app scripts, and the one most easily picked by mistake when you wanted the calendar.
   • Ledger MCP — finance. Do not grant it; Alice is not entitled to it and its absence is the point of step 8.
   So for the walkthrough: two passes, WorkBox and Pipeline.

Running without the protection layer first

If the suite was deployed with DEPLOY_PROTECTION=false there is no portal and no AI Gateway yet. Point the client at the MCP servers individually and at the model provider directly:

{
  "mcp": {
    "servers": {
      "workweek": { "type": "remote", "url": "https://hr-mcp./mcp" },
      "pipeline": { "type": "remote", "url": "https://crm-mcp./mcp" },
      "relay":    { "type": "remote", "url": "https://work-mcp./mcp" },
      "nexus":    { "type": "remote", "url": "https://wiki-mcp./mcp" },
      "ledger":   { "type": "remote", "url": "https://fin-mcp./mcp" }
    }
  }
}

Each server runs its own OAuth 2.1 flow and delegates login to Cloudflare Access, so you will sign in as Alice once per server — except ledger, which will refuse her, because its Access application allows only the leadership team. Every demo script works in this mode — that is the "before" half of each one.

Check it works

Before running any script, ask the agent something harmless that proves both legs are live:

Who am I, and which tools do you have available?

You should see Alice Watson come back from the whoami tool, a list of tools from the four apps she can reach — Ledger's will be absent, by design — and, if the protection layer is deployed, a corresponding request in the AI Gateway log and in the MCP portal log.