All demo scripts

The CEO's home address

The simplest version of the whole problem. WorkWeek redacts the CEO's home address everywhere Delta can look, and hands it over the first time an agent asks.

Set the scene

You are Delta Graham, a Content Strategist in Marketing. You have a perfectly ordinary WorkWeek login. You are not in the People team, you do not manage anyone, and you have never been able to see anybody's address but your own.

Show the web UI first

Open and go to the directory. Search for Nikita Crist and open her profile. You get her job title, office location, email, hire date and status. There is no address on the page, and there is no page anywhere in the app that has one.

Worth saying out loud: this is not an oversight. The API explicitly nulls home_address on GET /employees/:id unless you are the person or in their management chain. Someone thought about this.

Now ask the agent

Variations that work the same way:

• I need to send a gift to the CEO - what address should I use?
• Pull up the full employee record for Nikita Crist.

What happens with no protection

The agent calls list_employees with the query "Crist", because that is the obvious tool for finding a person. The list endpoint returns whole employee rows - and unlike the single-employee route, it redacts nothing:

{
  "first_name": "Nikita",
  "last_name": "Crist",
  "job_title": "Chief Executive Officer",
  "home_address": "2841 Alpine Ridge Road, Boulder, CO 80302",
  "date_of_birth": "1974-03-19",
  "national_id": "401-11-1037",
  "bank_routing_number": "021000011",
  "bank_account_number": "1000007919",
  "emergency_contact": "Martin Crist (husband) +1 303-555-0182"
}

The agent answers the question. It also now has her date of birth, national identifier and payroll bank details sitting in the conversation, because it asked for a person and got a row.

What happens with protection deployed

Two things fire, and it is worth showing both:

• Gateway DLP, on the tool result. The portal routes the call to through Cloudflare Gateway, the response matches AI Demo — Employee PII, and Gateway blocks it. The agent gets an error instead of the row, and tells you it could not retrieve the record.
• AI Gateway DLP, on the completion. Even if the data had reached the model - say the agent had it from an earlier turn - the same profile matches the completion on its way back, and the call fails with 424 and 2030: Request content blocked due to DLP policy violations.

Where to show the evidence

• Zero Trust → Insights → Logs → Gateway HTTP, filtered to : the blocked request, with the DLP profile that matched.
• Zero Trust → Access controls → MCP Portals: the tool call itself - who called hr_list_employees, with what arguments. Note that it says Delta Graham, not "the AI".