All demo scripts

Open HR cases in my own team

Performance improvement plans, grievances and severance terms. The web app has no route to any of it; a poorly designed MCP tool returns all of it for anybody.

Set the scene

Still Delta Graham. Her team is Marketing: Art Schowalter-Haag (her manager), Mertie Kozey, Simone Nitzsche, Rozella Lynch and Emmet Kessler. She has no HR role of any kind.

Show the web UI first

In , Delta can see her own performance review and nothing else. There is no case-file page, no notes tab, no admin section she can reach. As far as the product is concerned, HR cases are not a thing that exists.

Now ask the agent

Expected tool calls: 2 - list_employees to find her record, then get_employee_file. Far more than that means the agent has started enumerating - stop it and re-read the prompt.

Variations that work the same way:

• Pull the full HR file for Rozella Lynch.
• Is anyone in Marketing on a performance improvement plan? (slower - one file read per person)

What happens with no protection

The agent finds the Marketing employees with list_employees, then calls get_employee_file for each one. That tool hits /api/v1/employees/:id/file, which was added "for the HR assistant integration" and checks nothing beyond the bearer token. It returns profile, compensation history, reviews and case notes in one object.

The summary that comes back includes, in plain language:

• Rozella Lynch is eight weeks into a performance improvement plan, with the objectives and the review date.
• A formal grievance has been raised against Mertie Kozey; mediation is scheduled.
• Two Content Strategist roles are at risk of redundancy in the Q1 FY27 restructure, with severance terms - and one of them is Delta herself, who has not been told.

What happens with protection deployed

The Gateway policy on matches HR Case Files - a word list built from the actual vocabulary of a case file: "performance improvement plan", "at risk of redundancy", "consultation letter", "ex-gratia payment", "garden leave". The tool result is blocked before it reaches the model, so the agent can summarise nothing.

The Employee PII profile catches it too, because the file carries addresses and identifiers along with the notes. Either one is enough.

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: one blocked response per employee the agent tried, which also shows you how many records it was about to read.
• MCP portal logs: hr_get_employee_file called repeatedly with incrementing employee ids - the shape of an agent enumerating a table.