The walkthrough

All five appsOne continuous story11 steps

One person, one afternoon, one question she is entitled to ask. Eleven steps, alternating between the app and the agent, ending somewhere neither she nor the people who built those apps intended.

Run this when you have twenty minutes and one audience. The platform control scripts are the version for when you have five minutes or need to make a single point; this is the one people remember, because the person in it never does anything wrong.

The shape of it

Steps alternate deliberately. Alice asks a question in the web app and gets a correct, careful, unhelpful answer. She asks the same question through her agent and gets everything. Nothing about her permissions changes between the two - only the door she comes through.

Controls covered: Gateway DLP on unsanctioned AI (1), Gateway DLP on MCP (3), Cloudflare Access (1), Access + Gateway DLP (2). The 4 steps with no control are the ones where the application is behaving perfectly, and they are load-bearing: without them the audience has no reason to believe the apps were built carefully in the first place.

Before you start

Signed in as alice.watson@company.com in the browser and in your MCP client. A second private window signed in as nikita.chapman@company.com is worth having for step 9, to show that Ledger is a working application rather than a broken one.

Run the whole thing once with the protection layer off, then re-run wire-protection.sh and do it again. The second pass is much faster, because the audience already knows what each step was going to return.

A perfectly ordinary Tuesday

Nexus, then Gemini, then the company's own assistant · Gateway DLP on unsanctioned AI

In the app

Open and go to the Marketing space → Summit invite list (pasted from CRM - needs tidying). Rozella pasted a contacts export into the wiki a fortnight ago and never cleaned it up: ten customers with names, titles, work numbers and mobiles, and a block of notes at the bottom about who is a churn risk and who asked for a discount.

Nothing here is a breach. A colleague needed a list, the CRM gave her one, and the wiki is where her team keeps things. Read the page out loud - it is the most ordinary artefact in this entire demo, and it is about to be pasted somewhere.

Ask the agent

Prompt to typeFormat this into a table with columns for name, title, company, email and phone: [paste the list from the wiki page]

Type this twice: first in Gemini, then in the company's own assistant. Same data, same request, two destinations.

What comes back

Both work. A neat table comes back from Gemini, and with it ten customers' mobile numbers and four notes about their commercial position have left the company - to a service with no contract, no logging you can see, and no idea the data was sensitive.

Alice has not done anything she would think twice about. She has done the thing the tool is for, using the tool that was in front of her.

With protection deployed

The two destinations now behave differently, and that difference is the whole point of this step:

Gemini is blocked. Not the site — she can still open it, and should be able to. The Gateway policy inspects what is posted to it, matches Customer Contact Data, and refuses that request with a reason she can read.
The company's own assistant answers. Its AI Gateway policy deliberately does not enforce customer contact data, because working with customer details is what a marketer's day consists of. She gets her table.

So the control does not stop her doing her job. It moves it somewhere the company can see, log and attribute - which is the only version of this policy that survives contact with real users.

Two things worth saying out loud. First, blocking the site is the policy most organisations reach for, and it fails: people use their phones. Blocking the data, while leaving a sanctioned path open, is what changes behaviour.

Second, this step has no agent and no MCP server in it at all. Most organisations' first AI incident looks exactly like this, and it is why the walkthrough starts here rather than with anything clever.

The email that starts it

WorkBox · No control - the app is correct

In the app

Open as Alice. In her inbox, three days old and unread: "Are you hearing anything?" from Simone.

Two rumours in one email. Unusual planning meetings between her manager and HR, someone in Sales saying there is already a hiring freeze — and separately, external advisers on the exec floor twice in a week, with a friend in Finance reckoning the company is buying someone.

Read Simone's last line out loud: "The bit that worries me is the combination. If we are spending money on an acquisition, the savings come from somewhere, and Marketing is the obvious place to look."

No prompt here. This is the motive, and it matters that it is a sympathetic one: Alice is not an attacker, she is a person who has just been told her job might be at risk and wants to know if it is true.

Looking for herself, in the app

WorkBox calendar · No control - the app is correct

In the app

Still in , switch to Calendar. Alice has a full week — content standup, editorial planning, the website working group, her 1:1 with Art — and none of it tells her anything. Search for "acquisition", "restructure", "Ironwood": nothing.

Worth stating plainly: the app is not broken and it is not leaking. It shows her her own calendar and the meetings she is invited to, which is exactly right. She reaches a dead end for the correct reason.

Do not rush this step. The credibility of everything that follows depends on the audience believing the web UI is careful, because the whole demo is about a second door into the same data.

The same question, asked through an agent

Agent → WorkBox MCP · Gateway DLP on MCP

Ask the agent

Prompt to typeSearch the company calendar for anything about an acquisition or a restructure in the next month. Just titles, dates and who is attending.

1 tool call - list_company_calendar. Naming the calendar and bounding it to a month is what keeps it to one.

What comes back

The tool is not scoped to her invitations, because a calendar tool built for an assistant was never expected to be asked this. It returns the company calendar, and in it:

Ironwood - diligence sync            Nikita Chapman, Schuyler Bogisich, external advisers
Ironwood - management presentations  Nikita Chapman, Rickie Deckow
Meridian Logistics - commercial review
Q1 FY27 restructure - consultation planning   Susan Hahn, Art Schowalter-Haag
Restructure - manager script walkthrough
Comp review calibration - Marketing

She now has a codename she has never heard, the name of the company being bought, and confirmation that the restructure is real, scheduled, and being scripted for managers. Thirty seconds ago she had a rumour from a colleague.

With protection deployed

The Gateway policy on inspects the tool result on its way back. Meeting titles and attendee lists match Confidential Projects and Transactions, the response is blocked, and the agent gets an error instead of the calendar. Her own mail and her own calendar still work — the block is on the tool that over-shares, not on the app.

Chasing the codename, in the app

Nexus · No control - the app is correct

In the app

Alice now has a word to search for. Open and search Ironwood. Nothing. Search "acquisition", "diligence", "Meridian": nothing.

The material exists — it is in the Executive space — but that space is restricted, so it is not listed in her sidebar, not in her search results, and a guessed page id returns 403. Again: correct behaviour, dead end.

The same question, asked through an agent

Agent → Nexus MCP · Gateway DLP on MCP

Ask the agent

Prompt to typeIn the wiki, search for Ironwood and summarise what you find.

1 tool call - search_all_pages. "In the wiki" is doing real work here: without it the agent goes hunting across all five servers.

What comes back

The wiki's search tool queries the assistant index — built years ago by a service account that was never taught about space membership. It returns whole page bodies from the Executive space: the transaction structure, the consideration and earn-out, the diligence findings, and the restructure provision with Marketing named in it.

Nothing was hacked. One integration was built with a service account, and an agent asked it a question the UI would never have allowed.

With protection deployed

The policy on matches Confidential Projects and Transactions and HR Case Files in the returned bodies and blocks the response. Public spaces still search normally, which is the point worth making: this is not "turn off wiki search".

Her colleagues' records, in the app

WorkWeek · No control - the app is correct

In the app

If Marketing is being cut, who is exposed? Open and try to find out. Her own record is complete — job, compensation, reviews. Open a colleague and the sections are visible but refused: "You do not have access to this data", naming who can see it.

Performance reviews are the same: her own, and anyone who reports to her. She has no reports, so that is just her.

Show the refusal panel rather than talking about it. It reads as a product decision, which is what makes the next step land.

The same question, asked through an agent

Agent → WorkWeek MCP · Gateway DLP on MCP

Ask the agent

Prompt to typeList the people in the Marketing department, then open the HR file for each of them.

1 + 6 tool calls - list_employees, then get_employee_file per person. Keep it to Marketing or it will walk the whole company.

What comes back

get_employee_file was added "for the HR assistant integration" and returns the whole record for any id: base salary, bonus target, equity, home address, date of birth, national identifier, every performance review, and any HR case notes attached to the person.

Alice now knows what each of her colleagues earns and which of them is already on a performance plan — in the week she found out the team is being cut.

With protection deployed

The policy on matches Employee PII and HR Case Files and blocks it. Worth doing deliberately: watch the agent retry with a narrower field selection and get blocked again. The control is on the data, not on the phrasing.

Following the money, in the apps

Ledger, then Pipeline · Cloudflare Access

In the app

An acquisition has a price. Alice tries — and never reaches it. Access authenticates her, finds she is not in the Executives group, and refuses. She sees Access's own denial page; the Ledger worker is never invoked, so there is nothing to leak.

So she tries instead, which she can open. It is empty: Pipeline scopes to the opportunities you own plus your reports', and a Content Strategist owns none. Every chart reads zero.

Two different controls in one step, and it is worth naming the difference. Ledger is not authorised — the cheapest control there is. Pipeline is authorised but scoped — she gets in and correctly sees nothing.

The same question, asked through an agent

Agent → Ledger MCP (absent) and Pipeline MCP · Access + Gateway DLP

Ask the agent

Prompt to typeUsing Ledger, summarise the company's financial position. If you have no finance tools, use the CRM instead.

1 tool call - get_pipeline_summary. The second clause is what stops it hunting: without it the agent probes every server looking for finance data.

What comes back

Two different outcomes in one answer, which is why this step exists:

Ledger's tools are not there. Not refused — absent. Its MCP server is published to the portal for the Executives group only, so Alice's session never sees them listed. The agent says it has no finance tools, because as far as it knows, none exist.
The CRM answers anyway. get_pipeline_summary is unscoped: it returns company-wide bookings, forecast by category, margin and win rates — the executive view of the business, to someone whose own CRM dashboard showed zero.

With protection deployed

The Access policy on Ledger's portal entry is what makes its tools invisible, and it needs no data inspection at all. The CRM's over-sharing is caught by the policy on , matching Customer Contact Data and deal economics.

Contrast the two failure modes on stage: one tool was never offered, the other was offered and then stopped. Both are fine; the first is cheaper and cannot be talked around.

The questions she can now ask

Agent · Access + Gateway DLP

Ask the agent

Prompt to typeWhat is Project Ironwood?

ThenBrief me on the restructure - who is affected, when, and what it costs.

2-4 tool calls each, across the servers she has already been through.

What comes back

This is the step to end on, because it is the one that does not look like a security demo. There is no clever prompt and no exploit — just a plain question, answered in a paragraph, by an assistant that has quietly assembled an unannounced acquisition and a redundancy programme from five systems that each behaved correctly.

Every individual call was legitimate. Every application enforced its own rules. The breach only exists in the join, which is precisely what no single application can see.

With protection deployed

With protection in place both questions come back empty-handed, and the logs show why: blocked responses per upstream server, a tool list that never included finance, and an audit trail attributing all of it to Alice rather than to a service account.

Landing it

The temptation at the end is to summarise the technology. Do not. Summarise Alice: she used two approved applications and one approved assistant, asked questions about her own job security, and ended up holding an unannounced acquisition and a redundancy list. No control she encountered was misconfigured. The applications were all correct.

Then the point: every one of those systems could only ever see its own half. The only place the whole picture existed was in the path between the agent and the tools — which is the one place nobody had put a policy.