Trust at the Edges: Credentials, Data, and Network Boundaries

For n8n, the security question is not whether a workflow has a single “safe” switch. It is whether each transition in the workflow control plane preserves the intended boundary: who may invoke a node, which project may call a subworkflow, what an expression can reach, where an outbound request may connect, and what data can be returned to a person or a model. This chapter separates those surfaces so the reader can judge n8n’s implemented controls, their defaults, and the responsibilities that remain with an operator.

Authority is decided before the model acts

Consider an AI Agent that receives a customer request and decides to update a record. The model may choose an identifier or another value declared by the tool schema, but it is not the authority that grants the update. The workflow still determines which node represents the operation, which credentials that node references, which user or project is allowed to use those credentials, and whether the run can cross into a subworkflow. The model’s choice is a parameter inside a larger chain of authority.

n8n makes one part of that chain explicit before execution. Its credential permission checker examines the credentials referenced by the workflow’s actively used node configurations. It checks project access for a stored workflow and can check a specific triggering user for inline or otherwise non-stored subworkflows. Missing credential IDs and an unresolvable triggering user fail closed. A credential slot that is present but not active for the node’s current configuration can be skipped, which avoids treating an unused alternative as an authority the run actually needs.

This preflight matters more for agents than for a fixed sequence because the model chooses among possible effects at runtime. If a tool wraps an HTTP Request node, the model can provide values that the workflow has exposed, but the node’s credential remains a separate object. If the current user cannot use that credential, the run should stop before a model-selected argument reaches the external service. The source also carries encrypted runner identity and execution context into workers and sub-executions, so moving the run to another process does not automatically discard the identity under which credential resolution was established.

Dynamic credentials make the distinction sharper. A run may attempt to resolve a private or user-specific credential while executing a node or a subworkflow. n8n records whether such credentials were used or attempted and forwards that usage through nested execution paths. That metadata is useful for redaction and telemetry, but it also reveals a design requirement: authority is not fully determined when the workflow is saved. Some authority is resolved at run time, under the identity and input that initiated the run.

Credential permission is not the same as permission to compose graphs. A workflow can have access to a credential and still be forbidden from calling a particular subworkflow.