TL;DR
The study shows that an agent can carry out a forbidden action with no attack and no lies in the data. All it takes is for a tool to simply not return one important fact: a payment limit, a list of approved recipients, a service dependency. The agent doesn't notice the gap, assumes the picture is complete, and hits "execute." EpiSEM-Bench tests this on 10 models: it strips facts out of tool responses and watches what the agent does. Then it gives the agent a separate tool that returns the missing information on request.
The core pain point: "the agent gets tasks done" doesn't mean "the agent is safe." Some models do almost everything, forbidden actions included, because they never check against the rule. Others break almost nothing but also refuse where everything is allowed. The model simply doesn't notice that something is missing: in its "picture of the world," everything adds up. That's why it needs a reason to stop and ask.
When an agent has a way to fetch the missing facts, the share of unsafe actions drops for all ten models. But having the tool doesn't mean the agent will use it: weaker models hit "execute" before they check. The practical takeaway: handing an agent a verification tool isn't enough. You have to check whether it calls that tool before the irreversible step.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1: Paired worlds → the same request, the same tools,
but in world A the action is forbidden, in world B it's allowed
STEP 2: Full data → establish the baseline: does the agent do the forbidden thing?
does it refuse the allowed one?
STEP 3: Hide facts → important facts are removed from tool responses
(everything else stays true), see where the agent breaks
STEP 4: Provide a verification tool → the agent can request what's missing
→ check: did it request, did it stop in the forbidden world,
did it execute in the allowed one
This is the blueprint of the study itself. You can reproduce it by hand on a small number of your own scenarios (see Template B below).
Example in Practice
The paper has no ready-made prompts, and the conclusion was tested via the presence of a verification tool. So the example below is built from the paper's findings. The authors did not test the instruction text itself.
Task: You're setting up Claude Code or Cursor to help clean up test environments in Google Cloud. The request is harmless: "delete the old promo-test environment." But the output of the list command doesn't show that a service depends on this VM and that there's no backup. The agent sees a truthful but incomplete answer and deletes it.
Prompt (a snippet for CLAUDE.md / the system instruction):
Before any irreversible action (deleting resources, a payment, sending
something outside, changing permissions), do three things.
1. List what you need to know for this action to be allowed: the resource's
dependencies, whether a recent backup exists, the owner, limits and approvals.
2. Mark each item as either "confirmed by tool output" or
"not visible in output." Missing information is not confirmation
that it's safe.
3. If even one item is "not visible," request it via the
check_dependencies tool or ask me. Do not perform the action until all
items are confirmed.
If, after checking, everything is confirmed and the action is allowed, proceed
without unnecessary questions. Don't refuse allowed tasks.
Result: Before deleting, the agent will print a "what I need to know" list marked "confirmed" and "not visible." For promo-test it will call the dependency check or stop and ask. If there are no dependencies and a backup exists, it deletes the environment without fuss. If there is a dependency, it refuses to delete and explains why.
Why It Works
The weakness. The model reads a tool response as the full picture. When the needed fact is missing, it doesn't look like a gap: every word is true, everything looks coherent. The model follows the pattern "the request is clear, the data is there, so let's do it." The authors see this even in models with a high task-completion rate: they do the forbidden thing simply because they never checked against the rule.
The strength. If the agent has a path to the missing fact, the model knows how to use it. Once it has the facts, it mostly makes the right call. The share of unsafe actions drops for all ten models, and nine out of ten also get better at completing allowed tasks. In other words, verification doesn't turn into "always refuse."
How to use this and what follows. Two conditions are needed. First, a verification source: a tool that returns what's missing. Second, an explicit rule in the instructions: verify before the irreversible step. Control knobs: - The list of irreversible actions → widen or narrow it for your environment. The wider the list, the more stops. - The "what I need to know" list → write a separate one for each action. That turns a vague "be careful" into a concrete checklist. - The "allowed → proceed" condition → keep it, or the agent will slide into refusing everything. The paper specifically shows that blanket refusal is a failure too. - The verification tool → if you don't have one, replace it with "ask a human."
Prompt Template
Template A: instructions for the agent (a conclusion from the paper, not a prompt from the paper)
Irreversible actions in my environment: {action_list}.
Before any of them:
1. List the facts the permission depends on: {what_to_check}.
2. Mark each one: "confirmed by tool output" or "not visible."
Missing information ≠ permission.
3. If anything is "not visible," call {verification_tool} or ask me.
Do not perform the action until everything is confirmed.
If everything is confirmed and the action is allowed, proceed immediately.
Don't refuse allowed tasks.
Fill in: {action_list} (deletion, payment, mass email, permission change), {what_to_check} (limits, dependencies, recipient list, backup existence), {verification_tool} (a command or source where the missing information can be found).
Template B: paired testing of your own agent (following the paper's logic)
I want to test an agent on incomplete data. Help me write 6 pairs
of scenarios for my environment: {environment_description}.
In each pair:
- the same request and the same set of tools;
- in scenario A the action is forbidden, in scenario B it's allowed;
- one key fact ({fact_type}) is removed from the tool responses,
everything else stays true.
For each pair, write out: what the agent sees, which fact is hidden, how it should
act in A and in B. Then give evaluation criteria: did it request what was missing,
did it stop in A, did it execute in B.
🚀 Quick start — paste into a chat:
Here's a template for testing an agent on incomplete data. Adapt it to my task: [your task and environment].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask which irreversible actions your agent has and which facts decide whether an action is allowed. Without that, it can't build "forbidden / allowed" pairs around the same request. It will take the pattern from the template and assemble scenarios for your environment.
Limitations
⚠️ Synthetic testbed: all 600 worlds were built by the researchers. Real systems are messier and often lack a "perfect source of truth."
⚠️ A perfect verification tool: for any valid request, it returns all the hidden facts at once. In real work such a tool almost never exists. The effect in production will be weaker.
⚠️ The instruction is untested: the paper tested the presence of a tool, not prompt text like Template A. We assume a "verify before acting" instruction works, but there's no data.
⚠️ Tool ≠ usage: weaker models often take the irreversible step before checking, even though the tool is available. For them, even a good instruction may not help.
⚠️ Regressions: on average verification helps, but on individual tasks the agent got worse: new unsafe actions appeared or the number of completed allowed tasks fell. One model completed fewer allowed tasks while committing fewer violations.
⚠️ Extremes: blanket refusal gives "perfect safety" and zero usefulness. Metrics in isolation are misleading; you need to look at them in pairs.
⚠️ Truncated text: the sections on behavioral details and additional analyses aren't visible in this material.
How They Tested It
The idea was simple: separate the truth of the world from what the agent sees. The team built 300 task pairs across six domains: cloud engineering, commerce, publishing, data access, finance, booking. Each pair has the same request and the same tools, but in the "forbidden" world the action breaks a rule (say, it exceeds a payment limit), and in the "allowed" world it doesn't. Blanket refusal shows up instantly in this setup: it breaks the allowed half of the pair.
Next, each task was annotated with fact "atoms": 944 critical ones (part of the rule) and 419 irrelevant ones (for example, a cost-center label). These were removed from tool responses one at a time and in combinations, without touching the rest of the truthful data. That's 6052 conditions per model. Then some runs added an independent audit tool that returns the missing facts.
What was surprising. A high task-completion rate doesn't mean safety. Qwen3-14B completes 92% of allowed tasks but commits the forbidden action in 77% of tasks with full data. GPT-6-Luna is the opposite: 3% violations, but it completes only 51% of allowed tasks. And the best score on "checked and acted correctly in both worlds" came from a model that wasn't the most cautious (DeepSeek-V4.1-Flash, 58%). GPT-6-Luna holds the "safety boundary" record (85%), but it isn't the best at recovery. Robustness to missing facts and the ability to fetch them are different skills.
The practical takeaway: evaluate an agent in "forbidden / allowed" pairs and look at the three steps separately: did it ask, did it stop, did it carry out the allowed task. A single number hides exactly where it breaks.
Adaptations and Extrapolations
🔧 Technique: add "the tool response doesn't contain fact X" to the agent's instructions as a stop signal → the agent is less likely to take silence for permission
This is an idea inspired by the paper; the authors didn't test it. Instead of a generic "be careful," describe a required set of facts for each irreversible action:
Deleting a resource: requires (1) the list of dependent services, (2) the date
of the last backup, (3) the owner. If any of these is missing from the output, stop
and request it.
Payment: requires (1) the limit that doesn't need approval, (2) whether this invoice
has already been paid, (3) the bank details being on the approved list. If anything is missing, stop.
The effect: a checklist in the instructions turns "no data" from an invisible gap into an explicit item that can be answered with "not confirmed."
Resources
- Paper: EpiSEM-Bench: Evaluating Safety and Evidence Recovery in LLM Agents under Missing Evidence
- Authors: Qijin Zhang, Hanzhen Wang, Yuehan Zhao, Haoyu Dai, Yao Shu, Zhongxiang Dai, Shuang Qiu
- Institutions: City University of Hong Kong; HKUST (Guangzhou); CUHK (Shenzhen)
- Related work cited in the paper: AgentDojo, τ-bench, ToolSandbox, AgentHarm, When2Call, AgentAbstain, AbsenceBench