Routine changes can let AI agents bypass active safety checks

An active safety plugin does not necessarily mean an AI agent’s actions pass through it. In controlled experiments, researchers found that ordinary operations could let prohibited edits execute while policy and approval plugins remained enabled.

Boming Xia, Qinghua Lu, Dino Sejdinovic and Liming Zhu report the findings in an arXiv preprint submitted on November 6, 2026. The work examines selected software assemblies, not the overall safety of AI agents or how frequently such failures occur in deployed systems.

Testing relationships, not component health

An agent harness coordinates model responses, tool execution, permissions and stored state. Safety responsibilities can be spread across the harness itself, independently developed plugins and configuration. Whether those parts cooperate correctly depends on more than whether each is running.

The researchers studied five relationships associated with three architectural patterns: guardrail enforcement, operator control and shared information. Their main source-analysis sample comprised fourteen independently written plugins for DeepSeek Harness and OpenCode, with comparisons across five released harnesses overall.

Their assessment procedure, PatternOps, connects each requirement to the components responsible for it and the runtime order or retained state that supports it. Controlled comparisons varied operations or responsibility assignments. Programmed model responses fixed action sequences; selected comparisons also used live models. The researchers joined tool calls, policy decisions, operator responses and effects rather than treating successful task completion as evidence of policy coverage.

A mode switch moved policy out of the path

In DeepSeek Harness, the Governance policy plugin and Tool Approval plugin used a callback chain. Callbacks normally ran in registration order, but a callback could answer without passing the request onward.

The researchers first arranged for policy to run before approval and confirmed that an initial edit reached policy in observe mode. Switching Governance to enforce mode recreated its instance and registered its callback behind Tool Approval. Approval then ended the chain before policy could evaluate edits.

On the tested rc.2 release, policy evaluated none of the five selected edits after this switch. When the programmed operator approved the edit prohibited by the study policy, it executed. Policy remained active on a separately tested read path, and the plugin manager raised no warning about the lost edit coverage.

Disabling and re-enabling Tool Approval moved it behind policy, restoring evaluation of all five selected edits. The next mode switch removed that coverage again. The same plugins and final settings therefore produced different behavior depending on operational history.

Saved permission changed eligibility

A different mechanism appeared in OpenCode 2.2.5. Permission Reviewer evaluated requests still requiring operator approval. After an “always” response saved an edit allow rule, the next prohibited edit was already permitted at the native permission stage. The reviewer abstained, and the edit executed without the designated policy decision.

This did not contradict the reviewer’s documented promise to review requests needing approval. It showed that the promise was weaker than the study deployment’s requirement for policy participation. Revoking saved consent restored evaluation.

The distinction matters when choosing repairs. Preventing prohibited effects is not equivalent to evaluating every admitted edit, including those another component rejects. A study wrapper placed after DeepSeek Harness’s callback chain prevented prohibited effects but missed two edits rejected earlier. Some OpenCode alternatives reached more requests yet differed in whether policy escalations produced another question, became denials or proceeded without renewed consent.

Information can disappear even when checks run

Policy also needs the right information. Airlock, a provenance-tracking plugin, stored source trust labels inside its running instance. Reapplication discarded those labels even when the untrusted source remained in the model’s input.

Conversation compaction exposed another dependency: on tested releases, changed history-field names prevented Airlock from recognizing an untrusted source retained verbatim after the summary. A decoder repair fixed that problem but still lost labels at the next reapplication. Study alternatives that persisted labels outside the instance or rebuilt them from history preserved restrictions and allowed clean work through the tested sequences.

Supporting cases found related problems elsewhere. In Deep Agents, direct routes to tool execution could bypass the router enforcing batched review, whereas per-call review held on all tested routes. A study-built grouped workflow also repeated completed work after resumption. An OpenCode shared-board case exposed inconsistent exclusion of shut-down members under the study’s explicit re-enrolment requirement.

Bounded evidence, practical implications

These are purposively selected cases on pinned releases, including developer previews, not prevalence estimates. Operator responses were programmed throughout; live-model comparisons covered selected findings. Some requirements were study choices, and some analyses were corrected after collection using unchanged records. The report is a preprint, not an established universal finding.

The practical lesson is to test the paths and operation sequences a deployment actually uses. Plugin health, successful tasks and blocked effects alone cannot establish that the required policy evaluated each covered action.