n8n Queue Mode and Workers: Where to Enforce Policy on AI Agent Tool Calls Behind the Firewall

How queue mode distributes execution

A single-process n8n deployment runs triggers and executions in one place. Queue mode separates those responsibilities. The main instance coordinates work, a Redis-backed queue holds pending executions, and worker processes pull jobs from that queue. Webhook processors can be added so inbound webhook traffic is handled apart from the main instance.

For policy design, the important consequence is where the agent actually runs. An AI agent node and its tool calls, such as HTTP requests, database queries, and MCP or API actions, execute in the worker that picked up the job. You do not choose that worker, and it can differ from one execution to the next. Each call therefore runs with the credentials and network reach available to that particular worker.

If workers are scaled horizontally, any control that lives in one place, or that depends on which worker ran the job, is a control you have to verify on every replica. A policy that holds on worker one and quietly differs on worker four is the failure mode to design against.

Four candidate enforcement points compared

Each layer sees a different slice of an agent tool call and can take a different action on it. The comparison below covers what each can see, what it can decide, and where it tends to fail in a multi-worker deployment behind a firewall.

• In-workflow checks: Sees: what the workflow author anticipated at design time. Decides: branching, validation, and approval steps that the author builds in. Fails when an agent selects a tool or parameters the designer did not plan for, or when checks are copied inconsistently across workflows. Evidence is only as good as each workflow's own design.
• Worker-level controls: Sees: the process, its configuration, and its environment. Decides: which credentials and settings a worker holds. Fails on coverage if workers are configured differently. Credentials available to a worker are available to every job it runs, so a broad credential set means broad exposure. Offers little visibility into individual tool-call parameters.
• Network egress and firewall rules: Sees: destinations, ports, and protocols. Decides: whether a connection is permitted. Holds on every worker if applied at the boundary. Fails to distinguish between actions on the same permitted host, cannot redact parameters, and does not know which agent or policy was involved.
• Execution-path enforcement between agents and tools: Sees: each tool call, its target, and its parameters. Decides: allow, redact, block, rate limit, or escalate for human approval, then records the decision. Holds on every worker if all tool traffic is routed through it. Fails if some tool paths bypass it, and it adds a hop whose latency should be measured in your own environment.

Why network and workflow layers are not enough alone

Network-level policy is a necessary backstop in a firewalled deployment, but NIST guidance on zero trust for cloud-native applications notes that network-level policies alone demand high maintenance, because location parameters keep changing as containers and virtualized workloads move. The same guidance describes identity-tier policy as more agile, since it can be written in terms of identity and application-level action. A tool call is exactly that kind of action, and an egress rule cannot express it.

Workflow-level checks have the opposite limitation. They express intent well, but they sit inside the thing being controlled. They describe what a workflow was designed to do, not what an agent actually calls at runtime, and they produce evidence that varies workflow by workflow.

The practical reading is layering. Egress rules limit reachable destinations. Workflow checks capture designed intent. A separate decision point in the call path applies policy to the actual call.

Placing enforcement so it holds on every worker

The placement that satisfies the coverage requirement is one where tool traffic from any worker passes through the same enforcement point before reaching a tool. Policy is then defined once and applied identically, regardless of which worker, or how many workers, exist at a given moment.

Three design decisions follow. First, route every tool path, including HTTP, database, and MCP or API actions, through the enforcement point, and use egress rules to deny direct paths around it. Second, narrow what workers hold. If the enforcement point mediates access, workers need not carry broad standing credentials for every tool. Third, define the decisions explicitly: allow, redact parameters, block, rate limit, and escalate to a human approver for consequential actions.

Apply the same requirement to any process that can execute a tool call, not only the workers you expect to. Enforcement that runs in the path is enforced at runtime, not reviewed after the fact. Detection-only tooling can tell you that a call happened, but it cannot stop it.

Distribution also affects evidence. NIST monitoring guidance observes that in distributed infrastructure, where components are logically separated, capturing and aggregating logs effectively can be difficult. Per-worker log files are a weak basis for audit. An enforcement point that records each decision centrally avoids reconstructing it from many workers.

Evaluating an enforcement point

Use a short set of questions when comparing options. Does enforcement apply identically on every worker and webhook processor, whichever process picks up the job? Is it in the tool-call execution path, so it can block, redact, rate limit, or escalate, or does it only detect afterward? What does each decision record contain, and how is it aggregated across workers? Can it be deployed inside your own cloud or firewall boundary? How does it sit alongside egress rules, and what latency does it add, based on measurements in your environment?

Trussed is one example of this category. It enforces policy in the execution path across agents, tools, and MCP servers, covering individual interactions and tool calls with allow, redact, block, rate limit, and human-approval escalation. It is deployed self-managed in the customer cloud, with configurable retention and data residency, and it produces audit-ready evidence from enforcement itself. It does not provide end-to-end tracing of agentic workflows, so keep workflow-level observability as a separate concern.

A practical next step is to inventory every tool your n8n agents can reach, note which credentials each worker holds, and mark which paths would bypass a central enforcement point. That map shows where egress rules and workflow checks must carry the load until enforcement is in the path.