A 5-step ritual to stop unreviewed workflow shipping

You are the ops lead deciding who can publish automations. Before August 4, an n8n user holding publish access could send a workflow live with a single click. A bigger permission matrix will not fix it. A small ritual that makes the permission matrix visible inside a normal work cycle does: propose the workflow, review it, scope it, record it, and only then let it run.

The gate is the publish button

Version 2.34.0 of n8n added a review cycle that keeps a workflow out of production while that review remains open. That is the gate you want on every automation. The n8n release dated 2026-09-01 makes the custom instance role editor warn about a role that carries only the Manage project roles permission, since a holder with it can change scopes on any project-type custom role. Keep that warning in the ticket. If a role can edit scopes, it can quietly widen the blast radius. If the warning appears, treat the role as a change request.

Scope the agent, not the team

A broad scope set turns a bad automation into a company-wide incident. A patch note turns a runner fix into something the next on-call person can verify. The test is simple: if an agent can read, write, or call something it does not need for its task, the scope is too wide. Version 2.34.0 of n8n added agent-level MCP scope management, letting an instance give different agents different MCP scopes instead of one shared set. Over August 5–7, n8n released four point updates to correct a health-check defect that made queue-mode deployments with external task runners report false negatives; the corrections were identified in 2.34.4 and 2.33.7. Start with a narrower default and expand only when a task needs it.

The checklist is the ritual

Each step below is testable in a minute, and each should appear in the workflow ticket before publish. The list is a minimum set of checks, not a policy document. If a check cannot be completed in a minute, it is probably the wrong check.

• Open a review before publish and confirm the gate is active.
• Name a reviewer who approves or requests changes, and check that the review record shows a decision.
• Approve the review and verify publication happens automatically, without a separate manual deploy step.
• Assign per-agent MCP scopes and confirm each agent has only the scopes it needs.
• Add a patch note for scaled task-runner setups.

The publish items keep the path honest. The scope item keeps the agent from inheriting more access than the task requires. Keep the patch note in the same ticket as the review.

The review loop needs a stop rule

The AWS sample Claude Code agent-team workflow stops after a third failed review cycle, blocking the affected scope for human decision rather than starting another build-review round. In the AWS sample, each review cycle yields a single review.md and a single pass-or-fail verdict from the review-agent pool. In that sample, a review-agent verdict rejects the work when a required test tier is missing or when an assertion checks a mock rather than the real system. The AWS sample gates every workflow step with four test tiers: T1 unit tests, T2 integration or contract tests, T3 deployed-resource verification, and T4 end-to-end journeys.

The number of tiers is less important than the stop rule. A missing tier is a hard stop, not a note for later. The same logic applies to a mock. If the test proves the fake, it has not proven the workflow. Human in the loop automation works when the loop has a terminal state.

Armosec's CISO checklist frames AI-agent production approval as seven gates, each tied to a concrete evidence standard. Armosec's checklist wants the runtime inventory entry for an AI agent to show the attached MCP tool runtimes, the named security reviewer, and the date the entry was added. That gives the ops lead a way to answer who can touch what, and when. The entry should be boring. It should answer the questions a new ops lead asks during an incident.