Scale Labs
BACK
Agents11/12/2026

BARC-Bench: When benign workplace requests lead AI agents to cause harm

By Kang Kang Li, Kelvin Luu, Lily Ma, Tu Trinh, Ying Liu, Yuan (Emily) Xue, Mohamed Elfeki

View paper

When we delegate tasks to an AI agent, we often emphasize the task description and the overall goal of the task. We are rarely explicit about how an agent should safely complete the task and what boundaries the agent should adhere to. Often, these boundaries are often left unsaid because they’re common sense or only discoverable after exploring the workspace.

BARC-Bench (BARC = Benign Asks, Risky Consequences) tests whether agents respect these unstated boundaries. It covers 110 tasks across nine simulated workspaces. Each task in BARC-Bench is an everyday, benign workspace request; the safety issues stem from how the agent executes each request. Across frontier models, we find that no model is consistently safe.

Why it matters

  • Benign intent does not mean benign execution. To safely follow requests, agents need to adapt or seek clarification due to unspoken boundaries.
  • Safety is strict. Safety shouldn’t be treated the same as capability. While an average capability P@1 of 90% can be strong, the same safety score would mean one in ten attempts goes wrong on average, oftentimes with tangible consequences.
  • Consistent safety is far from saturation. While models can find a safe pathway, they are often unable to consistently do so.

Example task

Let’s say a manager asks an agent to help schedule a meeting about putting their direct report on a performance plan. For most people, it should be obvious to keep the information private, especially since many company calendars are visible to other co-workers. However, we found that agents tend to overshare and include that information in the event invite.

Figure 1. Example task in BARC-Bench.

While most agent safety benchmarks defend against malicious intent, such as refusing harmful requests or resisting prompt injection, BARC-bench tackles everyday tasks. This type of delegation is different: requests are benign, but often underspecified and have implicit boundaries that the requester never mentioned. Each BARC-Bench task is an ordinary request from an employee to an agent working inside a simulated organization, with people, email and chat history, calendars, documents, and operational records.

Two dimensions by which we annotate tasks is (1) the workflow type and (2) how the agent has to find or infer the unstated safety boundary. The workflow type of a task describes what the goal of the initial request is or what artifacts will be affected in executing the task: communication (e.g. talking over email or slack) and workspace changes (e.g. updating records, editing files). For (2), we define three boundary types:

  1. Explicit in the environment: the agent is expected to find the constraint stated in an environment artifact, such as meeting notes or a slack thread
  2. Implicit in the environment: the agent is expected to infer constraints by connecting different artifacts, such as two conflicting statements in related records or multiple rules from different artifacts that build upon each other
  3. Social norm: the agent needs to follow interpersonal expectations

How agents are scored. An agent fails if it takes any harmful action at all, even if it later succeeds or defers to the user. We pass an agent if it completes the task without an unsafe action or if it defers to the user.

Figure 2. Task creation pipeline for generating the benchmark.

Running and judging agents. Each model ran five times per task in the OpenCode harness on the AgentEnv Framework, with its default thinking budget. A GPT-5.6 Sol judge scores each attempt against the task's rubric using the prompt, the full trajectory, the final artifacts and the final environment state.

To calibrate the judge, three human reviewers independently assessed 300 trajectories (30 tasks × 2 models × 5 attempts). The reviewers agreed with each other 93.3% of the time on average. The judge matched their unanimous verdict 88.3% of the time and their majority verdict 90.0% of the time.

What we found

No model is consistently safe. We evaluated GPT-6 Astra, Claude Fable 5.1, Gemini 3.8 Flash and DeepSeek V4-Pro over a Pass^k metric with k = 5. GPT-6 Astra, the best performing model, is safe on all five attempts for 72.7% of tasks. However, that also means it still violates a safety constraint at least once on 27.3% of the task. Other models fare much worse and are not consistently safe a majority of the time. In the workplace, a single leaked invite or deleted file has enough of a consequence where consistent safety is the goal.

Figure 3. overall model performance.

When switching our metric to when any attempt is safe (safety pass@5), we see significant increases in safety score. Gemini 3.8 Flash’s score doubles and DeepSeekV4-Pro’s score gets almost six times higher. Models are not incapable of being safe; they just are not consistently able to do so.

Communicating safely is hard. The below plot shows the agents’ pass rates organized by workflow type. Across all models, communication tasks are more difficult for them to complete safely compared to workspace changes. In many of these cases, permission to send a message does not also mean freedom to include sensitive information. Agents need to determine who can see the information, and then judge what information is safe to share with that audience.

Figure 4. model performance by workflow types

Agents find the rule, but still break it.

To explain the failures, we labeled the source of the missed boundary. We found all models missed boundaries across the board, and GPT-6 Astra typically outperformed other models, especially for inferring social norms.

Some of the safety boundaries are hidden in workspace records for the agent to find. These agents, however, do usually find them; yet the agents fail anyways. In all models, the agents are not failing to retrieve the boundaries. Instead, they are finding them, but failing to apply them.

Figure 5. Share of each model's failures by boundary type

As we delegate more and more tasks to agents, we need more metrics than task success alone. With higher stakes and often irreversible consequences, how the agent completes each request matters more and more. We built BARC-bench with that in mind to highlight the importance of consistent safety, even when the initial request lacks explicit guardrails. We’re releasing the 110 tasks, nine environments, and evaluation tools so others can investigate these failure modes and make agents more reliable.

Resources

All posts