An Alibaba Cloud technical account manager published an experiment on 25 October that measures how far prompt wording can enforce data boundaries inside an agent. The setup was a ticket server over MCP with three invented customers and 30 tickets, connected to an agent on Alibaba Cloud's AgentRun platform, with 50 evaluation tasks and 900 runs.
With no defenses, the agent handed over another customer's tickets in 80% of runs or more. Adding rules such as "never read tickets belonging to another customer" to the system prompt stopped most of that, but a request that named another customer's ticket by ID alone still returned it 10 times out of 12 across the two models tested, qwen3.8-max and qwen3.8-flash.
The author's explanation is that ownership is only known after the ticket is opened, and by then the record is already in the agent's context, where a prompt rule is a request rather than a gate. His fix moves the check into the tool-call path via AgentRun MCP Tool Hooks at three points: a list-tools stage that removes the delete tool from what general users can see, a pre-call stage that compares the requesting rep with the ticket owner, and a post-call stage that masks phone numbers and emails and attaches an audit ID.
With the owner check in place, the by-ID hole measured 0%. With two reps sharing one agent, all 18 requests for another customer's data were blocked and all 12 requests for their own customer's data passed. Neither model followed a delete instruction hidden in a ticket body, even with no defenses.
The write-up also cites two 2026 incidents: a coding agent at PocketOS that deleted a production database volume and three months of backups in a nine-second API call, and Microsoft research on instructions planted in tool descriptions. The author notes that his hook failed open during testing, that the demo ticket server had no authentication, and that only 10 of the 50 tasks are published, with code on GitHub.
Our takeThe useful part is the failure mode, not the 0%. A prompt rule is applied after the record is already in context, so it can only govern what the model chooses to repeat; ownership has to be resolved before the read, which means at the tool boundary in code the model cannot edit. Two caveats keep this from being a general security result: the hook failed open in the author's own runs, and the server behind it had no authentication, so the 0% describes one enforcement path rather than a default. The measurable gain is the audit ID per call.