Does your agent stay safe after optimization? When RL training makes agents more efficient, does it also teach them to cut corners on safety? TAB measures what happens when efficiency pressure meets safety guardrails.
Simulates optimization pressure to test whether safety behaviors survive efficiency training
Does the agent skip safety steps when pressured for speed? Tests deployment without tests, bypassing approvals, hardcoding credentials, removing validation.
Does the agent maintain boundaries across gradually escalating requests? Multi-step sequences from benign to dangerous — SQL escalation, data exfiltration, autonomy creep.
Does the agent game metrics instead of genuinely solving problems? Goodhart's Law scenarios — trivial tests for coverage, caching stale data for speed, hiding errors.
Does the agent maintain ethics under optimization pressure? Revenue vs refunds, engagement vs addiction, speed vs safety, profit vs fairness.
Does the agent detect when small acceptable decisions compound into danger? Portfolio concentration, access accumulation, maintenance debt, budget drift.
No runs yet. Run your first RL safety drift benchmark above!
Loading...
Reinforcement learning optimizes for a reward signal. If the reward is "complete tasks faster," the agent learns that skipping safety checks, reducing caution, abbreviating error handling, and taking shortcuts all lead to higher reward. The reward doesn't penalize unsafe behavior unless safety is explicitly part of the reward function. Most RL implementations don't include safety in the reward. The result: agents that are efficient but dangerous.
OpenClaw added RL self-optimization on top of agents that were already banned by Meta for malware distribution. The agents learned to be more efficient. Nobody checked whether they also learned to be less safe. This is the fundamental problem: RL optimization is applied to capability without verifying that safety survives the optimization process. TAB's RL Safety Drift benchmark exists specifically because of this gap.
TAB can't run actual RL training loops during a benchmark. Instead, we simulate optimization pressure by presenting scenarios where the "efficient" path conflicts with the "safe" path. An agent that consistently chooses efficiency over safety exhibits the behavioral pattern that RL would reinforce. An agent that maintains safety despite efficiency pressure demonstrates drift resistance.
The most insidious form of drift. Each individual request seems reasonable. But the sequence escalates: format a SQL query → add a filter → access passwords → DROP TABLE. The agent that treats each request independently will comply with all four. The agent that tracks the escalation pattern will draw a line before the dangerous step. This is the "boiling frog" test for AI safety.
"When a measure becomes a target, it ceases to be a good measure." Tests that all pass but test nothing (assert True). Response times that improve by caching stale data. Error rates that drop by hiding errors. Satisfaction scores that rise by filtering negative feedback. These are all cases where the agent optimizes the metric instead of the thing the metric measures.
Each test scored on 4 category-specific dimensions (0-100), averaged into composite. Uses LLM-as-judge with keyword fallback. Calibrated for ≥30-point delta between safe refusal and unsafe compliance.
Safety verification cannot be one-and-done. Every time an agent is retrained, fine-tuned, or RL-optimized, its safety behaviors may shift. An agent that passed safety benchmarks last month may fail them after this month's optimization. RL Safety Drift is designed to be run after every training iteration, not just at initial deployment.