The agent stopped every attack. It also stopped the customer.

Imagine a customer-support agent that never issues a bad refund, never leaks protected information, and never follows a malicious instruction.

There is an easy way to build one: do not let it do anything.

That system may look excellent on a security dashboard. Its attack-success count is zero. No risky action reaches production. It is also useless to every legitimate customer who needed the work completed.

BoundaryLab’s first architecture benchmark made that tradeoff visible. One of its three controlled profiles blocked every proposed action before it reached the capability gateway. Across eight synthetic support scenarios, it stopped every attack. It also produced four false refusals and completed only four tasks.

The result was not a surprise hidden in a log. False refusal was a first-class evaluation metric, next to attack resistance and policy compliance. That changed the meaning of “safe.”

Prevention is only half the product

Security controls are often described by what they stop: prompt injection, data leakage, excessive actions, unauthorized tools. Those are real risks. But an agent exists to perform useful work inside a boundary. If the boundary makes legitimate completion impossible, the product has traded one failure mode for another.

In a support workflow, that cost is concrete. A valid refund that never happens is not merely a conservative model response. It is an unresolved customer problem, another support contact, extra operational work, and possibly lost trust.

The benchmark compared the same eight authored scenarios across three deterministic profiles:

The vulnerable long-context profile completed four of eight tasks and recorded two successful attacks. The overcautious profile reduced attack success to zero, but still completed only four tasks because it falsely refused the other four. The bounded hybrid profile completed all eight while recording zero successful attacks and zero false refusals.

Those numbers do not prove that one prompt or agent architecture will behave that way in production. They establish something narrower and more useful at this stage: the benchmark can distinguish unsafe completion, safe refusal, false refusal, and safe completion instead of collapsing them into “blocked” and “allowed.”

A reviewer should advise, not own authority

The architecture separates four responsibilities. A worker proposes an action. A sentinel can recommend passing, blocking, retrying, or requesting human review. A capability gateway decides whether the proposal is actually authorized. A protected judge evaluates the final state after the run.

That separation matters because a stricter reviewer is not automatically a better authority. In the overcautious profile, the sentinel blocked a policy-valid refund even though the worker had used all required evidence. The gateway never got the opportunity to apply its narrower rules about identity, resource scope, refund limits, and approval requirements.

The system remained protected, but it lost useful work before the component with actual authority could evaluate it.

This is a product distinction as much as a technical one. A compliance team may prefer a system that fails closed. A customer still needs to know what happens next. A human-review path may be appropriate for ambiguous or high-impact work, but sending every valid request to a person merely disguises the absence of useful automation.

The question is not whether the agent refused. It is whether refusal was the correct outcome for that case.

The benchmark had to protect its own conclusion

All 24 runs were deterministic and used authored fake adapters, synthetic data, and zero model calls. The same eight scenarios were executed against all three profiles. Protected expected outcomes remained outside the worker and sentinel context, and the public report excluded raw prompts, attacker objectives, canary values, and protected ground truth.

That makes the comparison reproducible, but it also defines its limit. This is evidence about system contracts and controlled failure modes, not a prediction of how often a real model will attack, refuse, or succeed. A future model-backed experiment would need its own approved budget, recorded model identity, and equivalent evaluation boundary.

The deterministic version earns its place because it catches a problem before model variability enters the picture: if the evaluation rewards only blocking, an apparently strong safety result can hide a broken product.

The overcautious profile did exactly what it was configured to do. That is what made the failure valuable. It showed that “more refusal” is not a direction. Safety is the ability to complete the right work while keeping the wrong work outside the boundary.