Parameter Drift in n8n Workflows Allows Approved Action A to Trigger Unrelated Action B in Bitrix24

An engineer writing for Habr examined a practical security gap in AI agent orchestration using n8n, Groq, MCP, and Bitrix24. The core finding was that a human could approve one specific action while the downstream execution node attempted a different action because the two nodes sourced their parameters independently.

The test involved placing a human approval step before any write operation that would change a synthetic task title in Bitrix24. In early workflow versions the approval screen displayed one set of values while the MCP client node that performed the update_task call used its own configuration. This produced the observed drift: APPROVED A ≠ ATTEMPTED B. Bitrix24 rejected the mismatched request, so the task state remained unchanged, yet the architectural defect was confirmed.

Evidence collected during testing

The researcher recorded concrete observations across multiple runs. In one execution the human approved a title change labeled Action A, yet the downstream node attempted Action B. Bitrix24 returned a rejection and no state change occurred. The experiment deliberately varied approval configuration, execution path, fresh-state comparison, and data extraction logic to isolate the drift condition from other failure modes.

Importantly, the AI agent itself operated under read-only Bitrix24 tools. It could propose changes but could not execute writes. Authority for the actual update resided in a separate deterministic MCP client node that ran only after the approval gate. The drift therefore originated in the orchestration wiring rather than in any autonomous decision by the language model.

Action Envelope and verification steps

The corrected design introduced a single Action Envelope object containing target_system, task_id, operation, expected_title, and requested_title. Both the approval message and the subsequent update_task call derived their values from this shared object, eliminating independent parameter sources.

Immediately before the write, the workflow performed a fresh get_task_by_id call and compared the current title against the expected baseline stored in the envelope. Only a match allowed execution to continue. After the update, another read verified that the requested title now existed in Bitrix24. Acknowledgement from the API and the verified post-write state were stored as separate evidence objects.

The series of controlled runs confirmed that the bound path succeeded end-to-end while the stale-state and extractor-error conditions were handled safely. The researcher concluded that boolean approval flags alone cannot guarantee that the parameters shown to a human are the same parameters later sent to the target system.