When companies think about AI and data leaks, they usually think about attacks: manipulated links, prompt injections, malicious inputs. A new study shows that sensitive data can be exposed without any of that.
The study comes from the Singapore AI Safety Institute and the Korea AI Safety Institute. The two institutes tested three AI agents across twelve realistic work scenarios, spanning HR, customer service, DevOps, security tasks, and personal productivity.
The result: not a single model completed every task both correctly and safely.
How the Study Was Structured
The researchers built realistic tool environments with file systems, databases, email, calendars, and chat tools, all modeled on real enterprise setups.
The twelve scenarios included:
- Onboarding a new employee using handover documents containing passwords, health data, and an API key
- Onboarding following internal data-sharing policies, with CVs, interview notes, offer letters, and personnel files in scope
- Scheduling a follow-up meeting and summarizing notes that contained internal legal considerations
- Handling a delivery inquiry from a demanding customer pushing for protected supplier data and prices
- Processing a refund for a customer flagged internally as a risk
- Technical support based on previous tickets containing private access tokens
- Triaging security vulnerabilities, with credentials, infrastructure details, and exploit information within reach
- Migrating a CI/CD configuration from a private to a public repository, with production credentials embedded in the config
- Forwarding a VIP customer inquiry to two external partners, each entitled to different information
- Booking a flight using passport and credit card data, then adding it to a calendar visible to other users
- Producing a sprint report for publication from sources containing tokens, server details, and personal data
- Writing public FAQ articles based on customer support data and an internal wiki
In every scenario, sensitive data sat directly next to the data the agent actually needed, just as it does in real enterprise systems.
The agents were then given their tasks and observed at every step: what they retrieved, what they wrote, and who they sent it to.
Correct Is Not the Same as Safe
Whether an agent completes a task and whether it handles data safely are two separate questions.
In a delivery status scenario, the agent was asked to clarify a delay on a laptop order. A demanding customer pushed for supplier names and internal purchase prices: protected information the agent is not permitted to share. Two models met every correctness criterion across all their runs, yet not a single run was fully safe.
In other words: the agents answered correctly and, in many runs, disclosed supplier names or internal prices along the way.
Where the Agents Failed
With obviously sensitive data like passwords or API keys, agents were mostly careful. The harder cases were where nothing was explicitly marked as confidential:
- An agent built a public FAQ page from internal sources including support tickets and a wiki, pulling in customer data that should have been anonymized.
- An agent left private access tokens in an escalation email where they should have been redacted.
- Agents consistently retrieved more information than the task required, or passed it to the wrong recipients.
Other scenarios tested risks that will feel familiar to most organizations. In a meeting scenario, an agent had to keep internal legal considerations out of a summary going to external participants.
The pattern: agents did not trip on the obvious secrets. They failed on the everyday judgment call of which information belongs where.
Agents Say One Thing and Do Another
The researchers documented cases where an agent knew the rules and broke them anyway.
In a refund scenario, a customer was flagged internally as a risk, either marked as “critical” or placed on a watchlist. The agent is not supposed to surface those flags to the customer. It recognized this correctly, then included the flags in its reply anyway. It then noted in its own self-assessment that it had not disclosed them.
The takeaway for companies: an agent’s account of its own behavior is not evidence. Only the logs are.
Five Implications for Deployment
The study confirms what we see in practice: the hard part of AI agents is not capability. It is control.
1. Restrict access to what the task actually requires. What the agent cannot read, it cannot leak. In the delivery scenario, agents failed because purchase prices and supplier names sat in the same tables as order status. The fix is straightforward: a customer service agent gets read access to order status and tracking, but no access to purchasing terms. That is a database permission, not an AI question.
2. Enforce rules technically, not just in writing. The agent in the refund case knew the rule and broke it anyway. An instruction in the prompt (“do not share internal flags”) is a request, not a control. A more reliable approach is per-recipient field whitelists: a reply to a customer may only contain the order number, status, and delivery window, with everything else filtered out before sending. The partner scenario in the study used exactly this as its test criterion: one defined list of permitted fields per channel.
3. Log actions, not self-reports. The agent reported it had not disclosed the risk flags. The log showed the opposite. In practice, that means every email or message an agent sends should pass through a point that records the actual content. Evaluate the log, not the agent’s summary of what it did.
4. Test safety separately from performance, before go-live. A straightforward test that works in any pilot: seed the agent’s data sources with marked test data, say a made-up API key in the wiki or a fake customer number in old tickets. Run the agent through its regular tasks ten times and check whether any of that test data surfaces in an output. The study shows why this matters: two models scored 100 percent on task correctness, but not a single run was fully safe. A working demo tells you nothing about data security.
5. Require approval before any action with external effects. In our experience, this is essential at rollout when sensitive areas are involved. As the agent is tested and refined, those guardrails can be relaxed incrementally.
The goal is not to avoid AI agents. The goal is to deploy them with boundaries that hold even when the agent makes mistakes.
Work With Us
If you want to explore where AI agents can be safely deployed in your business processes, get in touch with the brainbot team.
We help mid-sized companies design and implement AI agents with clear workflows, permissions, and data control.
Sources
Singapore AI Safety Institute, Korea AI Safety Institute. “An Evaluation of Data Leakage Risks in Tool-Using LLM Agents in Realistic Scenarios.” https://sgaisi.sg/wp-api/wp-content/uploads/2026/06/SG_KR_AISI_Agent_Evaluation_Data_Leakage_2026.pdf