n8n in Production: A PSF Domain Assessment

Form trigger and webhook nodes accept any input. No semantic validation, content classification, or injection detection is built in.

n8n's trigger nodes — webhooks, form submissions, scheduled polls — accept payloads without semantic scrutiny. An adversarial prompt in a webhook body flows directly to the AI Agent node, which passes it to the LLM. For workflows that accept free-text user input (support ticketing, document processing, chatbot backends), this is a meaningful PSF Domain 1 gap. The platform provides no built-in mechanism to classify incoming content, detect prompt injection attempts, or enforce a permitted-use policy before the AI node fires. Practitioners building customer-facing n8n workflows must implement input governance explicitly — either as a pre-processing Code node that calls a classification endpoint, or by routing inputs through an AI node whose sole purpose is semantic screening before the primary workflow proceeds. Without this, the workflow processes whatever arrives in the trigger payload.

AI Agent node returns raw LLM output as a string. Structured output requires an explicit JSON parse node; no semantic validation is native.

n8n's AI Agent node delivers the LLM's response as a text string in the workflow data object. For workflows that must produce machine-readable outputs — JSON for a downstream API, a specific field for a CRM update — practitioners insert a separate Parse JSON node and handle parse failures via error branches. This is functional but fragile: it relies on the LLM consistently producing the expected format, which it does not always do. n8n's native retry behaviour for AI nodes is limited. More critically, semantic output validation — checking whether the LLM's answer is factually appropriate, appropriately scoped, and free of harmful content — is entirely absent. PSF Domain 2 requires output contracts. In n8n, that means a validation sub-workflow or a second AI node that evaluates the primary response before it reaches downstream steps.

No PII detection, data classification, or scrubbing. Workflow data containing sensitive fields is passed to LLMs and logged in execution history by default.

n8n's execution log stores the full input and output data for every node by default. In a self-hosted deployment, this data sits in the n8n database. In n8n Cloud, it is held in Europ-hosted infrastructure. Either way, any sensitive data that flows through the workflow — customer PII, medical records, financial transactions — is written to execution history, potentially indefinitely. For GDPR, HIPAA, or PCI DSS compliance, this creates an audit risk that most n8n deployments have not addressed. The platform has no native PII detection or data masking. Practitioners must either configure data retention policies carefully, use n8n's execution data pruning settings, or implement PII scrubbing in Code nodes before data enters execution logging. The deeper issue is that sensitive data submitted to n8n AI workflows passes directly to third-party LLM APIs unless the deployment uses a locally-hosted model node.

Execution log provides node-level trace and data visibility. No native alerting, LLM-specific metrics, or anomaly detection.

n8n's execution history is its primary observability mechanism. Every execution shows which nodes ran, what data each node received and emitted, whether the execution succeeded or failed, and the total run time. For simple workflows this is sufficient for debugging. The gaps emerge at scale: n8n provides no native dashboarding for workflow success rates over time, no alerting when error rates exceed a threshold, and no LLM-specific metrics like token consumption, model latency, or hallucination indicators. For production AI workflows handling significant volume, practitioners need to export execution data to an observability platform — Datadog, Grafana, or similar — to get the visibility PSF Domain 4 requires. n8n Cloud's newer versions expose some workflow metrics but not the depth needed for enterprise AI governance.

Workflow versioning exists. No canary rollout, traffic splitting, or automated rollback. Manual activation controls only.

n8n supports workflow versioning — you can view previous versions of a workflow and restore them — but it does not provide the deployment safety primitives that PSF Domain 5 describes. There is no mechanism to activate a new workflow version for a percentage of traffic while keeping the prior version live for the remainder. There is no automated rollback trigger when error rates spike. Workflow activation is a binary on/off toggle. For AI workflows in production, this means deploying a changed workflow is a hard cut-over: all subsequent executions use the new version immediately. For low-stakes, low-volume workflows this is acceptable. For workflows processing hundreds of transactions per hour or handling sensitive decisions, PSF Domain 5 requires a safer deployment pattern.

Wait node and Form trigger enable human-in-the-loop pause points. No native approval workflow or structured override interface.

n8n's Wait node is its primary human oversight primitive: a workflow can pause execution and resume when a webhook is called, enabling a human to review and approve before the workflow proceeds. Combined with a Form trigger for the reviewer interface, this is a workable human-in-the-loop mechanism. The limitations are in structure and auditability. n8n does not provide a native case management interface for reviewers — decisions are captured via webhook calls rather than a purpose-built approval UI. The audit trail of who approved what, when, with what justification, must be built by the practitioner. For PSF Domain 6 in a regulated environment, a wait-webhook pattern will satisfy the technical requirement for human gates but may not satisfy documentation requirements for approval audit trails without additional logging.

Credential management with encryption at rest. No native secret rotation, least-privilege enforcement on credentials, or supply chain scanning.

n8n's credential system encrypts stored credentials at rest using AES-256 and allows credentials to be shared selectively between workflows and users. This is adequate for baseline credential security. The gaps: n8n does not enforce least-privilege access to credentials — any workflow with access to a credential can use it without scope restrictions. There is no native secret rotation mechanism; stale credentials accumulate. In self-hosted deployments, the encryption key is typically a single environment variable; key rotation is manual and poorly documented. For PSF Domain 7, the most significant concern in AI deployments is that n8n workflows often hold LLM API keys, database credentials, and third-party service tokens in the same credential store — a credential leak exposes the entire stack. Supply chain risk from community nodes (n8n's third-party node ecosystem) is also unaddressed.

Self-hosted deployment option provides infrastructure independence. Cloud offering creates dependency. LLM provider coupling via configured credentials.

n8n's self-hosted option is a genuine vendor resilience asset: an organisation running n8n on its own infrastructure does not depend on n8n's SLA for the orchestration layer. Export workflows as JSON for backup and portability. The vendor resilience risk is in the LLM layer: n8n AI workflows are typically configured against a specific provider (OpenAI, Anthropic, etc.) by credential name. Switching providers requires reconfiguring AI nodes individually across potentially hundreds of workflows. There is no provider abstraction layer or failover configuration native to n8n. For PSF Domain 8, practitioners should abstract the LLM call behind a Code node that accepts a provider configuration variable, making provider switching a config change rather than a workflow edit.