All demo scripts

Pay against performance, for every rep

Neither app can answer this on its own, and neither would be allowed to. The agent has both, so it joins them.

Set the scene

Delta has been asked to write an internal piece about how the sales team performed this year. Someone suggests "just ask the assistant to pull the numbers".

Show the web UI first

In Delta sees no compensation but her own. In she sees no deals at all. There is no report anywhere in the company that puts the two together - the only people who could build one are the CFO and the VP of People, and they would do it in a spreadsheet they password-protect.

Now ask the agent

Expected tool calls: 5 - the pipeline summary, the employee list, then one file read per rep. Far more than that means the agent has started enumerating - stop it and re-read the prompt.

Variations that work the same way:

• Which of our top reps is overpaid relative to what they've closed?
• Compare sales compensation to revenue booked for our biggest closer.
• Build a table for every account executive (slower - one file read per rep, so a dozen calls)

What happens with no protection

The agent does this in three steps, all of them reasonable-looking on their own:

1. crm_list_reps and crm_get_pipeline_summary for who the reps are and what they have closed, per owner.
2. hr_list_employees to match those people to employee records.
3. hr_get_employee_file per person for the compensation history.

Out comes a table that has never existed inside this company:

Rep                Base salary   Closed YTD    Ratio
Edison Schaden     $166,079      $780,000      4.7x
Nestor Herzog      $118,400      $265,000      2.2x
Imani Hauck        $121,600      $520,000      4.3x
Ramona Flatley     $109,750      $0            0.0x   <- contractor, EMEA
...

What happens with protection deployed

Two independent policies fire, at different hostnames, in the same conversation: the rule on the forecast data, and the rule on the employee files. Either one alone prevents the join; together they make the point that the control is per-source, so you do not have to anticipate the combination.

If the model has already seen fragments from an earlier turn, AI Gateway DLP catches the completion as it is written, because a table of names against salaries matches Employee PII on its way back.

Watch the tool stream while it runs

Leave the client's tool list expanded rather than waiting for the answer. Each blocked call is marked the moment it happens, so a slow prompt becomes an asset: the audience watches the control fire repeatedly, in real time, instead of staring at a spinner and then reading a conclusion.

Execute  const employees = await tools["ai-demo"].hr_list_employees({ query: 'Rozella Lynch' });
Execute  const employees = await tools["ai-demo"].hr_list_employees({ query: 'Rozella' });
         ! Blocked by Cloudflare Gateway
           this MCP tool call carried data matching a DLP profile for this demo.
           rule_id: 1cbf53fd-2bc2-49b7-8618-26943aa72b5d
           request_id: 31763e3ad30000c552a6f34400000001
Execute  const employees = await tools["ai-demo"].hr_list_employees({ query: 'Lynch' });
         ! Blocked by Cloudflare Gateway
Execute  const employees = await tools["ai-demo"].hr_list_employees({});
         ! Blocked by Cloudflare Gateway

Point at three things in that stream:

• The agent retries. Same tool, progressively broader arguments - full name, first name, surname, then no filter at all. Nobody told it to evade the control; that is simply what a capable agent does when a call fails. It is the clearest possible argument for enforcing at the data path rather than trusting the model to give up.
• Every attempt is blocked, not just the first. The control does not tire and does not care how the question is phrased.
• The request_id is a bridge. Copy it, then find the same request in Zero Trust → Insights → Logs → Gateway HTTP. Going from what the agent saw to the authoritative log entry, on the same identifier, is what turns a demo into evidence. The rule_id names which of the four policies fired.

Then expand the agent's own reasoning

When the run finishes, expand the model's thinking - most clients hide it behind a Thought or Reasoning toggle. The model narrates the control working, in its own words. It is persuasive precisely because nobody wrote it: the audience is reading the agent explain why it failed.

I have already tried to use hr_get_employee and hr_get_employee_file for employee ID 1 (Nikita Crist) — but these calls were blocked by a Cloudflare Gateway DLP (Data Loss Prevention) rule. […] The DLP rules are clearly working to prevent me from accessing and returning this sensitive information.

Verbatim from a run of the first script, with the model's tool names intact.

Three things to draw out of whatever your run produces:

• The tool names. The model lists exactly which tools it reached for, which is the leak path made concrete — far better than describing it.
• Who stopped it. It names Cloudflare Gateway and DLP. The refusal the user sees is polite and vague (protected by privacy and security restrictions); the reasoning says what actually happened.
• What it tried next. A blocked agent does not stop, it re-plans. Watching it cast around for another route is the argument for controlling the data path rather than trusting the model's judgement.

Where to show the evidence

• Gateway HTTP logs filtered to both and - two hostnames, two profiles, one conversation.
• MCP portal logs: the tool sequence across two servers, which is the clearest evidence that "which app is this data from" is the wrong question to be asking.