n8n-io/n8n

A clear instance of declarative, tested transformations exists in the workflow template import path: `templateTransforms.ts` provides centralized transformation functions for credential overriding and resourceLocator scrubbing, and `templateTransforms.test.ts` contains unit tests (including boundary/empty and non-mutation checks). The import orchestration (`templateActions.ts`) correctly delegates to this transformation layer.

• high

  Extend this transformation-layer pattern to any other template-related data reshaping currently done inline (if present). As a check, ensure any future transformation helpers have adjacent unit tests and are invoked by the import orchestration rather than reimplemented at call sites.

  • packages/frontend/editor-ui/src/features/workflows/templates/utils/templateActions.ts:33-74 — Shows the preferred orchestration style: call into the transformation layer from the template import path.
• med

  If additional transformation responsibilities emerge (e.g., further template normalization beyond credentials and resourceLocator), consider expanding the existing `templateTransforms.ts` module rather than creating one-off helpers next to orchestration logic, to keep transforms declarative and testable as a single governed layer.

  • packages/frontend/editor-ui/src/features/workflows/templates/utils/templateTransforms.ts:1-173 — Currently centralizes multiple related transformations (credential normalization/replacement and resourceLocator clearing) in one tested module.

No codebase-wide “Orchestrated pipelines” primitive was found in the sense of a governed DAG/asset definition with explicit declared dependencies, retry behavior, and reproducible, observable pipeline runs. What was found related to “orchestration” is worker-status polling in the frontend, which does not constitute a pipeline orchestration layer with a dependency graph and execution governance.

• high

  Identify where data/AI pipelines are executed (backend worker/services layer) and ensure they are defined declaratively as a DAG (assets/manifests) with explicit dependencies and retry/success/failure handling surfaced as structured run records (reproducible inputs + run metadata).

  • packages/frontend/editor-ui/src/features/settings/orchestration.ee/orchestration.store.ts:1-82 — Current “orchestration” visibility is limited to worker status polling; the primitive audit criteria (DAG dependencies, retries, reproducible runs) are not present here.

The repo externalizes data/contract validation using Zod-based schemas at tool boundaries (notably in the agents integration tool layer) and also provides a reusable schema-resolution/validation helper in the workflow SDK. This indicates a real data-quality/contract primitive, though only a small number of ingestion-boundary sites were confirmed in this audit slice.

• high

  Extend this audit to all ingestion boundaries (HTTP handlers/DTO parsing, workflow input ingestion, node parameter parsing, webhook payloads). For each, require an explicit schema gate (Zod/JSON-schema-to-Zod) with a quarantine/error path instead of only downstream type assumptions.

  • packages/cli/src/modules/agents/integrations/integration-tools.ts:805-920 — Shows the expected pattern (Tool `.input(...)` schema gate) at one ingestion boundary; replicate/verify across other ingestion surfaces.
• med

  Add/verify standardized error routing for schema-validation failures (e.g., consistent error codes, capture invalid payloads, and ensure invalid inputs never propagate into execution).

  • packages/@n8n/workflow-sdk/src/validation/resolve-schema.ts:1-227 — The helper produces descriptive validation messages but this audit did not confirm the end-to-end quarantine/routing behavior for invalid datasets at every boundary.

An explicit raw landing-layer concept exists (`InsightsRaw`), and compaction stages read from it. However, the compaction process deletes the processed raw rows from the source table, so the raw layer is not immutable and is not safely recoverable for auditing/reprocessing after transforms.

• high

  Make `insights_raw` append-only/immutable by removing the destructive delete. Replace `DELETE FROM ${sourceTableName} ...` with an approach that preserves raw rows (e.g., mark-processed without deletion, move to an archive table, or store immutable raw snapshots keyed by run/batch).

  • packages/cli/src/modules/insights/database/repositories/insights-by-period.repository.ts:220-290 — Compaction currently deletes processed rows from the source table, which violates the 'raw / immutable source layer' requirement.
• med

  Add explicit auditability guarantees: store lineage metadata for each compaction run (source batch identifiers, time window, and counts) so auditors can reproduce aggregates from immutable raw data.

  • packages/cli/src/modules/insights/insights-compaction.service.ts:1-220 — Compaction is staged and batch-oriented, but there is no evidence (in the inspected code) of lineage metadata that preserves the exact immutable raw inputs used per aggregate output.

No clear implementation of “Data + pipeline versioning” (data state captured in immutable, versioned snapshots and linked to specific pipeline logic releases) was found. The codebase has evaluation dataset syncing and mock/pin-data generation, but dataset state is updated (and new examples get random UUIDs) rather than being snapshot-versioned and tied to a specific pipeline release for guaranteed reproducibility.

• high

  Add explicit, release-tied dataset snapshotting for evaluation inputs (e.g., store generated/synced scenario inputs + splits as immutable artifacts/versions, then reference the snapshot id in evaluation runs). Ensure the snapshot is created deterministically from repo content + pipeline version/commit, not only by diffing current filesystem state.

  • packages/@n8n/instance-ai/evaluations/langsmith/dataset-sync.ts:55-210 — Current sync logic updates/creates examples based on derived inputs and uses randomUUID for new examples; there is no release-specific snapshot id or immutable dataset artifact coupling.
• med

  Record and persist pin-data generation provenance/versioning (generator code version/commit + schema resolution strategy + input workflow hash) and store the resulting pin data as versioned artifacts (or ensure the evaluation can fetch a prior immutable pin-data version).

  • packages/@n8n/ai-workflow-builder.ee/evaluations/support/pin-data-generator.ts:1-489 — Pin data generator resolves schemas using typeVersion and constructs prompts, but there is no evident mechanism for immutable, release-specific storage/versioning of the generated data outputs.
• low

  If using an external system (e.g., LangSmith) as the data store, introduce a governed “dataset/model/pipeline version” field in example metadata and enforce that evaluation runs pin to a specific dataset snapshot/version rather than relying on “current sync”.

  • packages/@n8n/instance-ai/evaluations/langsmith/dataset-sync.ts:1-55 — Metadata and sync behavior are present, but there is no shown linkage to a pipeline release/version that would make re-runs reproducible against a specific data state.

No explicit data lineage / provenance primitive (e.g., OpenLineage/Marquez/DataHub/Amundsen, or equivalent lineage/provenance emission + governance artifacts) was found in this codebase via repository-wide searches. No schema/config/artifact for provenance emission and no lineage/provenance implementation points were located.

• high

  Add an explicit, machine-queryable lineage/provenance emission layer in the pipeline/execution path (record dataset identifiers, source dataset(s), and transformation/derivation edges with timestamps + run identifiers). Ensure it is persisted and queryable (DB tables/events) and covered by automated tests that validate lineage correctness end-to-end.

• med

  Adopt or integrate a standard lineage model (e.g., OpenLineage) or define an equivalent internal schema and publish a machine-readable contract (schema) for lineage events.

I did not find any feature-management primitive (e.g., a centralized, versioned feature definition/feature store used as a single source of truth by both training and serving). The codebase appears to define feature-like schemas inline in application code rather than externalizing them into a governed feature layer suitable for avoiding training/serving skew.

• high

  Introduce a centralized feature-definition artifact (feature store + versioned contracts/feature manifests) and route both training and serving to read from the same generated/compiled feature definitions.

  • packages/frontend/editor-ui/src/features/agents/agent.types.ts:1-39 — Current schemas are defined inline via TypeScript interfaces, indicating an implicit (code-local) source of truth rather than an externalized feature layer.

This codebase clearly implements a vector/embedding-store primitive via n8n LangChain vector store nodes (including external providers like PGVector) and a shared createVectorStoreNode dispatcher. However, the audited implementation shown for the in-memory store is explicitly ephemeral (lost on restart) and the memory manager metadata does not demonstrate any governance tying vectors to the embeddings model version and embedded content version.

• high

  Add explicit vector versioning governance: store metadata/namespace keyed by (1) embeddings model identifier/version and (2) a hash/version of the embedded content (e.g., per-document content hash or dataset manifest). Ensure both are written alongside vectors and used to route queries to the correct index.

  • packages/@n8n/ai-utilities/src/utils/vector-store/MemoryManager/MemoryVectorStoreManager.ts:120-200 — Metadata tracks size/createdAt/lastAccessed but not embeddings model version or content version.
  • packages/@n8n/ai-utilities/src/utils/vector-store/MemoryManager/MemoryVectorStoreManager.ts:200-320 — addDocuments persists vectors into the in-memory store without recording model/content version linkage.
• high

  Enforce model/content version linkage at the insertion call path: have createVectorStoreNode/insertOperation derive a content version (or accept one from upstream) and pass it into populateVectorStore so providers can persist vectors into a versioned namespace/index.

  • packages/@n8n/ai-utilities/src/utils/vector-store/createVectorStoreNode/operations/insertOperation.ts:1-82 — Insertion delegates persistence to args.populateVectorStore, but no versioning contract is enforced in this flow.
• med

  For each external vector store provider (e.g., PGVector), implement and validate a consistent schema for storing: embeddings_model_id, embeddings_model_version, content_version/hash, and a retrieval filter to prevent mixing indexes from different versions.

  • packages/@n8n/nodes-langchain/nodes/vector_store/VectorStorePGVector/VectorStorePGVector.node.ts:1-260 — A persistent vector-store provider exists; the remaining requirement is to ensure it persists version linkage and uses it during retrieval.

Model version pinning exists and is implemented well in `packages/@n8n/ai-workflow-builder.ee/src/llm-config.ts`, where model factories construct LangChain chat models using explicit versioned model IDs for OpenAI and Anthropic. Additionally, integration-test fixtures include explicit versioned model identifiers to keep test behavior deterministic. However, general runtime node templates (e.g., the OpenAI-compatible example node and the LMChatOpenAi node) appear to accept model IDs from node parameters without enforcing version pinning.

• high

  Add governance to user-facing model selection nodes (e.g., OpenAI-compatible example node and LMChatOpenAi): validate that `model` is a pinned, versioned ID (or provide a controlled dropdown sourced from a pinned registry), and reject/warn on floating identifiers like `latest`/`stable` or unversioned names.

  • packages/@n8n/node-cli/src/template/templates/programmatic/ai/model-openai-compatible/template/nodes/ExampleChatModel/ExampleChatModel.node.ts:36-66 — The node forwards `model: modelName` directly from node parameters into `supplyModel` without pin enforcement.
  • packages/@n8n/nodes-langchain/nodes/llms/LMChatOpenAi/LmChatOpenAi.node.ts:300-360 — The node exposes a user-provided `model` resource locator and routes it to the provider; this is a runtime invocation surface where pinning should be governed.
• med

  Extend `llm-config.ts` model registry coverage (if needed) to also cover any remaining generation/evaluation stages so all production model invocations go through pinned factories rather than partially relying on user-entered model strings.

  • packages/@n8n/ai-workflow-builder.ee/src/llm-config.ts:18-134 — Currently, pinning is strong for the factories defined in this file; ensuring every relevant production path uses these factories reduces drift risk.

The codebase does have a managed/centralized prompt layer for at least the AI Workflow Builder and related evaluators (e.g., packages/@n8n/ai-workflow-builder.ee/src/prompts/* with re-exported builders). Core LLM calls use these prompt builders and, in key flows like the Planner Agent, enforce a structured output schema with validation and a bounded retry loop—matching the intended prompt/model-call management primitive.

• high

  Ensure every other agent/evaluator model call site in this repo (outside the planner/responder examples) follows the same pattern: (1) prompt text built from the centralized prompts module, and (2) output parsed/validated against an explicit schema gate before the result is used.

  • packages/@n8n/ai-workflow-builder.ee/src/prompts/index.ts:1-82 — Centralized prompts exist; this is the desired enforcement target for remaining call sites.
  • packages/@n8n/ai-workflow-builder.ee/src/agents/planner.agent.ts:121-176 — Demonstrates the correct pattern (validation + bounded retry). Other call sites should be checked for equivalent governance.
• med

  Add/strengthen automated tests that fail if a call site inlines a prompt literal or bypasses the centralized prompt builders (e.g., unit tests asserting the prompt builder function is used, or snapshot tests tied to prompt builder outputs).

  • packages/@n8n/ai-workflow-builder.ee/src/agents/planner.agent.ts:55-105 — Planner prompt governance is already testable via prompt builder outputs + schema parsing; extending this approach can prevent prompt drift elsewhere.

The repo contains at least one strong determinism pattern: deterministic workflow-builder node ID generation that is explicitly implemented and unit-tested. However, at higher-level evaluation/execution run boundaries (the parts that would need exact reproducibility of datasets/prompting/LLM sampling), the observed harness/config wiring does not show explicit capture of determinism controls such as RNG seed or pinned model sampling parameters; the execution flow also uses randomUUID for run IDs.

• high

  Add a determinism configuration object at evaluation-run boundaries (e.g., in the harness runner config): capture and persist (1) RNG/seed value(s), (2) LLM sampling parameters (temperature/top_p/max_tokens), (3) pinned model IDs/versions, and (4) relevant environment/config versions. Persist it alongside the evaluation run artifacts (transcript/output/score).

  • packages/@n8n/ai-workflow-builder.ee/evaluations/harness/runner.ts:30-120 — The run config type is the natural run boundary but contains no explicit seed/determinism controls in the observed portion.
• high

  Eliminate or quarantine non-deterministic identifiers used inside evaluation execution, or ensure they are explicitly recorded as non-reproducible metadata while the actual determinism controls are captured separately (e.g., record the seed + model parameters instead of relying on deterministic outputs only).

  • packages/cli/src/modules/instance-ai/eval/execution.service.ts:1-120 — Uses randomUUID when returning error results; this affects run identity but should not affect the ability to recreate the underlying workflow evaluation deterministically without an explicit captured determinism config.
• med

  Ensure CI/provenance capture includes the determinism-critical items, not just CI source (ci/local) and GH run IDs. Either embed commit SHA/branch in the metadata artifact or ensure the run artifact stores them directly (instead of relying on LangSmith auto-tracking).

  • packages/@n8n/ai-workflow-builder.ee/evaluations/cli/ci-metadata.ts:1-39 — Comments explicitly say commit SHA/branch are not included here; reproducibility of exact code prompts/configs would be stronger if persisted alongside run artifacts.

The codebase contains a strong, schema-governed AI output validation primitive for structured outputs. LLM text is parsed and validated against a declared Zod schema before any result is accepted, and when auto-fix is enabled, failures trigger a bounded retry loop that re-checks the corrected output against the same schema.

• high

  Search for any other LLM call sites whose outputs are consumed without going through a structured output parser (e.g., raw `content`/string outputs returned to workflow execution). Add/route them through a schema gate like `N8nStructuredOutputParser` to ensure consistent rejection/retry behavior.

  • packages/@n8n/nodes-langchain/utils/output_parsers/N8nStructuredOutputParser.ts:1-179 — Demonstrates the intended pattern: schema-validated parsing with rejection on mismatch; this can be used as the standard routing target.
• med

  If additional structured output formats exist beyond the current Zod-from-JSON-schema path, factor them into the same parsing/validation interface so all formats share identical error messages and retry semantics.

  • packages/@n8n/nodes-langchain/utils/output_parsers/N8nOutputFixingParser.ts:1-96 — Shows the retry loop depends on `this.outputParser` (same schema gate); ensuring format parity will preserve this guarantee.

The codebase contains a concrete grounding/wrongness check primitive implemented as LLM-as-judge correctness evaluation plus robust judge-output parsing (with multiple output-format fallbacks). This enables verdicts (pass/fail) derived from comparing generated output against expected context, rather than surfacing raw model text without verification.

• high

  Extend the wrongness-check coverage from offline evaluations to any production paths where AI outputs are acted upon (e.g., auto-executed workflow edits or direct user-facing factual claims). Ensure there is a deterministic verdict gate (schema-validated verdict + bounded retries/fallback) between generation and action.

  • packages/@n8n/agents/src/evals/correctness.ts:1-31 — Currently provides grounding/wrongness checks in the eval framework; confirm whether analogous gating exists in runtime production decision points.
• med

  Add explicit tests asserting end-to-end that judge verdict parsing fails safely (e.g., returns undefined/throws) and cannot be interpreted as a pass when parsing fails.

  • packages/@n8n/agents/src/evals/parse-judge-response.ts:1-33 — Parsing has fallbacks; add regression tests for malformed/ambiguous judge outputs to ensure the system doesn’t accept an incorrect verdict.

I did not find a closed self-correction feedback loop that takes a specific check/validation error, injects it into the next model attempt, and re-checks with bounded retries. The closest pattern is a bounded retry loop in the checklist verifier, but it retries without feeding back the failure details into the prompt.

• high

  Implement a closed feedback loop in the checklist verifier: when agent.generate throws or when parsed. results is missing/empty, capture the exact error (e.g., exception message, structuredOutput parsing failure reason, or validation mismatch) and append it to the next attempt’s user message/instructions (e.g., an additional section like “Previous attempt failure: … Fix accordingly”). Keep MAX_VERIFY_ATTEMPTS and ensure a safe fallback still returns an empty result if all attempts fail.

  • packages/@n8n/instance-ai/evaluations/checklist/verifier.ts:52-111 — Bounded retry exists, but failure information is not injected into subsequent prompts; it only logs/warns and re-runs with the same message construction.
• med

  Add a targeted test that simulates structuredOutput/JSON schema failures and asserts the next attempt includes the prior failure message and that parsing succeeds on retry (or safely falls back after MAX_VERIFY_ATTEMPTS).

  • packages/@n8n/instance-ai/evaluations/checklist/verifier.ts:52-111 — There is no shown mechanism or test coverage here that validates prompt-level feedback on specific failures.

The repo includes a full evaluation harness with scoring and artifact output: evaluators run via a central harness runner, harness-level score aggregation is implemented in a dedicated score-calculator module, and evaluation results are persisted to disk (including summary.json) for offline regression measurement. Implementation quality is strong and appears to support both local and LangSmith modes with reusable, testable components.

• med

  Verify and document the recurrence/golden-set comparison workflow end-to-end (e.g., how outputDir artifacts map to golden datasets and how diffs/regression thresholds are computed in CI), and ensure failing scores route back to the operator/CI gate.

  • packages/@n8n/ai-workflow-builder.ee/evaluations/harness/output.ts:1-220 — Artifacts are saved to disk, but the code slices reviewed did not confirm the specific CI/recurring comparison against a golden baseline.
  • packages/@n8n/ai-workflow-builder.ee/evaluations/harness/runner.ts:1-200 — Runner supports scoring feedback collection, but the reviewed slices did not show the full gate/threshold comparison loop that enforces quality on recurring runs.

The repository contains a runnable correctness-check primitive in the form of the `packages/testing/code-health` CLI, which runs rule checks and returns clear process exit codes (0 on pass; 1 on violations; 2 on internal errors). I did not find evidence of a root-level documented single command or CI workflow entrypoint wiring it, so the completeness of the “one entrypoint” story is only partial.

• high

  Add/confirm a top-level, documentation-backed command (e.g., a repo root `pnpm` script or Make/Just target) that runs `packages/testing/code-health/src/cli.ts` with the intended arguments, so agents can discover a standard one-command pass/fail check without spelunking.

  • packages/testing/code-health/src/cli.ts:1-105 — While the CLI itself has the pass/fail semantics, I did not locate (via code-graph queries) a root-level `package.json`/CI workflow entrypoint in this audit environment to confirm the standard command wiring.
• med

  Document the exact CLI invocation contract (supported commands/flags, expected env vars like `CODE_HEALTH_CHANGED_FILES`, and what constitutes pass/fail) in a README at `packages/testing/code-health/` so the correctness signal is externally governed.

  • packages/testing/code-health/src/cli.ts:1-105 — The behavior and exit codes are present in code, but there was no evidence in the audited slices of accompanying documentation explaining how to run it.

The codebase contains a governed diagnostics primitive via custom ESLint rules in `packages/@n8n/eslint-config`. The rules emit structured, rule-specific messages and often include autofixers, turning lint failures into actionable “what/where/how to fix” diagnostics.

• high

  Add/verify a repo-level runnable check documentation (e.g., `npm run lint` / `pnpm lint`) and ensure it surfaces ESLint rule IDs + file/line locations in CI logs, so diagnostics are actionable outside of local development.

  • packages/@n8n/eslint-config/src/plugin.ts:1-33 — Confirms the diagnostics are wired into an ESLint plugin and enabled in a recommended config, but does not itself demonstrate how the repo runs lint in CI.
• med

  For the most important rules, ensure each rule uses `meta.messages`/`messageId` consistently (and includes an autofix where safe), extending the existing pattern shown by `no-plain-errors` and `no-json-parse-json-stringify`.

  • packages/@n8n/eslint-config/src/rules/no-plain-errors.ts:1-50 — Shows the desired pattern: named messageId and fix implementation.

The codebase has an explicit positive confirmation mechanism in the AI workflow evaluation CLI: successful completion ends with exit code 0, while exceptions end with exit code 1. However, the inline comment indicates pass/fail is treated as informational rather than mapped to the exit code, limiting the strength of “correctness” signaling.

• high

  If the intended primitive is “confirm correct (green) vs wrong (fail) so agents/CI can safely stop,” update the CLI to map evaluation pass/fail (based on the computed `summary` / score vs threshold) to the process exit code (e.g., exit 0 only when pass, exit 2 or 1 when fail) instead of always exiting 0 on successful completion.

  • packages/@n8n/ai-workflow-builder.ee/evaluations/cli/index.ts:520-690 — Currently: always `process.exit(0)` after `runEvaluation`, with pass/fail described as informational (comment). This can be insufficient if correctness must gate CI/agent stopping.

This codebase contains strong machine-readable contract artifacts, primarily via exported Zod schemas (extension and package manifests) and explicit JSON-schema-driven tool input validation in the agent layer. These contracts are treated as source-of-truth for validation and are supported by automated tests.

• high

  Identify the production call sites that consume the exported schemas (beyond the schema definitions/tests) and ensure there is an explicit, documented path for agents/tools to retrieve the contract artifacts (e.g., stable imports/entrypoints or generated schema outputs).

  • packages/@n8n/extension-sdk/src/schema.ts:1-97 — Schema exists, but this audit slice only confirms the contract artifact; it does not yet confirm every consuming surface uses the exported schema as the gate.
  • packages/cli/src/modules/n8n-packages/spec/manifest.schema.ts:1-38 — Schema exists with refinements, but we did not yet read the handler/loader code paths that ingest manifests using this schema.
• med

  For workspace manifests, consider migrating/adding an explicit Zod schema (or equivalent JSON-schema artifact) alongside the parser to make the contract more uniformly machine-readable for downstream tooling.

  • packages/@n8n/instance-ai/src/workspace/workspace-manifest.ts:1-40 — Current contract is enforced via parsing logic, but it is not exported as a standalone schema artifact equivalent to the Zod-based manifests.

No tenant-key-on-every-record primitive was found. The database entities inspected (e.g., WorkflowEntity, Agent) do not include a tenant/organization/workspace discriminator column, and the shared base entity does not implement any tenant-key mixin or default tenant scoping mechanism. This suggests the codebase is not enforcing multi-tenant row ownership via a required tenant key on every record.

• high

  If this product is intended to be multi-tenant, introduce a tenant identifier column (tenantId/orgId/workspaceId) on all writeable business tables and enforce it via database constraints and/or default ORM scoping. Start by identifying the canonical tenant key used in this system (if any) and then backfill migrations + entity/repository updates.

  • packages/@n8n/db/src/entities/workflow-entity.ts:1-140 — WorkflowEntity lacks any tenant/org/workspace column, so this would be a required change to satisfy tenant-key-on-every-record.
  • packages/cli/src/modules/agents/entities/agent.entity.ts:1-53 — Agent entity lacks any tenant/org/workspace column; it would need the tenant key added and wired for scoping.
• med

  Add an automated check (lint/test) that fails CI if new/changed writeable entities or migrations omit the required tenant discriminator column, and add integration tests that attempt cross-tenant reads/lists/exports and assert denial.

  • packages/@n8n/db/src/entities/abstract-entity.ts:1-103 — There is no existing tenant-key base abstraction; a guardrail is needed to prevent future omissions.

This codebase does not appear to implement a database-enforced tenancy isolation safety net (e.g., Postgres RLS policies forced at the DB layer, or schema/database-per-tenant). While the project has “workspaceId/tenant-like” concepts, the concrete scoping mechanisms observed are implemented in application-layer components (e.g., scoped filesystem/workspace and instance security settings), not in the database layer as a default-enforced filter.

• high

  Confirm whether n8n’s data model is truly multi-tenant at the DB level (workspace/instance boundaries) and, if so, implement defense-in-depth in the database: add RLS policies (or schema-per-tenant / DB-per-tenant) that restrict reads/writes by the server-resolved tenant/workspace identifier, and ensure policies are FORCED even for table owners.

  • packages/@n8n/instance-ai/src/workspace/scoped-workspace.ts:1-193 — Current “scoping” is application/filesystem level; it does not protect against a missed DB filter.
• med

  Add integration tests that attempt cross-workspace (cross-tenant) read/list/export actions and assert denial at the DB boundary (not only application 403s).

  • packages/cli/src/instance-settings-loader/loaders/security-policy.instance-settings-loader.ts:1-55 — Existing enforcement points observed are app-level configuration; tests should validate DB-layer denial as well.

I did not find evidence of a default-scope mechanism that automatically applies tenant/project isolation to queries. Instead, the code relies on explicit scoping in some methods, and at least one critical 'existing record' lookup (`findOneBy({ id: threadId })`) is not scoped by project/workspace, which is consistent with this primitive being absent at the data-access layer.

• high

  Introduce (and enforce) a data-layer default scope for tenant/project identifiers so that all repository/ORM reads are automatically filtered. Concretely, ensure `findOrCreateInSerializableTransaction` cannot load a thread without the correct tenant/project scope (e.g., by making the base repository/EntityManager inject `projectId`/tenant constraints for all `find*` calls).

  • packages/cli/src/modules/agents/repositories/agent-execution-thread.repository.ts:55-104 — Current code reads with `repository.findOneBy({ id: threadId })` inside the transaction, with no `projectId` constraint. This is the precise kind of omission default-scoped queries should prevent.
• med

  Audit other repository/entity queries for the same pattern: any `findOneBy({ id: ... })` / `findOne(...)` / query builder reads that do not include the tenant/project discriminator should be converted to default-scoped behavior or explicitly constrained at the repository boundary.

  • packages/cli/src/modules/agents/repositories/agent-execution-thread.repository.ts:55-104 — This file demonstrates the anti-pattern: a non-scoped 'existing record' lookup preceding a scoped write.

The codebase establishes an authenticated principal (`req.user`) at the request boundary via `AuthService.createAuthMiddleware`, but I did not find any implementation of “tenant context at the boundary” (i.e., tenant/workspace/org context derived once from the verified identity/JWT before business logic). Therefore, this tenancy isolation primitive appears absent in the request-entry layer.

• high

  Implement tenant/workspace/org context resolution in the entry auth middleware (same layer as `createAuthMiddleware`), deriving tenant context from the verified principal/session (e.g., from user membership/claims), storing it in a trusted request-scoped field (e.g., `req.tenant`/`req.workspaceId`), and ensuring downstream services use this trusted value rather than client-supplied IDs.

  • packages/cli/src/auth/auth.service.ts:60-155 — The middleware currently only sets `req.user`/`req.authInfo` after validating the JWT from a cookie; tenant context is not resolved here.

The codebase does implement a Redis cache key prefix, but it is based on global configuration (`globalConfig.redis.prefix` + `globalConfig.cache.redis.prefix`) rather than tenant-aware key namespacing. Concrete cache keys like `mfa:enforce` and `roles:scope-map` are also not tenant-prefixed, and there is no visible default tenant scoping in the cache layer.

• high

  Enforce tenant-aware cache key construction in the cache layer (`CacheService`) so that every get/set/delete automatically prefixes keys with a tenant identifier (e.g., `tenant:{tenantId}:...`) derived from trusted tenant context (request/auth/session), not client input.

  • packages/cli/src/services/cache/cache.service.ts:34-66 — Redis `keyPrefix` is derived only from global config and does not incorporate tenant context; this is the best central place to enforce default tenant namespacing.
• high

  Audit and update all constant/bare cache keys (e.g., `mfa:enforce`, `roles:scope-map`) to either (a) rely on the new cache-layer tenant prefix automatically, or (b) include an explicit tenant component in the composed key where the cache layer cannot infer it.

  • packages/cli/src/mfa/mfa.service.ts:10-48 — Uses `MFA_CACHE_KEY = 'mfa:enforce'` with `cacheService.set/get`, which is not tenant-prefixed.
  • packages/cli/src/services/role-cache.service.ts:32-88 — Uses `RoleCacheService.CACHE_KEY = 'roles:scope-map'` for `cacheService.get/set`, which is not tenant-prefixed.
• med

  Add an integration test that attempts cross-tenant cache access (set in tenant A, get in tenant B) and asserts it is isolated/denied (or returns miss), to prevent silent cache-based leaks.

  • packages/cli/src/services/cache/__tests__/cache.service.test.ts:1-120 — Existing tests cover cache behavior (TTL, backend selection, key handling) but not tenant isolation; extend test coverage to verify tenant-prefixed keys.

No evidence was found of tenant-scoped object/blob partitioning in the storage layer: the S3 node and S3 request helper appear to operate on caller-provided `bucketName` and `fileKey`/`path` without automatically adding a tenant/workspace namespace or enforcing tenant-scoped access at the blob/object addressing level.

• high

  Enforce tenant/workspace-scoped object key partitioning at the lowest storage boundary (e.g., S3 request helper or an unconditional wrapper): require the caller to supply only a tenant-scoped identifier, and automatically prefix object keys (e.g., `${workspaceId}/...`) or select per-tenant buckets.

  • packages/nodes-base/nodes/Aws/S3/GenericFunctions.ts:19-82 — S3 requests are built from `bucket` and `path` inputs; add tenant scoping/partition enforcement here so it cannot be bypassed.
• high

  Harden the S3 node object operations (download/upload/delete/copy/list) so that `fileKey`/`destinationPath` are transformed/validated into tenant-scoped object identifiers by default (and do not permit reading/writing arbitrary global keys).

  • packages/nodes-base/nodes/Aws/S3/V2/AwsS3V2.node.ts:679-732 — Download uses `fileKey` directly to request `${basePath}/${fileKey}`; tenant prefixing should be automatic and non-optional.
  • packages/nodes-base/nodes/Aws/S3/V2/AwsS3V2.node.ts:736-818 — Delete uses `fileKey` directly; tenant-scoped keys are required to prevent cross-tenant deletion.

I did not find a concrete “tenant context in async work” primitive implemented in the async layers. The core queued execution worker (`JobProcessor`) consumes a job payload (`JobData`) that does not include tenant/workspace/org/account identifiers, and it immediately queries execution data by `executionId` without any tenant context being established from the job message. This means tenant isolation in async processing appears to rely on something outside the payload (or is missing entirely at the primitive level).

• high

  Introduce mandatory tenant context for queued execution jobs: extend `JobData` to include a verified tenant/workspace/org identifier (or include enough data for the worker to derive it from a trusted source) and update enqueue sites accordingly.

  • packages/cli/src/scaling/scaling.types.ts:18-48 — Current `JobData` lacks any tenant/workspace/org/account field to support tenant-scoped worker enforcement.
• high

  Update the worker entry point to re-establish tenant context before touching data. Concretely, ensure `JobProcessor.processJob` sets/loads tenant context (from trusted job payload data or trusted execution/workflow lookup) and that repository calls cannot proceed without tenant scoping.

  • packages/cli/src/scaling/job-processor.ts:39-78 — Worker immediately loads execution by `executionId` via repository call, with no tenant context shown.
• med

  Apply the same tenant-context rule to other async message boundaries (task broker / runner messaging). Ensure handler paths either carry tenant context in message payloads or derive it in a way that enforces tenant-scoped access by default.

  • packages/cli/src/task-runners/task-broker/task-broker.service.ts:140-220 — Task routing/handler dispatch occurs at this async boundary; tenancy should be enforced here by default, not via ambient assumptions.

The codebase contains rate limiting, but the implemented buckets are keyed by IP or user id / request-body field value. There is no evidence of per-tenant (workspace/account/org) quota/rate-limit buckets, so the “per-tenant resource limits” primitive is not present as specified.

• high

  Add a tenant-scoped rate-limiter strategy: extend the rate-limit decorator + RateLimitService so limiter keys are namespaced by a trusted tenant/workspace identifier (e.g., `tenant:${tenantId}:...`) resolved from the authenticated principal, and update middleware wiring so it is enforced by default for tenant-affecting endpoints.

  • packages/cli/src/services/rate-limit.service.ts:1-99 — Limiter keys are currently `user:${req.user.id}` (and optionally `body:${value}`), which will not prevent cross-tenant noisy-neighbor effects.
  • packages/@n8n/decorators/src/controller/rate-limit.ts:1-77 — Only user-keyed and body-keyed configurations exist; add tenant-keyed configuration and corresponding key extraction.
• med

  Update/extend integration tests to verify isolation: create two tenants/workspaces, drive one tenant to exhaust its limit, and assert requests from the other tenant are not throttled (and that 429 behavior is tied to the tenant bucket, not only user/IP).

  • packages/cli/src/modules/dynamic-credentials.ee/__tests__/dynamic-credentials-rate-limit.integration.test.ts:1-193 — Current rate-limit tests assert 429 enforcement and OPTIONS behavior, but they do not demonstrate per-tenant isolation (the limiting keying shown by implementation is IP/user/body).

No tenant-scoped key management is implemented. Encryption keys are managed and selected at the instance/global level (via `instanceSettings.encryptionKey` and a single `DeploymentKey` active key), and the `DeploymentKey` entity does not include any tenant/workspace identifier to support per-tenant keys, BYOK/CMEK per tenant, or per-tenant crypto-erase.

• high

  Add tenant scoping to the key model: introduce a tenant/workspace identifier column to `DeploymentKey` (and migrations), enforce uniqueness/activation invariants per tenant (e.g., one active key per tenant per type), and ensure all key-manager queries filter by tenant.

  • packages/@n8n/db/src/entities/deployment-key.ts:1-19 — Current key entity lacks any tenant column, so per-tenant keys cannot be represented.
• high

  Update the key management API to resolve keys per tenant: change `KeyManagerService` methods (e.g., `getActiveKey`, `getKeyById`, `rotateKey`, `listKeys`) to accept a tenant identifier and apply it in `DeploymentKeyRepository` queries.

  • packages/cli/src/modules/encryption-key-manager/key-manager.service.ts:1-178 — Key selection is currently based on `type/status` only, with no tenant scoping.
• high

  Update the crypto layer to use tenant context when selecting keys/envelope wrapping: modify `Cipher`/encryption callers so the correct tenant-scoped envelope key (or per-tenant deployment key id) is used instead of the global `instanceSettings.encryptionKey`.

  • packages/core/src/encryption/cipher.ts:1-131 — Cipher defaults to instance-global `encryptionKey` and does not incorporate tenant context in key selection.
• med

  Add isolation tests for crypto boundaries: integration tests that (1) create/activate keys for multiple tenants/workspaces, (2) encrypt identical payloads under each tenant, and (3) assert that decrypting with the wrong tenant’s key material fails/returns incorrect data, plus crypto-erase behavior for a tenant.

  • packages/@n8n/db/src/entities/deployment-key.ts:1-19 — Because key scoping is currently impossible at the schema level, such tests would likely be missing or ineffective until schema changes are made.

This codebase implements admin/elevated-role scoping via a role model that distinguishes `global` vs `project` roles and anchors project-scoped elevated assignments to a per-`projectId` membership table (`ProjectRelation`). There is no sign (from the examined authz/data-model wiring) of a simplistic global `isAdmin` boolean gating all elevated behavior; instead, elevated privileges flow from role scopes and roleType, with project-scoped role assignments computed through project relations.

• high

  Add/extend integration tests that explicitly attempt cross-project/project-membership elevated access (e.g., assign a project-scoped admin/editor role in project A and verify the same principal cannot administer resources in project B).

  • packages/@n8n/db/src/entities/project-relation.ts:1-26 — Project membership/role assignment is the boundary; tests should validate that elevated role checks correctly refuse cross-project actions.
• med

  Audit authorization entrypoints to confirm that every permission check uses the membership-resolved role/scopes (not only a principal’s derived role scopes without ensuring the resource’s project context matches).

  • packages/@n8n/db/src/repositories/role.repository.ts:1-221 — Role association logic differentiates global vs project roles; authorization callers should rely on these semantics rather than re-implementing assumptions.

The codebase contains the uniform-not-found pattern for at least the executions resource: when an execution lookup is blocked due to insufficient permissions (including cross-workspace/tenant access), the service returns NotFoundError (404) rather than ForbiddenError (403). However, ForbiddenError (403) exists broadly, and this primitive is only confirmed at the execution-related sites reviewed here.

• high

  Audit every per-resource fetch/action endpoint for workspace/tenant-scoped data to ensure access-denied is mapped to the same response as not-found (404/uniform error), not to ForbiddenError (403). Start with endpoints analogous to /executions/:id (getOne, stop, retry, delete, update, and any 'findOne' repository wrappers).

  • packages/cli/src/executions/executions.controller.ts:92-145 — These endpoints show the correct uniform-not-found behavior when no accessible workflow IDs exist.
  • packages/cli/src/executions/execution.service.ts:220-270 — This service demonstrates the correct mapping from blocked/insufficient-permissions to NotFoundError (404).
• med

  Add an explicit cross-tenant/workspace isolation integration test for each resource fetch/action that asserts identical error responses for a non-existent ID and an inaccessible-but-existing ID (no 403 distinction, no different message/timing).

  • packages/cli/src/executions/executions.controller.ts:92-145 — These are the high-value per-resource entry points where the primitive should be test-covered.

The repository contains multiple isolation-related tests, including cross-project access control and endpoint/security-header isolation. However, there are no clear integration/security tests that specifically attempt cross-tenant read/write/list/export and async access and assert denial—so the 'Cross-tenant isolation tests' primitive is not implemented as defined.

• high

  Add a dedicated cross-tenant security test suite that creates resources under Tenant A and attempts (from Tenant B identities) cross-tenant reads, writes, listing, export/download, and any async/background retrieval paths; assert uniform denial (preferably the same not-found/forbidden behavior policy used elsewhere).

  • packages/cli/test/integration/access-control/cross-project-access.test.ts:1-220 — Existing tests prove cross-*project* permission boundaries, but this is not the cross-*tenant* boundary required by the primitive.
• high

  Extend existing isolation suites (Playwright/API and CLI integration) to include tenant boundary checks for every major data operation: list, get-by-id, update, create, delete, export, and async/background processing. Keep tenant context resolution tied to verified identity (JWT/session) rather than client-supplied tenant IDs.

  • packages/testing/playwright/tests/e2e/api/form-endpoint-isolation.spec.ts:1-118 — Current isolation coverage is endpoint-routing; add tenant-scoped resource access attempts instead.
  • packages/testing/playwright/tests/e2e/api/webhook-isolation.spec.ts:1-50 — Current isolation coverage is security headers; add tenant-scoped resource access attempts instead.
• med

  Identify the system’s tenant model (e.g., organization/instance/workspace concept) and mirror the cross-project tests using that tenant boundary in test setup utilities so future tests consistently exercise the correct isolation boundary.

  • packages/cli/test/integration/access-control/cross-project-access.test.ts:1-220 — Cross-project test setup already uses backend test utilities and authenticated agents; the same pattern should be adapted for the tenant boundary.

Federated SSO is present and appears well-wired for both SAML and OIDC. The codebase exposes SAML ACS endpoints and an OIDC callback flow that both delegate authentication to protocol-specific services and perform verification steps (SAML XML/metadata validation; OIDC signed state/nonce verification and authorization code/token processing via openid-client). After successful authentication, it establishes an authenticated session using the auth service’s cookie issuance.

• high

  Review whether SAML response signature verification (beyond XML schema validation) is fully enforced inside samlService.handleSamlLogin() for all configurations (e.g., metadata-based key retrieval, signature validation, and audience/recipient checks). Add explicit tests for signature failure, tampered assertions, and wrong Recipient/Audience.

  • packages/cli/src/modules/sso-saml/saml.controller.ee.ts:80-142 — ACS handler delegates trust decisions to samlService.handleSamlLogin; this is the critical boundary where full cryptographic verification must occur.
  • packages/cli/src/modules/sso-saml/saml-validator.ts:1-114 — saml-validator currently shows XML/XSD schema validation and identity provider binding checks; ensure signature/token validation is also performed in the actual login path.
• med

  Ensure OIDC logout/session revocation semantics are consistent: verify cookie/token lifetimes, whether logout invalidates server-side sessions or refresh tokens (if any), and whether role/provisioning changes take effect promptly.

  • packages/cli/src/modules/sso-oidc/oidc.controller.ee.ts:69-132 — The callback issues a session cookie via authService.issueCookie(res, user, true, req.browserId); confirm session revocation and expiry behavior elsewhere.
• low

  Add/expand observability around SSO failures: correlate IdP error causes (state/nonce invalid, token exchange failure, claim/userinfo fetch failure) with structured logs and user/session identifiers to speed incident response.

  • packages/cli/src/modules/sso-oidc/oidc.service.ee.ts:260-620 — OIDC login flow already logs several error conditions; further standardization/correlation IDs would improve operational quality.

Directory provisioning via SCIM is not implemented in this codebase. The repository contains an SSO provisioning configuration/controller and related role-mapping based provisioning service logic, but no SCIM 2.0 endpoints (/scim/v2/Users, /scim/v2/Groups) or SCIM-style PATCH/deactivation handlers were found.

• high

  Add a SCIM 2.0 HTTP surface under the identity/provisioning backend (e.g., /scim/v2/Users and /scim/v2/Groups) including request/response models and schema support.

  • packages/cli/src/modules/provisioning.ee/provisioning.controller.ee.ts:1-45 — Current provisioning controller is limited to /sso/provisioning/config; no SCIM v2 endpoints are present here.
• high

  Implement SCIM lifecycle operations with explicit deprovisioning: handle deactivation (e.g., PATCH active=false) and delete flows so that access is revoked (e.g., remove memberships/relations and invalidate any active sessions/tokens tied to the user).

  • packages/cli/src/modules/provisioning.ee/provisioning.service.ee.ts:200-283 — The service currently removes stale *project relations* based on role mappings, but it does not demonstrate SCIM deactivate/delete semantics or access revocation beyond project relation removal.
• med

  Map SCIM identity attributes (externalId, userName, emails, groups) to the existing internal role/permission data model, ensuring all provisioning mutations flow through a single centralized authorization/provisioning policy layer.

  • packages/cli/src/modules/provisioning.ee/provisioning.service.ee.ts:200-283 — Existing logic provisions via role-slugs and ProjectRelation deletes/adds; SCIM should be wired to the same mechanisms but driven by SCIM requests, with correct lifecycle semantics.

RBAC modeled as data is present. The codebase persists roles/scopes via `AuthRolesService` (DB Role/Scope entities synchronized from `@n8n/permissions` definitions) and enforces authorization through centralized scope/role policy logic (`userHasScopes`) rather than scattered hardcoded privilege booleans. Frontend also uses a scoped RBAC model (store + middleware) for permission evaluation.

• high

  Audit remaining backend endpoints/handlers to confirm they all call the centralized RBAC policy (`userHasScopes`/`@ProjectScope` style decorators or equivalent) and do not introduce scattered per-handler privilege checks.

  • packages/cli/src/permissions.ee/check-access.ts:1-150 — This file should be the primary chokepoint; verify all protected operations delegate to it.
• med

  Verify the backend also has explicit deny-by-default behavior at the routing/middleware boundary (i.e., endpoints without a RBAC guard are not silently accessible).

  • packages/frontend/editor-ui/src/app/utils/rbac/middleware/rbac.ts:1-26 — Frontend gating exists, but backend deny-by-default should be confirmed separately.

This codebase contains evidence of centralized authorization/policy chokepoints in the CLI backend: workflow execution authorization is routed through dedicated checker services (SubworkflowPolicyChecker and CredentialsPermissionChecker) and resource access is abstracted behind AccessService. However, the presence of more granular controller-level policy enforcement could not be fully verified from the sampled files, so implementation appears solid in some execution paths but only partially mapped to every public API entry point.

• high

  Audit all backend REST controllers for consistency: ensure every entry point that returns protected resources uses the same centralized authorization services/checkers (AccessService and permission checkers) and does not rely on scattered per-endpoint role/permission logic.

  • packages/cli/src/workflows/workflows.controller.ts:1-220 — Marked as a should-be site (controller authorization should be centralized). Not directly verified in this run due to lack of read slice for the relevant portion.
• med

  Confirm that authorization (not just authentication) is policy-driven in MCP: after getAuthMiddleware attaches req.user, ensure MCP handlers call an explicit permission/policy layer for tool/workflow access and log denials.

  • packages/cli/src/modules/mcp/mcp-controller.ts:1-216 — Entry-point wiring to centralized auth middleware is present, but deeper authorization policy application for MCP requests was not validated from the provided slices.
• med

  Ensure centralized authorization is uniformly applied to runtime credential surfaces via their dedicated access services, with deny-by-default behavior and consistent audit/telemetry on denials.

  • packages/cli/src/modules/runtime-credentials/runtime-credentials-access.service.ts:1-220 — Marked as a should-be site (runtime credential access should be centralized). Not directly verified in this run due to lack of read slice for the relevant portion.

In the UI command bar, authorization is permission-model driven (via `getResourcePermissions` / `hasPermission`). However, the user store still defines privilege shortcut booleans like `isAdmin`/`isAdminOrOwner` by directly comparing the user role, which violates the “no hardcoded privilege shortcuts” requirement that privilege must flow through the role/permission model without boolean shortcut flags.

• high

  Remove/avoid `isAdmin`/`isAdminOrOwner` boolean privilege shortcuts in `users.store.ts`. Instead, derive UI gating from the standardized permission layer (e.g., the same `getResourcePermissions` / `hasPermission` approach used elsewhere) so privilege decisions are centrally auditable and role-driven.

  • packages/frontend/editor-ui/src/features/settings/users/users.store.ts:20-60 — Contains `_isAdmin` computed via `user?.role === ROLE.Admin` and derived booleans like `isAdminOrOwner`, which are the exact form of privilege shortcut this primitive forbids.
• med

  Search for other `isAdmin` / `isRoot`-style booleans used for access control and refactor them to permission checks against the role/permission model (not direct role equality).

  • packages/frontend/editor-ui/src/features/settings/users/users.store.ts:20-60 — Establishes a clear anti-pattern location to use as a refactoring template for other occurrences.

Deny-by-default is present for the Public API (v1): the `publicApiScope` middleware rejects requests by default (403) when no token grant exists or when the required scope is not explicitly present. Key public route handlers for workflows and executions apply this middleware, preventing silent-open endpoints.

• high

  For any new Public API v1 endpoint, ensure it is wired with `publicApiScope(<required-scope>)` (and any additional scope/tag/project middleware) rather than relying on downstream checks.

  • packages/cli/src/public-api/v1/shared/middlewares/global.middleware.ts:1-160 — The deny-by-default behavior lives in `publicApiScope` / `makePublicApiScopeEnforcementMiddleware`; new endpoints should use this boundary.
• med

  Add/extend tests similar to `global.middleware.test.ts` to cover at least one representative new handler per resource type (workflows, executions, credentials, etc.), asserting 403 when scope is missing.

  • packages/cli/src/public-api/v1/__tests__/global.middleware.test.ts:1-114 — There are already unit tests asserting default-deny behavior for `publicApiScope` (missing `tokenGrant`, missing required scope, empty `apiKeyScopes`). Reuse the same pattern for handler-level wiring.

This codebase applies the “AuthN before AuthZ at the boundary” primitive correctly at key HTTP entry points: REST requests use a centralized middleware that verifies the auth cookie/JWT before setting `req.user`, and MCP HTTP endpoints use a dedicated middleware that verifies the Bearer token before the controller uses `req.user` for access-relevant decisions.

• med

  Audit additional public HTTP entry-point handlers beyond the MCP controller and verify each is wired with the appropriate authentication middleware before any handler logic reads `req.user` for gating/authorization.

  • packages/cli/src/modules/mcp/mcp.controller.ts:61-169 — Shows the correct pattern for MCP; other entry points should be checked for the same wiring discipline.

MFA enforcement/step-up-like gating is present and centralized: the auth middleware checks whether MFA was used during token/session creation (`usedMfa`) and blocks access when instance policy enforces MFA, unless the route explicitly allows skipping (`allowSkipMFA`). MFA setup endpoints are configured to bypass this gate so users can enroll/verify. However, what’s implemented is closer to a global “require MFA for access” control than a fine-grained per-action step-up flow (the code shows enforcement gating + route bypass, but not an obvious per-sensitive-action second-factor prompt/flow beyond the `usedMfa` session attribute).

• high

  Confirm there is a truly fine-grained step-up mechanism for *sensitive actions* (not just a global enforcement gate). If needed, introduce a dedicated step-up requirement per endpoint/action (e.g., a separate `requireStepUp`/`minMfaAssurance` route metadata) that triggers an additional second-factor challenge for existing sessions that were created without MFA.

  • packages/cli/src/auth/auth.service.ts:70-133 — Enforcement is based on `mfaEnforced` and session `usedMfa`, with only `allowSkipMFA` as a bypass. There is no separate per-action step-up prompt/requirement shown in the enforcement logic.
• med

  Audit all sensitive endpoints for `allowSkipMFA` usage and ensure only MFA enrollment/verification and explicitly safe endpoints can bypass. Add tests that verify the MFA gate behavior for representative protected routes.

  • packages/cli/src/controllers/mfa.controller.ts:62-186 — MFA endpoints are explicitly allowed to skip MFA (`allowSkipMFA: true`), which is correct for enrollment/verification, but this pattern should be limited to only those safe cases.
  • packages/cli/src/controller.registry.ts:162-202 — The bypass behavior is route-metadata-driven; incorrect `allowSkipMFA` settings elsewhere could silently weaken enforcement.
• low

  Document the intended semantics of `usedMfa` and how it maps to “step-up” assurance in your threat model (global enforcement vs. per-action step-up), so future route additions follow the right policy.

  • packages/cli/src/auth/auth.service.ts:250-290 — The primitive is implemented as a session attribute (`usedMfa`) checked against policy (`isMFAEnforced()`), so the codebase semantics should be explicitly documented.

Session & token hygiene is implemented in multiple places with short-lived expiry, server-side invalidation/rotation, and revocation semantics. OAuth consent-session cookies are JWT time-bounded and explicitly cleared on errors/invalid sessions. MCP OAuth access tokens are short-lived and are invalidated server-side via DB presence checks; refresh tokens are rotated and both access/refresh tokens support explicit revoke endpoints via DB deletes. Additionally, the token-exchange subsystem adds bounded lifetimes and replay protection via JTI consumption (server-side).

• high

  Confirm and document the logout/revoke call chain for each token type (OAuth consent session cookie, MCP access/refresh tokens, and token-exchange access tokens). Where logout exists, ensure it triggers clearCookie() (consent session) and DB revocation/delete (access/refresh) rather than only client-side removal.

  • packages/cli/src/modules/mcp/oauth-session.service.ts:1-63 — There is clearSession() for cookie invalidation, but this audit did not include the actual logout route wiring.
  • packages/cli/src/modules/mcp/mcp-oauth-token.service.ts:1-217 — Server-side revokeAccessToken/revokeRefreshToken exists, but this audit did not include the route(s) that call revokeToken() or revokeAccessToken()/revokeRefreshToken() on logout.
• med

  Ensure minted token scopes/claims are consistently scoped (aud/resource/iss/sub + any scope claim) and that authorization decisions depend on server-resolved identity/role state rather than solely token-embedded claims where role changes must take effect immediately.

  • packages/cli/src/modules/mcp/mcp-oauth-token.service.ts:1-217 — Access tokens include aud/client_id/sub and are validated with DB presence, but this audit did not trace downstream authorization logic for scope enforcement.

Scoped machine credentials are implemented: API keys are stored as non-human credentials with persisted `scopes` and `audience` (`user_api_keys`), existing keys are backfilled with role-derived scopes, and authentication strategies verify tokens/credentials and attach scoped identities to requests for least-privilege authorization. A separate scoped JWT strategy for token-exchange also cryptographically verifies and maps to role scopes.

• med

  Add/confirm end-to-end revocation semantics for API-key/JWT credentials (e.g., ensuring server-side invalidation for rotated/deleted keys is enforced in the strategies and token-exchange paths).

  • packages/cli/src/services/api-key-auth.strategy.ts:1-101 — This strategy verifies and then authorizes by looking up the API key record by `apiKey` and `audience`, which is good for revocation by deletion; however, a dedicated check for server-side invalidation/blacklisting is not shown in the reviewed snippet.

This codebase does implement IP allowlists for the Webhook trigger: it supports per-node `ipWhitelist` entries (single IPs and CIDRs) and enforces them before any authentication/authorization logic runs. I did not find an additional, clearly-wired per-tenant/network constraint at higher levels (e.g., instance-wide middleware). The Form flow appears to support IP allowlist helpers, but the specific boundary enforcement site for the Form handler was not identified in the inspected slices.

• med

  Confirm whether the Form trigger (and other public entrypoints) should enforce the same IP allowlist boundary check, and wire it at the request entry before any authentication validation. Add/verify a clear `if (!isIpAllowed(...)) { 403/401 }` boundary near the handler entry for the Form POST/GET paths.

  • packages/nodes-base/nodes/Form/utils/utils.ts:800-840 — This slice shows form authentication/credential validation logic using `validateWebhookAuthentication` and error handling, but the boundary IP allowlist check site was not confirmed here.

TLS is supported (HTTPS is created when `protocol === 'https'`), but encryption-in-transit is not forced. When the config is not set to HTTPS, the server starts an `http.createServer`, allowing plaintext traffic; no unconditional HTTPS redirect/HSTS enforcement was evidenced in the inspected server bootstrap code.

• high

  Force HTTPS unconditionally for the inbound edge: remove/disable the plaintext `http.createServer` path (or make it redirect all requests to HTTPS with HSTS). Ensure this behavior is correct behind proxies/load balancers (e.g., correct `trust proxy` usage and redirect conditions).

  • packages/cli/src/abstract-server.ts:100-220 — The plaintext transport path is explicitly created via `http.createServer(app)` when `protocol !== 'https'`.
• med

  Add/verify transport hardening headers: ensure `Strict-Transport-Security` (HSTS) and redirect behavior are set on all relevant paths (including behind any reverse proxy).

  • packages/cli/src/abstract-server.ts:1-220 — The inspected bootstrap shows server selection and common middleware setup; no guaranteed HSTS/redirect enforcement is shown in the server initialization code.

Encryption-at-rest is present and centrally implemented via `packages/core/src/encryption/cipher.ts` (AES-256-CBC payload encryption plus AES-256-GCM authenticated DEK wrapping, with optional key-rotation via `EncryptionKeyProxy`). Sensitive external secrets configuration is handled encrypted during migration: decrypted from the encrypted `settings` blob and then re-encrypted into `secrets_provider_connection.encryptedSettings`.

• high

  Verify that encrypted-at-rest coverage extends to backup/export/derived data paths (e.g., database dumps, object storage backups, log/trace exports) and that no plaintext sensitive fields are written by any repository/serialization layer outside the cipher abstraction.

  • packages/core/src/encryption/cipher.ts:1-131 — This proves application-level encryption/decryption, but does not by itself prove backups/exports are encrypted or that every storage path uses the cipher.
• med

  Audit all DB columns that store credential material (e.g., credentials data blobs and any external secrets settings columns) to ensure they are always written via `encryptWithInstanceKey`/`encryptV2` and never persisted in plaintext on any code path (including tests/migrations).

  • packages/@n8n/db/src/migrations/common/1771500000000-MigrateExternalSecretsToEntityStorage.ts:75-115 — This migration demonstrates correct encrypted writes for one sensitive location; other tables/columns may exist and should be confirmed.

This codebase has centralized encryption key management for data encryption keys (KeyManagerService + EncryptionKeyProxy + cipher encryptV2/decryptV2). Keys are stored centrally (DeploymentKeyRepository), there is a rotation mechanism (rotateKey/addKey + active/inactive statuses), and ciphertexts can reference specific key ids for correct decryption. However, the implementation does not clearly provide the full 'managed key store with scheduled rotation and emergency revocation procedure' model: markInactive() is not fully enforced (TODO), and no explicit emergency revocation flow is evidenced in the reviewed code paths.

• high

  Add/implement an explicit emergency revocation procedure (e.g., a 'revoke' operation that marks keys unusable for decrypt and/or forces cipher to reject revoked key ids), and expose it via the encryption-key controller with appropriate admin scope. Ensure it is enforced on every decryptV2 path (key id lookup).

  • packages/cli/src/modules/encryption-key-manager/key-manager.service.ts:1-178 — markInactive() exists but has a TODO for usage-count guarding; no revocation semantics beyond inactive are shown.
  • packages/core/src/encryption/cipher.ts:1-131 — decryptV2 fetches keys by id and decrypts; it should enforce revocation/reject semantics if added.
• med

  Ensure scheduled rotation is configured and enforced by code (not only an on-demand API call). For example, add a scheduler/job that rotates keys on a configured interval and deactivates old keys according to policy.

  • packages/cli/src/modules/encryption-key-manager/key-manager.service.ts:1-178 — Rotation exists as rotateKey(), but no scheduled rotation mechanism was observed in the reviewed files.
  • packages/cli/src/modules/encryption-key-manager/encryption-key.controller.ts:1-59 — The API controller provides create/list, implying rotation is currently operationally driven rather than scheduled.
• med

  Clarify and harden key storage model boundaries: if 'centralized key management' is expected to be a managed external KMS/HSM/Vault, integrate it (or document the DB-backed design clearly as the authoritative managed store).

  • packages/cli/src/modules/encryption-key-manager/key-manager.service.ts:1-178 — Keys are managed in DeploymentKeyRepository (DB-backed), and wrapped with the instance encryption key; no external managed KMS interface is evidenced here.

This codebase has a working secrets-management primitive via the Enterprise External Secrets EE module. It provides runtime integration with external secret managers (HashiCorp Vault and Azure Key Vault), authenticates using configured connection settings, fetches secret values at connect/update time, caches them in memory, and serves secrets through getters for expression-based references. I did not find evidence of plaintext secrets being hardcoded into the provider implementation paths themselves.

• high

  Treat external-secrets integration settings as sensitive: ensure any logs around provider init/update never include secret values/tokens (e.g., confirm logger usage and redaction across the rest of the external-secrets module).

  • packages/cli/src/modules/external-secrets.ee/providers/vault.ts:220-615 — Provider logs debug messages about retrieving secrets, token renewal, and failures; verify these logs never include the actual token/client_secret/secret contents.
  • packages/cli/src/modules/external-secrets.ee/providers/azure-key-vault/azure-key-vault.ts:1-155 — Azure provider logs warning/error paths; confirm it never logs secret values (the code stores values in cachedSecrets but logging should be non-sensitive).
• med

  Ensure rotation/revocation is enforced end-to-end for Vault/Key Vault connections (e.g., confirm connect/update lifecycle triggers on credential/provider changes and supports cache refresh without requiring restarts).

  • packages/cli/src/modules/external-secrets.ee/providers/vault.ts:220-615 — VaultProvider implements token renewal scheduling and update() refreshes cached secrets; validate the module calls update() on a consistent interval/config change path.

The primitive does not hold for this codebase: the full-history secret scan found committed secret-like values, and the repo contains a fixture file with credential material (API keys, AWS credentials, a GitHub token, and a private key block).

• high

  Remove the committed credential material from git history (not just the current tree). Delete/replace the fixture contents with non-secret test vectors, then rewrite history (e.g., filter-repo/bfg) and rotate any credentials that could have been real.

  • packages/@n8n/instance-ai/evaluations/computer-use/fixtures/leaked-credentials.txt:1-14 — Contains credential-like strings and a private key PEM that triggered the secret scan; this violates the requirement that there be no committed secrets across all commits.

Schema validation libraries (notably Zod-style APIs via `parse/safeParse`) are present and DTOs are test-covered. However, in the specific controller boundary handlers reviewed, incoming boundary values (`req.params.id`, `req.query.transferId`) are read and used without an explicit, enforce-reject schema check visible in the handler code. The codebase may validate inputs via framework/decorator plumbing, but that wiring was not verified in the slices inspected here.

• high

  Verify and document where boundary input validation is enforced for `@Param`, `@Query`, and `@Body` decorated arguments. If enforcement happens outside the handler (e.g., in the controller/route execution pipeline), add/inspect that code to confirm invalid params are rejected before any DB/token usage.

  • packages/cli/src/controllers/users.controller.ts:127-170 — Handler reads `req.params.id` and uses it directly; enforcement is not visible here.
• high

  Add explicit schema validation (e.g., Zod `safeParse`/`parse`) for path/query parameters used in security-sensitive flows (password reset link generation, invite token generation, user deletion transfer). Reject invalid types/constraints early.

  • packages/cli/src/controllers/users.controller.ts:127-170 — Password reset link generation uses `req.params.id` directly.
  • packages/cli/src/controllers/users.controller.ts:174-209 — Invite link generation uses `req.params.id` directly.
  • packages/cli/src/controllers/users.controller.ts:222-305 — User deletion uses `req.query.transferId` directly.
• med

  Ensure DTO validation failures produce consistent 400 responses (and do not leak internals). Add integration tests that send malformed `id`/`transferId` values and assert rejection.

  • packages/@n8n/api-types/src/dto/user/__tests__/user-self-settings-update-request.dto.test.ts:1-133 — DTO-level rejection behavior exists in unit tests; add similar tests for controller endpoints/parameter boundaries.

The codebase has some good injection-safe data access patterns (notably TypeORM QueryBuilder with bound parameters in `FolderService.getFolderTree`). However, there are also clear injection-safety deviations: database migrations build SQL strings using template-literal interpolation and pass them to `queryRunner.query(...)` (string-built SQL), which does not satisfy the primitive’s requirement of avoiding string concatenation for query construction.

• high

  Eliminate template-literal SQL construction in migrations where possible. Instead, use the ORM’s identifier-safe facilities for dynamic identifiers (e.g., properly escaped identifiers) and parameter binding for variable data; avoid passing fully string-built SQL with interpolated fragments into `queryRunner.query(...)`.

  • packages/@n8n/db/src/migrations/postgresdb/1690000000000-MigrateIntegerKeysToString.ts:6-38 — Multiple `queryRunner.query( `...${tablePrefix}...` );` statements build SQL by interpolating `tablePrefix` directly into raw SQL strings.
  • packages/@n8n/db/src/migrations/sqlite/1690000000002-MigrateIntegerKeysToString.ts:14-45 — Migration creates tables and inserts using template literals that interpolate `tablePrefix` into SQL passed to `queryRunner.query(...)`.
• med

  For complex QueryBuilder conditions that embed subqueries (e.g., `folder.id IN ${subQuery}`), verify (and add tests) that all user-controlled values are represented only via bound parameters from QueryBuilder, not via direct string interpolation of runtime values.

  • packages/cli/src/services/folder.service.ts:105-141 — Recursive CTE + `folder.id IN ${subQuery}` should be confirmed to carry placeholders/params safely; currently `folderId` is bound via `.where(... :folderId ...)` and `.setParameters(...)`.

This codebase includes an end-to-end data redaction concept and enforces it in key sensitive data flow paths. Execution node output and flatted runData pushed to the frontend are redacted via a proxy redaction service with fail-closed behavior (skip/empty on redaction failure). Separately, the MCP browser redaction layer detects secret/sensitive patterns and applies redactions to both text and structured tool results using marker-based replacement.

• med

  Verify that the @Redactable() decorator on log-streaming/audit event relay methods is actually wired to anonymize/redact payload fields (e.g., user/email/name) for every enabled path (including when redaction policy/enforcement flags differ). Add tests that assert sensitive fields are masked in emitted audit events.

  • packages/cli/src/events/relays/log-streaming.event-relay.ts:120-205 — Audit payloads include ...user and are decorated with @Redactable(), but enforcement details are not shown in the snippets read; confirm anonymization/redaction occurs on every path.

No clear implementation of the primitive “access logging on protected routes” was found. While the codebase has an audit-event concept (with payload fields like userId/userEmail) and protected-route scope checks exist, the inspected middleware/bootstrapping code does not emit a request access/audit log for authenticated/protected route accesses with a unique actor identifier on every path.

• high

  Add a centralized request middleware on the server (or public-api router) that runs for all authenticated/protected endpoints and emits an access/audit log entry for each request, including a unique actor identifier (e.g., req.user.id or API key subject) and request context (route, method, outcome).

  • packages/cli/src/abstract-server.ts:140-220 — Server initialization is the correct placement for a cross-cutting access-logging middleware, but no such middleware is present in the inspected bootstrap logic.
• high

  Ensure access/audit logging is emitted on every protected-route authorization outcome (authorized, forbidden/404 for scope failures, auth failures), not only in select business logic. Wire the logging at the same layer as scope enforcement (or as a finalizer after it).

  • packages/cli/src/public-api/v1/shared/middlewares/global.middleware.ts:1-60 — This scope middleware enforces access decisions but currently performs no audit/access logging.
• med

  Reuse the existing audit-event infrastructure (EventMessageAudit payload fields like userId/userEmail) to standardize actor attribution, and add tests that assert an audit/access entry is produced for representative protected routes.

  • packages/cli/src/eventbus/event-message-classes/event-message-audit.ts:1-72 — Audit payload supports actor fields, which can be leveraged once middleware emission is wired.

The codebase contains an implemented retention-and-deletion control for execution data: a leader-only scheduled pruning service performs rolling soft-deletion (marking eligible executions with deletedAt) and periodic hard deletion that removes execution entities plus associated binary/FS execution bundles. It also has retention mechanisms for workflow history (pruning older history while preserving current/active versions), with additional scheduled compaction/trimming for auto-saved histories.

• high

  Add/confirm an explicit “secure deletion” policy statement for how binary/DB data are disposed (e.g., whether DB hard deletes are acceptable as “secure disposal”, and what “cryptographic wipe” means in this system). If cryptographic wipe is required by your compliance standard, document and implement field/volume crypto handling for execution_data/fs bundles beyond simple rm/delete.

  • packages/cli/src/executions/execution-data/fs-store.ts:1-144 — Current implementation deletes files via fs.rm(recursive, force); there is no cryptographic wipe step.
  • packages/cli/src/executions/execution-persistence.ts:240-430 — HardDelete deletes database rows and binary data via binaryDataService/fsStore.delete; no cryptographic wipe is present in this layer.
• med

  Verify backup/derived-data coverage for execution retention: document that pruning reaches all relevant storage backends (db rows, execution_data, filesystem bundles, and any configured external storage). Add tests that run pruning against each configured storage mode.

  • packages/cli/src/services/pruning/executions-pruning.service.ts:1-163 — Wires pruning schedules, but does not document backup/derived-data reach.
  • packages/cli/src/executions/execution-persistence.ts:240-430 — Hard deletion is implemented for db + fs paths; external storage coverage depends on other store implementations not shown here.
• low

  Create or link a single retention-policy document enumerating each dataset (executions, execution_data binaries, workflow history), their retention windows, soft vs hard delete stages, and safety exclusions; reference the enforcing pruning services/repositories for auditability.

  • packages/@n8n/db/src/repositories/execution.repository.ts:560-640 — Retention windows are encoded in code via globalConfig.executions.pruneDataMaxAge/pruneDataMaxCount and pruneDataHardDeleteBuffer.
  • packages/@n8n/db/src/repositories/workflow-history.repository.ts:1-122 — Retention is encoded for workflow history via date-based deletes with active/current exclusions.

Secure defaults/hardening is partially implemented: the server constructs a `helmet`-based security headers middleware (CSP, X-Frame-Options, and conditional HSTS) and applies it when serving the UI `index.html` via history-API fallback. However, the hardening middleware is not clearly applied globally to all HTTP paths (notably non-UI/API responses), and HSTS is conditional on n8n directly terminating TLS, which may leave an unenforced gap when TLS is terminated by a reverse proxy.

• high

  Apply the `helmet`/security-headers middleware broadly (e.g., `this.app.use(securityHeadersMiddleware)` or equivalent) for all relevant routes/responses, not only inside the history-API handler.

  • packages/cli/src/server.ts:392-456 — Hardened middleware is only executed inside `historyApiHandler` before sending `index.html` (not applied to general API/non-UI responses in the shown code).
• med

  Ensure HSTS expectations are met across deployments behind a reverse proxy: document and/or automatically support `X-Forwarded-Proto`/proxy-aware HSTS enabling so that HTTPS is consistently enforced on every hop.

  • packages/cli/src/server.ts:414-426 — HSTS is enabled only when n8n handles TLS directly (`globalConfig.protocol === 'https'` and `sslKey`/`sslCert` present), otherwise `strictTransportSecurity: false`.
• low

  Verify debug/verbose error exposure is disabled in production for all environments where `inProduction` is true (e.g., ensure error handlers and logging don’t return stack traces to clients).

  • packages/cli/src/server.ts:1-120 — This file imports `inDevelopment`/`inProduction`, but the shown hardening implementation focuses on `helmet`; a dedicated production error/debug guard was not verified in the code slices reviewed.

A dedicated “audit event” mechanism exists in the form of `EventMessageAudit` + `MessageEventBus.sendAuditEvent`, which persists structured audit messages to a dedicated event-bus log writer (JSON lines). However, the implementation quality for a “dedicated audit event store” is weak for governance needs: the persistence layer clearly rotates/removes log files and provides no visible immutability/tamper-evidence or integrity verification, and the code evidence reviewed does not demonstrate a tenant-scoped, queryable/exportable audit trail interface with actor/tenant/action/resource/context/timestamp semantics.

• high

  Confirm and document the audit-event schema requirements (actor, tenant/org, action, resource type+id, context, timestamp) are actually populated on `EventMessageAudit.payload` at emission time (not just the interface exists). Then enforce missing fields at compile/runtime (e.g., validators).

  • packages/cli/src/eventbus/event-message-classes/event-message-audit.ts:1-72 — Shows the available structured fields, but does not prove they are always populated (no evidence of tenant/action/resource/timestamp coverage from the inspected slices).
• high

  Strengthen audit-store immutability and tamper-evidence: replace/augment the rotating file-log approach with an append-only store that prevents in-place modification and supports integrity validation (e.g., hash-chaining/signing per record). Ensure administrative deletion/retention changes cannot silently rewrite history.

  • packages/cli/src/eventbus/message-event-bus-writer/message-event-bus-log-writer-worker.ts:1-145 — Writes via append but also rotates and deletes old logs (`rmSync`), with no visible hash-chain/signature or integrity verification.
• med

  Provide tenant-scoped audit read and export endpoints specifically for the audit event store (with pagination and verifiable export formats). The current public audit handler is for generating security audit reports, not for querying the audit event records.

  • packages/cli/src/public-api/v1/handlers/audit/audit.handler.ts:1-28 — Endpoint shown is `generateAudit` returning a report from `SecurityAuditService`, not an interface to the persisted audit-event store.

The codebase does implement an append-only style event log writer for audit/event messages (JSON lines appended to `.log` files). However, the same component deletes old logs (`rmSync`) and rotates them via renaming, and there is no evidence in code of integrity validation (e.g., hash chaining or signatures) that would make tampering detectable across records/files. Overall, the append-only aspect exists, but the tamper-evidence governance/evidence-chain requirements are not met.

• high

  Implement tamper-evidence for the event/audit evidence store: compute a per-record integrity link (e.g., hash-chain using the previous record hash, or Merkle tree, or signed records with an append-only verifier) and persist the integrity metadata alongside each record so that any alteration breaks validation for all subsequent records.

  • packages/cli/src/eventbus/message-event-bus-writer/message-event-bus-log-writer-worker.ts:90-100 — Current behavior appends raw JSON lines; no integrity metadata/hash-chain is shown around the append point.
• high

  Replace/augment destructive retention with audited, recoverable archival semantics for audit evidence (restrict deletion; ensure archival copies are immutable; require integrity validation before purging). Remove or tightly control `rmSync`-based evidence deletion for audit evidence.

  • packages/cli/src/eventbus/message-event-bus-writer/message-event-bus-log-writer-worker.ts:62-70 — Evidence files are deleted via `rmSync` in cleanup logic.
• med

  Ensure the tamper-evidence chain spans rotations across files: rotation should carry forward the last-record hash (or equivalent) into the next log file, so verifiers can validate continuity across renames/archives.

  • packages/cli/src/eventbus/message-event-bus-writer/message-event-bus-log-writer-worker.ts:35-56 — Rotation is implemented by renaming and creating new `.log` files; no cross-file chain continuity is shown.
• med

  Add a public/internal audit-verification interface that can validate the integrity chain over a requested time range and export verifiable evidence bundles (record hashes + chain tip + verifier output).

  • packages/cli/src/eventbus/message-event-bus/message-event-bus.ts:121-140 — The event bus writes and confirms delivery, but the evidence verification/export mechanism for tamper-evidence is not shown in these write-path excerpts.

This codebase implements a dedicated audit-event emission pipeline using `MessageEventBus.sendAuditEvent()` and persists audit messages via the event-bus log writer. Audit events are emitted for sensitive auth and many workflow/user/role-governance events in `log-streaming.event-relay.ts`. However, at least one sensitive export path (`/n8n-packages/export` and its service export logic) does not show evidence of emitting an audit event in the controller/service layers reviewed, which creates a likely audit-coverage gap for data exports.

• high

  Add/ensure an audit event is emitted for the workflows/credentials export endpoint (`/n8n-packages/export`) including actor identity and the set of exported workflow IDs (and possibly whether credentials were included). Ensure the audit event is emitted at the point where export contents are determined (service), not only at transport/controller level.

  • packages/cli/src/modules/n8n-packages/n8n-packages.controller.ts:10-29 — Defines the sensitive export HTTP endpoint returning a downloadable archive; no audit emission is present in this wiring slice.
  • packages/cli/src/modules/n8n-packages/n8n-packages.service.ts:34-65 — Implements the actual export logic (packaging manifest and exported workflows/credentials) without any shown audit-event emission in the reviewed slice.
• med

  Verify that permission/role changes and other sensitive permission-adjacent actions are fully covered by audit events (beyond token-exchange/role-mapping). If permission/role management exists elsewhere, ensure it routes through the same audit emission mechanism (`sendAuditEvent`) and is included in the log-streaming relay/listeners model.

  • packages/cli/src/events/relays/log-streaming.event-relay.ts:1040-1185 — Shows some role-governance events are audited (role mapping rules and token exchange role updates), but broader permission-change coverage needs confirmation across all role/permission management surfaces.
• low

  Document how timestamps/order are ensured across hosts for audit reconstruction (event log writer + delivery retry) and confirm audit timeline integrity for customer/auditor consumption.

  • packages/cli/src/eventbus/message-event-bus/message-event-bus.ts:277-340 — Startup recovery logic drains unsent events and cycles log writing, which supports timeline completeness but should be explicitly validated/documented for the audit use-case.

The repository includes a public API endpoint for `generateAudit` that produces a security audit report (risk categories over workflows). However, there is no queryable, provable audit *access* for a tenant-scoped audit trail with pagination and an exportable, independently verifiable evidence trail (including integrity/cryptographic assurance). Therefore this primitive is absent in the required form.

• high

  Implement (or wire in) a dedicated, append-only, structured audit event store and expose it via a tenant-scoped, paginated public API for auditors/customers/support, plus a separate export endpoint that outputs verifiable evidence (identity assertion, policy/policy-version state, and cryptographic integrity such as hash-chaining/signatures).

  • packages/cli/src/public-api/v1/handlers/audit/audit.handler.ts:1-28 — Current endpoint is `generateAudit` only; no audit-read query/export interface for an audit trail.
• med

  Ensure the implementation logs and persists the required audit context fields (actor identity, tenant/project scope, event type, resource identifiers, policy state/version, timestamp) into the dedicated evidence store at the time of each sensitive action; do not rely on generated reports or debug/log streaming.

  • packages/cli/src/security-audit/security-audit.service.ts:1-75 — Current service generates reports from workflow state and risk reporters; it does not implement persistent audit trail evidence for independent verification.

No dedicated “audit retention & separation of duties” primitive is implemented or wired in this codebase. The code contains a security-audit *report generator* (CLI + public API handler) that computes findings from workflows, but there is no persisted audit/event evidence store with an enforced retention window, restricted tamper controls, or audited log deletion/purging.

• high

  If n8n is expected to provide compliance-grade audit trails, introduce a dedicated structured audit/event store (separate from app logs) and implement: (1) retention window configuration, (2) immutable/append-only write semantics, (3) separation of duties so system admins cannot shorten retention or modify prior audit records, and (4) retention purge jobs whose execution and deletions are themselves audited.

  • packages/cli/src/security-audit/security-audit.service.ts:1-75 — Current implementation only produces computed reports from workflows; it does not persist audit evidence or enforce retention controls.
  • packages/cli/src/public-api/v1/handlers/audit/audit.handler.ts:1-28 — The exposed endpoint returns the computed report; no audit trail read/export or retention/purge mechanism is present here.
• med

  Add verifiable operational artifacts: a retention/purge job definition (config + scheduler), audit-store mutation safeguards (no UPDATE/DELETE on evidence rows except via controlled purge), and an audited record of purge actions (who/what/when/how many).

  • packages/cli/src/security-audit/security-audit.service.ts:1-75 — No purge/retention enforcement logic exists in the security-audit module; evidence retention requirements would need new code/config.

This codebase does not show a data-residency / region-pinning primitive: there is no evidence of a tenant-level region attribute driving in-region data/compute placement or region-keyed routing. Where 'region' appears, it is used for unrelated concepts (e.g., provider userLocation metadata) or generic request routing, not residency enforcement.

• high

  If n8n is deployed as a multi-tenant service with any EU/region residency obligations, introduce an explicit tenant data residency model (tenant.region) plus region-keyed routing so workflow execution and all persistence/sync/side-effects are constrained to the tenant’s chosen region.

  • packages/core/src/execution-engine/routing-node.ts:1-220 — Current routing logic shown here does not incorporate any tenant-region placement decision, so residency pinning would not be enforceable at this layer without adding region-aware selection and sink constraints.
• med

  Audit and document every data sink (primary DB, caches, queues/event bus, backups/snapshots, analytics/export pipelines, and third-party integrations) and enforce region pinning across them; the primitive must guarantee no cross-region 'shadow data' escapes.

  • packages/@n8n/agents/src/sdk/provider-tools.ts:1-138 — Existing 'region' handling is not residency-related; use this as a cue that 'region' strings alone do not represent residency enforcement—explicit sink-level controls are needed.

I did not find an implementation of “No cross-region leakage” that enforces residency for all data sinks (including derived/backup/analytics/exports/relays). The pubsub scaling components route via Redis prefixes/hostId without any region-scoped enforcement, and the export service writes out exported artifacts without any visible region pinning/blocking.

• high

  Introduce and enforce tenant/organization region scoping across all data sinks that can propagate or materialize data outside the primary store (including pubsub/relay paths and export outputs). Ensure routing/placement is keyed by tenant region and that cross-region destinations are blocked by policy checks close to the sink (not only at the primary DB).

  • packages/cli/src/scaling/pubsub/publisher.service.ts:1-146 — Publisher builds channel names from Redis prefix only; no region scoping present for propagation sink.
  • packages/cli/src/scaling/pubsub/subscriber.service.ts:1-195 — Subscriber validates sender/targets/hostId, but no region-aware checks exist for residency enforcement.
• high

  Add explicit residency enforcement to export flows: validate tenant region vs. configured export destination region (or storage bucket/endpoint region), and block or reroute exports that would place data out-of-region.

  • packages/cli/src/services/export.service.ts:1-200 — Export logic writes encrypted artifacts to an output directory without any region/policy checks visible in this implementation slice.
• med

  Audit secondary sinks comprehensively (backups/snapshots/replication/analytics pipelines and any third-party syncs). For each sink, add region pinning plus an automated test that attempts an out-of-region sink configuration and verifies the sync/export is blocked.

  • packages/cli/src/scaling/pubsub/publisher.service.ts:1-146 — Demonstrates a concrete class of propagation sinks; similar audits are needed for backup/analytics/export/sync code paths.

No dedicated data-subject rights (export & erase) primitive was found. While the codebase contains (a) an entity-export service that appears to export from all tables and (b) a user deletion endpoint that deletes user-related primary records, neither is demonstrated as a GDPR/CCPA-style DS request mechanism that exports all data for a specific subject and performs auditable erasure with required cascade coverage (backups/derived stores).

• high

  Implement a dedicated DS rights module with public API endpoints for (1) export-by-subject and (2) erase-by-subject, including DS request identity verification, tenant scoping, and response evidence artifacts.

  • packages/cli/src/services/export.service.ts:200-360 — Current exportEntities is bulk/all-table oriented; it should be replaced or extended with per-subject export that enumerates and exports all subject-linked records.
• high

  Add an erase handler that performs comprehensive cascade deletion beyond the primary rows, explicitly covering backups and derived stores (and document/verify backup-safe strategy), then make the erase action itself auditable in a structured, immutable audit store.

  • packages/cli/src/controllers/users.controller.ts:200-360 — Deletion currently removes AuthIdentity/Project/User and emits an event, but there is no demonstrated DS-rights erase job/cascade coverage to backups and derived stores.
• med

  Add explicit wiring from DS request endpoints to underlying data deletion/export services so that the DS primitive is not merely “admin actions,” but a governed workflow with auditable checkpoints.

  • packages/cli/src/public-api/v1/handlers/audit/audit.handler.ts:1-28 — Public API “audit” handler exists for security reporting, not DS rights; DS endpoints should be added in the same routing layer.

The codebase includes a central “encryption key manager” with endpoints to list keys and rotate/create a new active data-encryption key. However, it does not present evidence of the primitive’s core requirement: customer-controlled, per-tenant/customer-managed keys with customer-driven import, scheduled rotation, and explicit revoke (crypto-shred) semantics. The visible API appears instance/global and permissioned for admins, not tenants supplying their own keys.

• high

  Add a tenant-scoped BYOK interface: implement per-tenant key reference + customer-provided key import (or KMS reference import) and persist it against tenant scope, not globally. Evidence target: current controller is global and lacks import/revoke flows.

  • packages/cli/src/modules/encryption-key-manager/encryption-key.controller.ts:1-59 — Controller exposes only list/create with GlobalScope('encryptionKey:manage'); no tenant scoping, import, or revoke endpoint is shown.
• high

  Implement explicit revoke semantics for crypto-shred: expose an API that transitions a tenant key to inactive/revoked in a way that ensures derived/encrypted-at-rest data becomes unreadable (or triggers a designed key-eraser workflow). Wire it end-to-end (API -> service -> repository -> storage).

  • packages/cli/src/modules/encryption-key-manager/key-manager.service.ts:1-178 — markInactive exists but has a TODO guard and is not shown wired to any customer-facing revoke path.
• med

  Provide scheduled rotation and prove enforcement: add rotation scheduling per tenant/customer (or policy-driven rotation) and persist rotation/activation history with tenant scoping; ensure only the tenant/customer can rotate/revoke within their scope.

  • packages/cli/src/modules/encryption-key-manager/key-manager.service.ts:1-178 — Rotation exists (rotateKey/addKey/insertAsActive), but no evidence of scheduled per-tenant rotation policy or tenant-scoped authorization.

The codebase provides an authenticated 'third-party licenses' endpoint and frontend client for retrieving a THIRD_PARTY_LICENSES.md file, but there is no in-repo, versioned sub-processor/data-flow inventory (or an equivalent API) that would allow verifiable mapping of which third parties touch data. Therefore, this primitive is absent.

• high

  Add a versioned, in-repo sub-processor/data-flow inventory artifact (e.g., SUBPROCESSORS.md or a machine-readable JSON) that is maintained alongside node/vendor changes, and that lists each third party that receives data (for each relevant data-flow: model/provider nodes, analytics, telemetry, etc.). Ensure entries have version/history and an explicit 'last reviewed' timestamp.

  • packages/cli/src/controllers/third-party-licenses.controller.ts:1-26 — Current transparency surface is licensing-based and does not provide a data-flow/sub-processor inventory.
• high

  Implement/extend an API endpoint to serve the sub-processor inventory with an auditable, verifiable backing file (and ensure the file exists in-repo). Reuse the authentication model but make the content explicitly about sub-processors and data flows (not licenses).

  • packages/cli/src/controllers/third-party-licenses.controller.ts:1-26 — There is already an endpoint pattern for transparency content retrieval; it should be adapted to serve the actual sub-processor inventory with an existing, versioned backing file.
• med

  Cross-check the declared inventory against actual third-party SDK usage in code (e.g., vendor node transports). Add a lightweight CI check to prevent undocumented third-party recipients from being added without updating the inventory.

  • packages/cli/src/controllers/third-party-licenses.controller.ts:1-26 — No mechanism is visible here for tying third-party usage in the codebase to a declared, versioned sub-processor inventory.

The primitive is present: there are at least two clear instances where expensive work is repeated inside loops. One is repeated lodash `get(...)` path resolution in a hot sort/comparator path; another is per-node `await fetch(...)` in a loop that can cause many sequential network calls. I did not find any cases where the expensive call/work is correctly hoisted/batched/memoized for these specific should-be sites.

• high

  In `Sort.node.ts`, precompute per-item derived values for each `sortFields` entry (including optional lowercasing) once before validation/sorting, and have the comparator read those cached values rather than calling `get(...)` repeatedly during comparator invocations.

  • packages/nodes-base/nodes/Transform/Sort/Sort.node.ts:160-240 — Shows nested loops and comparator path that repeatedly calls `get(a.json, field.name)` / `get(b.json, field.name)` in the hot path.
• high

  In `executions.utils.ts`, refactor the per-node `fetch` inside the loop to avoid N sequential calls: (a) collect unique `testUrl`s and fetch them in parallel with a bounded concurrency, and/or (b) avoid fetching at all when can be decided from already-available state, and/or (c) memoize results by `testUrl` within the function call.

  • packages/frontend/editor-ui/src/features/execution/executions/executions.utils.ts:130-190 — Shows `for (const node of nodes)` performing `await fetch(testUrl, ...)` for each applicable node.

Bounded interfaces are implemented partially via the `ListProjectsQueryDto` pagination contract (with `take` capped to `MAX_ITEMS_PER_PAGE`). However, the code intentionally supports unbounded collection retrieval when callers omit pagination (`take` defaults to `undefined` and the controller returns a bare array). Client code also calls `GET /projects` without pagination (`getAllProjects()`), creating genuine unbounded collection surfaces—so the primitive is present but not correctly enforced end-to-end.

• high

  Remove/disable the backward-compat path that allows omitting `take` to return all projects. Make `take` required or apply a safe default server-side limit when `take` is absent (and always return an envelope with `count`/`data` if that’s the desired bounded contract).

  • packages/@n8n/api-types/src/dto/project/list-projects-query.dto.ts:1-50 — The DTO explicitly defaults `take` to `undefined` (no limit) for backward compatibility—this is the root cause of unbounded behavior.
  • packages/cli/src/controllers/project.controller.ts:1-80 — Controller returns a bare array when pagination params are omitted, enabling unbounded responses to clients.
• high

  Fix frontend/API wrapper(s) that call collection endpoints without pagination parameters (e.g., `getAllProjects`) by requiring `take/skip` (or at least sending a default `take`) from the client.

  • packages/frontend/editor-ui/src/features/collaboration/projects/projects.api.ts:1-25 — `getAllProjects()` performs `makeRestApiRequest(context, 'GET', '/projects')` with no `take/skip`, which will trigger unbounded server behavior if the server still supports it.
• med

  Enforce bounded behavior consistently at the repository/query layer by ensuring `applyPagination` always sets a `take` (server-side) even if callers omit it.

  • packages/@n8n/db/src/repositories/project.repository.ts:1-224 — Pagination currently only applies `take` when `options.take !== undefined`; if `take` is omitted, the query is unbounded. Aligning repository behavior with bounded-interfaces would harden the system against other call sites.

The codebase has a strong and correct caching/memoization implementation: (1) a per-instance memoized DB read for instance version history, and (2) a centralized cache abstraction (`CacheService`) built on `cache-manager` with Redis and memory backends, including TTL and hit/miss/refresh behavior.

• high

  Audit other hot-path deterministic functions for repeated expensive calls and route them through `CacheService.get/getHash/getHashValue` with stable cache keys and explicit invalidation/TTL strategy (the repo already has the infrastructure; the main risk is missing keying/invalidation at call sites).

  • packages/cli/src/services/cache/cache.service.ts:89-132 — Central caching behavior exists; expanding its usage is the most direct path to improve memoization coverage.
• med

  For memoized values like `_cache` in `InstanceVersionHistoryService`, confirm invalidation correctness under leader changes and any external updates to the underlying repository table (current logic memoizes until re-init).

  • packages/cli/src/modules/instance-version-history/instance-version-history.service.ts:20-45 — Memoization depends on `_cache` and leader-only initialization; invalidation is implicit via `init()` retries and leader behavior.

The codebase shows an intent to use Oracle pooling (via `PooledOracleEmbeddings` borrowing connections from a pool). However, the pool initialization path appears to run on each embeddings/list call (`configureOracleDB.call(...)` is invoked inside per-call functions), so the expensive pooling handle is not clearly created once and reused across the component lifetime.

• high

  Cache the Oracle `oracledb.Pool` so `configureOracleDB.call(...)` is executed once per credential set (or per node instance) and reused. For example, memoize `getPool` inside the node instance (keyed by credentials/provider/model) so `withConnection` only calls `pool.getConnection()`.

  • packages/@n8n/nodes-langchain/nodes/embeddings/EmbeddingsOracleDB/EmbeddingsOracleDb.node.ts:47-70 — Pool is fetched inside `withConnection` via `const pool = await this.getPool();`.
  • packages/@n8n/nodes-langchain/nodes/embeddings/EmbeddingsOracleDB/EmbeddingsOracleDb.node.ts:133-152 — `getPool` is implemented as `await configureOracleDB.call(this, credentials...)`, which would re-run during each `withConnection` invocation.
• high

  For `searchModels`, avoid calling `configureOracleDB` (pool creation/config) on every `searchModels` invocation. Instead, obtain a shared cached pool (same approach as above) and only open/close connections per request.

  • packages/@n8n/nodes-langchain/nodes/embeddings/EmbeddingsOracleDB/listModels.ts:13-28 — `configureOracleDB.call(this, ...)` is executed at the start of every `searchModels` call, followed by `pool.getConnection()` and `connection.close()`.

The codebase uses a Bull-backed queue to offload workflow execution work from the main/initiating path to worker consumers. The decision to enqueue vs. run inline is made in `WorkflowRunner.run`, and the actual heavy processing happens inside Bull's `queue.process` handler in `ScalingService.setupWorker`.

• high

  Search for any remaining queueing decision points or execution paths that still call `runMainProcess(...)` for queue mode; ensure workflow execution (and other potentially slow/failable steps) are consistently routed through `enqueueExecution` so the hot path stays free.

  • packages/cli/src/workflow-runner.ts:300-360 — This file is the central offload switch (queue vs inline). Any alternate entrypoints should follow the same pattern.
• med

  Audit `enqueueExecution(...)` / job handler logic for idempotency and retry semantics (e.g., ensuring job processing is safe to retry after failures). The offload exists, but correctness depends on retry safety.

  • packages/cli/src/workflow-runner.ts:420-520 — This is where jobs are constructed/enqueued; retry/idempotency expectations should align with the worker-side processing.
  • packages/cli/src/scaling/scaling.service.ts:70-120 — Worker-side handler catches errors and reports; validate that the underlying `jobProcessor.processJob` is retry-safe.

The codebase does contain a correct lookup data structure implementation (an LRU cache built on `Map`). However, at least one hot per-record spot (pairwise output generation) repeatedly uses linear `Array.find` over the same collection (`r.feedback`) rather than building a lookup index for O(1) metric access, so the anti-pattern appears in that location.

• high

  In `writeOutputs`, build a per-record lookup (e.g., `const feedbackByMetric = new Map(r.feedback.map(f => [f.metric, f.score]))`) once per record, then replace the three `r.feedback.find(...)` calls with O(1) `feedbackByMetric.get(metric)` reads.

  • packages/@n8n/instance-ai/evaluations/cli/pairwise.ts:460-507 — Shows the repeated linear scans: `const find = (m) => r.feedback.find(...);` followed by `find('pairwise_primary')`, `find('pairwise_diagnostic')`, and `find('pairwise_judges_passed')` for every record.
• med

  If `feedback` is stable and large across the entire run, consider pre-indexing once at ingestion time (rather than per output pass) to avoid repeated O(n) searches each time metrics are emitted.

  • packages/@n8n/instance-ai/evaluations/cli/pairwise.ts:460-507 — Metric extraction via repeated `find` is performed during CSV row generation; moving to a precomputed index would remove repeated linear scans.

The codebase does contain a well-implemented batching pattern at the I/O boundary for bulk workflow setting updates (chunked DB reads/updates in `bulkSetAvailableInMCP`). However, at least two node execution paths (Rocketchat and Brandfetch) still perform outbound API calls inside per-item loops, which are exactly the round-trip anti-patterns for this primitive (and were not found to use a batching strategy at those call sites).

• high

  For Rocketchat node execution, avoid calling `rocketchatApiRequest.call(...)` once per item. Implement batching if the Rocketchat API supports multi-message endpoints, or restructure to send fewer grouped requests (e.g., collect messages per channel/resource and call a bulk endpoint, or add concurrency controls + explicit chunk size).

  • packages/nodes-base/nodes/Rocketchat/Rocketchat.node.ts:372-480 — Per-item loop constructs `body` and executes `rocketchatApiRequest.call(... '/chat', 'POST', 'postMessage', body)` for each `i`.
• high

  For Brandfetch node execution, avoid `brandfetchApiRequest.call(...)` once per item index `i`. If Brandfetch supports bulk logo/color/company retrieval, introduce a batched fetch strategy (or group domains and call a bulk endpoint); otherwise implement bounded chunking to cap round-trips and avoid unbounded linear growth.

  • packages/nodes-base/nodes/Brandfetch/Brandfetch.node.ts:150-210 — Inside `for (let i = 0; i < length; i++)`, the code performs `await brandfetchApiRequest.call(this, 'GET', `/brands/${domain}`)` per item.
• med

  Add/extend a shared batching helper (at the I/O boundary) used by nodes that call external services, to standardize chunk sizing and to prevent accidental per-item request fan-out.

  • packages/cli/src/modules/mcp/mcp.settings.service.ts:80-170 — A working reference exists: `bulkSetAvailableInMCP` uses `BULK_CHUNK_SIZE` + `In(chunk)` + transaction-per-chunk, which can be generalized into a reusable batching utility pattern.

The primitive exists and is well-implemented in `DbLockService`, which synchronizes shared in-process lock state using a FIFO queue plus ownership tokens, and relies on Postgres transaction-scoped advisory locks for cross-process correctness. Additional synchronization is applied at key mutation boundaries in the workflow dependency repository (row-level locking) and in the scoped task runner (promise-chain serialization per scope).

• high

  Review `ScopedMemoryTaskRunner` shared mutable arrays/maps for logical invariants under concurrency (e.g., `capturedErrors` max-size enforcement and `inFlightTasks.delete(info.id)` timing relative to overlapping `runTask` calls). If invariants matter strictly, consider encapsulating these mutations behind per-scope serialization or an internal single-flight queue.

  • packages/@n8n/agents/src/runtime/scoped-memory-task-runner.ts:52-120 — Per-scope serialization is implemented, but other shared state mutations (e.g., error capture and in-flight bookkeeping) occur within `runTask` across async interleavings.
• med

  Confirm `WorkflowDependencyRepository.acquireLockAndCheckForExistingData` coverages: ensure every concurrent writer path for workflow dependency mutations uses the same locking strategy (especially if there are other methods performing inserts/updates without calling this helper).

  • packages/@n8n/db/src/repositories/workflow-dependency.repository.ts:102-156 — The helper applies `FOR UPDATE` + existence check for Postgres. If there are additional write paths, they may need to reuse the same synchronization boundary.
• low

  Add targeted comments/tests for the in-process mutex edge cases already handled (stale release, transfer-before-resolve ordering) to prevent future refactors from regressing microtask/window safety.

  • packages/@n8n/db/src/services/db-lock.service.ts:120-264 — The code explicitly documents and implements transfer ordering and token-based stale-release prevention; tests exist for `DbLockService` but additional regression assertions for queue transfer timing can harden correctness.

The codebase has a correct, explicit bounded-concurrency/backpressure primitive implemented as `ConcurrencyQueue` + `ConcurrencyControlService`. Capacity is enforced via a queue of awaiters: when the cap is hit, new work is blocked until capacity is released. This primitive is applied at the evaluation test-runner fan-out boundary, with additional abort-aware eviction/release handling to prevent capacity leaks.

• med

  Audit other fan-out-heavy execution paths to ensure they consistently use `ConcurrencyControlService.throttle/release` (or equivalent) rather than spawning unbounded per-item async work. If found, route those call sites through the concurrency control.

  • packages/cli/src/evaluation.ee/test-runner/test-runner.service.ee.ts:820-900 — Demonstrates the intended correct pattern at a major fan-out site (throttle + abort-aware remove/release). Use it as the model when checking other runners/iterators.

The primitive exists in `InstanceVersionHistoryService`: DB work (fetching all version entries) is deferred until first use and then cached for subsequent consumer methods, avoiding unnecessary repeated computation and data transfer.

• high

  Audit other modules that build potentially large result sets or expensive derived data (e.g., caches, computed selectors, “history”/“timeline” style queries) and ensure the fetch/compute is guarded behind a “first use” check like `_cache === null` (and that partial consumer methods don’t force full recomputation).

  • packages/cli/src/modules/instance-version-history/instance-version-history.service.ts:30-60 — Use this pattern as the target behavior: expensive repository work runs only on first demand via `getCache()`.

The codebase contains streaming implementations (notably SSE event writing and incremental processing of async stream chunks). However, the 'constant memory regardless of input size' primitive is violated in places where streams are converted into full strings (e.g., accumulating entire text from an agent stream) and where workflow code is fully inlined/assembled in memory (local import resolution).

• high

  Replace `collectNativeStreamText` with a bounded/streaming alternative: expose an `AsyncIterable`/stream of text deltas to the consumer, or cap/roll up content (e.g., limit retained text, store only recent tail, or persist incrementally to storage). Avoid `deltaText += ...` / `messageText += ...` over unbounded streams.

  • packages/@n8n/instance-ai/src/runtime/resumable-stream-executor.ts:86-137 — Full buffering into `string` via concatenation accumulators inside a stream read loop.
• high

  Change `resolveLocalImports` to avoid assembling the entire inlined bundle in memory. Instead, stream/emit chunks incrementally to the downstream builder (or write to a temp file / bounded buffer). If a single string is required by the API, enforce strict size limits and/or incremental truncation.

  • packages/@n8n/instance-ai/src/workflow-builder/extract-code.ts:47-143 — Reads imported files into `inlinedChunks` and then concatenates them all with `join`, requiring memory proportional to total inlined code.
• med

  Audit other stream-to-buffer conversions for the same issue pattern (look for functions that return `string`, `Buffer`, or `Array` after consuming an async/stream input). Prefer iterators/chunked outputs and bounded retention.

  • packages/@n8n/instance-ai/src/runtime/resumable-stream-executor.ts:86-137 — Concrete example of a stream being fully materialized into an unbounded `string`.

Timeouts support exists in this codebase (undici Agent/ProxyAgent timeouts via `proxyFetch`, and `AbortSignal.timeout()` in the n8n evaluation client). However, at least one critical unbounded boundary remains: `N8nClient.callWebhook()` calls `fetch()` directly with no timeout, and many higher-level `N8nClient` methods call the internal `fetch()` without passing `timeoutMs`, making the timeout facility dependent on callers.

• high

  Bound `N8nClient.callWebhook()` by passing an `AbortSignal`/timeout (e.g., extend `callWebhook` to accept `timeoutMs` and pass `signal: AbortSignal.timeout(timeoutMs)` into the `fetch()` call).

  • packages/@n8n/instance-ai/evaluations/clients/n8n-client.ts:360-410 — Direct `fetch(url, ...)` without any timeout/signal is an unbounded network call.
• high

  Ensure `N8nClient` REST calls always use a bounded timeout: either (a) give the internal `private fetch()` a default timeout when `options.timeoutMs` is omitted, or (b) make callers pass a timeout consistently (or enforce it via types).

  • packages/@n8n/instance-ai/evaluations/clients/n8n-client.ts:515-555 — Timeout is only attached when `options.timeoutMs` is truthy, so calls that omit it become unbounded.
  • packages/@n8n/instance-ai/evaluations/clients/n8n-client.ts:65-90 — Example: `login()` calls `this.fetch(...)` without `timeoutMs`, so the timeout binding is not applied.
• med

  Add a small internal helper for REST requests (single entry point) that requires a timeout parameter and centrally constructs the `AbortSignal`, reducing the chance that future methods forget to pass `timeoutMs`.

  • packages/@n8n/instance-ai/evaluations/clients/n8n-client.ts:515-555 — The internal `fetch()` method already supports timeout, but callers currently don’t consistently provide it.

The codebase contains a retry utility with deterministic backoff (linear/exponential, capped at 30s) but it does not implement jitter. Additionally, there is at least one concrete HTTP retry loop (fetchNodeTypesJsonWithRetry) that uses deterministic sleep between attempts and does not implement jitter or exponential backoff with a clearly defined capped budget. As a result, the primitive 'retry_backoff_jitter' is only partially present and is not correctly applied to the transient-failure retry sites found.

• high

  Upgrade `packages/@n8n/utils/src/retry.ts` to add jitter to the computed delay (e.g., full jitter or equal jitter) while preserving the existing capped exponential backoff budget. Ensure the delay computation is centralized and consistently used by call sites.

  • packages/@n8n/utils/src/retry.ts:1-52 — Backoff is implemented deterministically via interval * attempt or Math.pow(2, attempt-1) * interval (capped at 30s), with no randomization/jitter in the delay.
• high

  Refactor `fetchNodeTypesJsonWithRetry` to use the updated jitter-capable retry helper, and switch to an exponential backoff strategy with a capped maximum delay budget and jitter.

  • packages/frontend/@n8n/rest-api-client/src/api/nodeTypes.ts:1-46 — Retry loop exists: axios.get is re-attempted and the delay is `sleep(delay * attempt)`; no jitter and the strategy is not exponential backoff + jitter.

Idempotency mechanisms are present, notably (1) DB-level execution dedup via a unique `execution_entity.deduplicationKey` index and (2) single-flight dedup for background task spawning using `BackgroundTaskManager`’s `dedupeKey`. Additionally, workflow statistics writes are made idempotent via `ON CONFLICT ... DO UPDATE` upserts. However, the audit did not confirm idempotency behavior in all retryable execution-creation call paths (e.g., whether retries always supply the dedup key and correctly handle duplicate-insert errors) within the sampled failure/duplication wiring.

• high

  Verify end-to-end idempotency for execution creation: ensure every retryable code path that persists a new `ExecutionEntity` supplies the correct `deduplicationKey`, and that duplicate-insert errors are caught and converted into a safe 'already exists / skip' outcome (rather than re-running). Cross-check where `deduplicationKey` is set (Schedule Trigger) and where it is passed into `WorkflowExecutionService.runWorkflow` / execution persistence.

  • packages/@n8n/db/src/entities/execution-entity.ts:60-114 — Shows the intended idempotency contract (`deduplicationKey`) and that uniqueness is enforced by an index.
  • packages/@n8n/db/src/migrations/common/1778000000000-AddExecutionDeduplicationKey.ts:1-35 — Shows the unique index mechanism relied on for dedup under concurrent inserts; correctness depends on correct wiring at call sites.
• med

  For idempotent upserts with conflict handling, audit the error branch and concurrency comments: specifically the SQLite branch in `upsertWorkflowStatistics` uses a naive post-query approach for determining insert vs update. Ensure that retries still remain correct for the side effects (counter increments) and that the classification logic does not trigger any additional write.

  • packages/@n8n/db/src/repositories/workflow-statistics.repository.ts:1-138 — SQLite path explicitly notes concurrency limitations for insert/update detection and then re-queries; verify no further mutation is conditionally executed based on that classification.
• low

  Add/extend tests covering idempotency under retries for background tasks: validate that repeated spawn attempts with identical `dedupeKey` return the duplicate result and do not start an additional run even when the first attempt is still running.

  • packages/@n8n/instance-ai/src/runtime/background-task-manager.ts:70-140 — Dedup implementation exists in `findDuplicate` and should be validated with retry/concurrency-oriented tests.

A circuit breaker implementation exists (packages/cli/src/utils/circuit-breaker.ts) and it is applied correctly to the log streaming message destination: receiveFromEventBus is wrapped with circuitBreakerInstance.execute(...) so the system will fail-fast (OPEN) and probe in HALF_OPEN with concurrency limiting.

• high

  Audit other external dependency call sites (network/db/HTTP/event bus send paths) for missing circuit breaker wrapping. Concretely, search for direct calls to external send/request functions that lack circuit breaker protection and add CircuitBreaker.execute(...) around those unhappy-path boundaries similar to message-event-bus-destination.ee.ts.

  • packages/cli/src/modules/log-streaming.ee/destinations/message-event-bus-destination.ee.ts:61-105 — This is the confirmed correct circuit-breaker wrapping pattern; use it as the template when adding protection to additional downstream call sites.
• med

  Ensure callers that catch CircuitBreakerOpen either (a) treat it as a normal fast-fail and stop further retries, or (b) propagate context upstream without re-triggering new retries that would defeat fail-fast behavior.

  • packages/cli/src/utils/circuit-breaker.ts:220-294 — CircuitBreakerOpen is thrown immediately in OPEN state; correct reliability depends on not undoing this with additional retry layers elsewhere.

The codebase does implement graceful degradation/fallback behavior. Notably, webhook cache lookup failures fall back to DB lookups, Redis cache-manager skips cache failures for non-cacheable values, and Postgres connection setup supports a fallback handler for pool acquisition/connection setup. Overall quality is strong, with correct error-branch handling and explicit continuation on non-critical failures.

• high

  For the Postgres transport fallback path, verify that all fallback-related failure branches still return a usable connection (or a clearly-defined error) and do not allow the fallback itself to throw unhandled exceptions; if there are unguarded operations inside `fallBackHandler`, wrap them with context and ensure the caller can continue or fail predictably.

  • packages/nodes-base/nodes/Postgres/transport/index.ts:97-146 — Fallback logic is defined here and passed into `poolManager.getConnection`; validate error branches inside this fallback to ensure they cannot abort the primary operation unexpectedly.
• med

  Standardize fallback staleness/explicitness: where cache is used (e.g., webhook cache), consider returning/recording a flag or timestamp indicating that results came from DB after cache failure, so callers can treat the result as 'non-cached' or 'stale-by-definition'.

  • packages/cli/src/webhooks/webhook.service.ts:46-73 — Cache failures degrade to DB lookup, but the code does not explicitly annotate that the result is not cached.

Error handling & propagation is present and generally well-applied in the @n8n/agents runtime: delegation errors are captured and returned as structured failed tool output, and streaming runtime failures are caught with cleanup and client-facing error signaling. However, at least some fallible write/emit operations appear to use local suppression (e.g., swallowing writer-write rejections), which is acceptable only if intentionally non-critical; overall quality is good but not perfect.

• high

  Review stream-related error branches for any intentionally-swallowed failures (e.g., `writer.write(...).catch(() => {})`). Ensure that if the stream write failure is meaningful, it is either propagated to the stream termination path or at least logged/recorded—avoid silent loss of error context.

  • packages/@n8n/agents/src/runtime/agent-runtime.ts:1110-1185 — Stream background task error path is handled, but the surrounding event-chunk writer uses rejection suppression; confirm this never hides critical failures (and add logging/telemetry if it does).
• med

  Audit the helper `closeStreamWithError` call chain to ensure that any failures during cleanup (`cleanupRun`) or error writes (`writer.write`, `writer.close`) are also handled in a non-silent way, preserving the original error context.

  • packages/@n8n/agents/src/runtime/agent-runtime.ts:1180-1260 — This block is the centralized unhappy-path handler for stream runtime errors; confirm it does not allow exceptions to escape unhandled or to get dropped without context.
• low

  Standardize error stringification/representation across tool delegation and runtime streaming so upstream callers get consistent error shapes (e.g., message + original error string/metadata when available).

  • packages/@n8n/agents/src/runtime/delegate-sub-agent-tool.ts:280-413 — Delegation failure is surfaced as `{error: ...}` and lifecycle events include `error`; consider ensuring runtime stream failures use the same representation for easier correlation.

Deterministic resource cleanup is present in the codebase: when an episodic-memory task lock is acquired, the code releases it in a finally block so the lock is freed even if the task throws.

• med

  Extend this audit pattern to other resource acquisitions (e.g., file streams, network connections/clients, DB handles) by explicitly checking whether their corresponding release/close happens in finally/defer/with/RAII at each acquisition site.

  • packages/@n8n/agents/src/runtime/agent-runtime.ts:1630-1675 — This file demonstrates the correct pattern (acquire in try, work, release in finally). Use it as the template when reviewing other acquisition sites.

The codebase has some atomic/all-or-nothing mechanisms: frontend cache persistence uses real IndexedDB transactions, and a data-table create+CSV-import flow uses compensating rollback (delete the created table) when row insertion fails. However, at least one compound CSV import operation into an existing table lacks rollback on failure (no catch around insertRows), making partial writes observable and therefore a should-be atomicity site.

• high

  Add an error-handling/rollback strategy to `importCsvToExistingTable` so that row insertion into the existing table is all-or-nothing (preferably a DB transaction; if not feasible, implement compensating deletion of any rows inserted during the failed import, with safeguards to avoid deleting pre-existing rows).

  • packages/cli/src/modules/data-table/data-table.service.ts:109-160 — The method wraps work in `try { ... await this.insertRows(...) } finally { cleanupFile(...) }` but has no `catch` and performs no rollback/compensation for partially completed inserts.

Input/boundary validation is present in the codebase. In `get-node-parameter.tool.ts`, the tool’s `input: unknown` is validated with a Zod schema at the handler boundary, and Zod validation failures are handled explicitly by returning an error response. For this audit, only this concrete required should-be site was identified and it is correctly implemented.

• high

  Repeat this boundary-validation pattern across other tool/handler entry points that accept `unknown`/raw request/serialized workflow input: define a Zod (or equivalent) schema per boundary, call `schema.parse(...)` (or `safeParse`), and in the failure branch return a structured error response without performing any side effects or deep lookups.

  • packages/@n8n/ai-workflow-builder.ee/src/tools/get-node-parameter.tool.ts:31-140 — Demonstrates the correct approach to replicate: schema definition, `parse(input)`, and explicit `z.ZodError` handling that returns `createErrorResponse(...)`.

I did not find a clear, explicit failure-isolation/bulkheading implementation in the code I examined. For example, the Oracle embeddings node borrows connections from a shared pool for each call; while it does correctly close connections in a `finally` block, it does not appear to partition or cap resources per independent workload in a way that would prevent one workload from exhausting shared capacity.

• high

  Introduce bulkheading around the shared Oracle connection pool usage. Options include: (1) separate pools per workload class (e.g., per model / per node instance / per embedding operation type), (2) semaphore-based concurrency limits scoped to this node/subsystem, and/or (3) time-bounded acquisition with a fast-fail fallback when the limit is reached—so one embedding workload can’t starve others sharing the same pool capacity.

  • packages/@n8n/nodes-langchain/nodes/embeddings/EmbeddingsOracleDB/EmbeddingsOracleDb.node.ts:44-74 — Connection/pool acquisition occurs here via `await this.getPool()` and `pool.getConnection()`, using the same underlying pool for all embedding calls. Add partitioning/caps here to achieve bulkheading.

Graceful shutdown is present. The task-runner entry point has robust signal handling with a forced-timeout, draining/stop calls (runner + healthcheck + Sentry), and guarded repeated signals. The engine server closes the HTTP listener on SIGINT/SIGTERM. The MCP browser server awaits connection.shutdown() before exiting, though it doesn’t explicitly close the HTTP server listener in the provided shutdown path.

• high

  For packages/@n8n/mcp-browser/src/server.ts, extend the shutdown handler to also stop/close the underlying HTTP server(s) (when transportType is 'http') so the process truly stops accepting new work during SIGTERM/SIGINT, not only the MCP connection.

  • packages/@n8n/mcp-browser/src/server.ts:86-123 — Shutdown routine only awaits connection.shutdown() and then exits; the HTTP server handle created via createServer(...).listen(...) is not explicitly closed in this shutdown path.
• med

  In packages/@n8n/engine/src/serve.ts, consider adding a shutdown timeout/forced-exit similar to the task-runner to avoid hanging indefinitely if server.close never completes (e.g., stuck keep-alive connections).

  • packages/@n8n/engine/src/serve.ts:13-24 — Shutdown exits only in server.close callback; there is no explicit max wait / forced shutdown timer.

The codebase contains a versioning mechanism for the CLI “Public API”: it loads versioned `v*` modules, mounts routes under `/${publicApiEndpoint}/${version}`, and provides per-version OpenAPI + Swagger UI. However, the audit did not find an explicit, public deprecation/sunset policy (headers + migration links) or other visible backward-compat governance across versions; the cross-cutting middleware/error handling also doesn’t show such compatibility signaling.

• high

  Add a standardized deprecation/sunset response policy for versioned Public API endpoints (e.g., `Deprecation`, `Sunset`, and/or `Link` headers with migration URLs) and ensure it is applied consistently via the public API middleware/error pipeline.

  • packages/cli/src/public-api/index.ts:1-231 — This file is the central wiring point for the versioned Public API; it is where deprecation/sunset headers would be most reliably applied across endpoints.
• med

  Introduce contract compatibility testing across API versions (e.g., snapshot/contract tests that ensure older versions remain valid and that schema evolution is add-only).

  • packages/cli/src/public-api/index.ts:1-231 — The router uses OpenAPI validation per version, but there is no visible governance/test policy here ensuring backward compatibility over time.
• low

  Extend the global public-api middleware to attach version-compat metadata (when relevant) in a single place to avoid endpoint-specific behavior.

  • packages/cli/src/public-api/v1/shared/middlewares/global.middleware.ts:1-160 — Cross-cutting request handling exists here (scope/cursor validation), but there is no visible version deprecation/sunset signaling.

This codebase implements scoped, server-managed public API credentials. API keys are stored with per-key `scopes` (and `lastUsedAt`), authenticated via `x-n8n-api-key`, and enforced per endpoint through middleware that checks `req.tokenGrant.apiKeyScopes`. There are also dedicated key-management endpoints (create/list/update/delete/scopes) guarded by `apiKey:*` scopes, supporting revocation/rotation workflows.

• high

  Verify consistency across the entire public API surface: ensure every public-api v1 handler uses the scope enforcement helpers (e.g., `publicApiScope` / `projectScope` / `apiKeyHasScopeWithGlobalScopeFallback`) and that all endpoints depend on `req.tokenGrant.apiKeyScopes` rather than bypassing enforcement.

  • packages/cli/src/public-api/v1/shared/middlewares/global.middleware.ts:1-160 — Central scope enforcement exists; auditors should confirm all handlers are wired through it.
• med

  Confirm rotation/revocation behavior is fully documented for external integrators (how to generate a new key with narrower scopes, how to revoke/delete old keys, and how last-used tracking is surfaced/queried).

  • packages/cli/src/services/public-api-key.service.ts:1-192 — Revocation/delete and scope persistence exist in code, but external documentation should be validated.
  • packages/cli/src/controllers/api-keys.controller.ts:1-119 — Key management endpoints exist (create/list/delete/update/scopes), which should map to any published contract/instructions.

Per-tenant/per-consumer rate limiting is present as a route-level capability: `ControllerRegistry` can attach rate limit middleware based on decorator metadata, and `RateLimitService` supports user-keyed buckets (keyed by `req.user.id`). However, enforcement is only enabled on routes that explicitly declare `keyedRateLimit`, and the shown limiter implementation does not demonstrate the expected public signaling contract (standard rate-limit headers, 429 retry guidance) required for third-party integrators.

• high

  Audit the full set of public API routes to ensure user/tenant-keyed rate limiting (`keyedRateLimit: { source: 'user' }`) is consistently applied at the controller/route registration layer (not only selectively). Any endpoints that are currently missing rate limiting should be updated to declare the correct keyed limiter configuration.

  • packages/cli/src/controller.registry.ts:110-225 — This file shows rate limiting is installed only when route metadata explicitly enables `ipRateLimit` or `keyedRateLimit` flags; otherwise requests proceed without the primitive.
• high

  Verify and standardize the public 429 response contract for the rate limiter: ensure headers like `Retry-After` (and, if used, `X-RateLimit-*` or equivalent) are emitted consistently and include retry guidance, aligned with the project’s other API response conventions.

  • packages/cli/src/services/rate-limit.service.ts:1-70 — The middleware is created via `express-rate-limit` with `message` only; no code shown here configures or asserts standard headers / retry guidance.
• med

  Ensure the keying aligns with 'tenant' semantics rather than just 'user'. If n8n public API keys/clients are team/project-scoped (or have an API key tenant identifier distinct from user ID), update `createUserKeyedRateLimitMiddleware` (or add a dedicated 'client/tenant' keyed mode) to bucket by the correct consumer identifier.

  • packages/cli/src/services/rate-limit.service.ts:60-99 — `extractUserIdentifier` returns `user:${req.user.id}`; this may not equal per-tenant/per-client scoping depending on the platform’s consumer model.

Idempotent writes (HTTP retry-safe mutations via an idempotency key) are not implemented as a public, consumable contract on the inspected public write endpoints (workflows + credentials). The codebase does include a separate “data deduplication” mechanism for execution/runtime purposes, but it is not the HTTP mutation idempotency-key pattern required for safe client retries.

• high

  Add idempotency-key support to public mutation handlers (starting with `createWorkflow`, `updateWorkflow`, `createCredential`, `updateCredential`): read an `Idempotency-Key` (or defined equivalent), validate it, and persist the key→(request identity, response payload/status) mapping so retries return the original result rather than creating/applying again.

  • packages/cli/src/public-api/v1/handlers/workflows/workflows.handler.ts:44-85 — No idempotency-key reading/dedup/replay in createWorkflow handler.
  • packages/cli/src/public-api/v1/handlers/workflows/workflows.handler.ts:300-345 — No idempotency-key control flow in updateWorkflow handler.
  • packages/cli/src/public-api/v1/handlers/credentials/credentials.handler.ts:86-115 — No idempotency-key reading/dedup/replay in createCredential handler.
  • packages/cli/src/public-api/v1/handlers/credentials/credentials.handler.ts:123-170 — No idempotency-key reading/dedup/replay in updateCredential handler.
• med

  Introduce a shared middleware/util for idempotency on writes: standardize header name, request hashing/identity, storage, replay logic, and conflict behavior (e.g., distinct 409/422 style machine code when key is reused with different payload).

  • packages/cli/src/public-api/v1/handlers/workflows/workflows.handler.ts:44-85 — Current handlers directly call services without shared idempotency plumbing; this motivates a cross-cutting middleware.
• low

  Keep execution/runtime deduplication (`DataDeduplicationService`) separate from HTTP idempotency; document both clearly to avoid confusion for integrators.

  • packages/core/src/data-deduplication-service.ts:1-125 — Deduplication here is tied to `IDataDeduplicator` and execution/data processing—not public HTTP mutation retry semantics.

The codebase has a strong, reusable pagination + cursor-filtering convention for public API v1 list endpoints: a shared pagination DTO (bounded page size), a `validCursor` middleware to normalize cursor queries, and a shared `encodeNextCursor` response contract. The main public list handlers (workflows, data-tables, projects, credentials, executions) apply this consistently, including returning `nextCursor` and enforcing bounded limits where applicable.

• med

  Audit remaining public list endpoints under `packages/cli/src/public-api/v1/handlers/**` to confirm they all use `validCursor` plus the same bounded page size/max-limit behavior (some handlers default differently). Ensure every list route returns `nextCursor` in the same envelope shape.

  • packages/cli/src/public-api/v1/handlers/workflows/workflows.handler.ts:1-240 — Example of the intended convention on one list handler (good; use as a reference while auditing others).
  • packages/cli/src/public-api/v1/handlers/credentials/credentials.handler.ts:1-238 — Example that also clamps page size to 250; verify parity across other list handlers.
• low

  Where list handlers use ad-hoc parsing of `offset/limit` rather than a shared DTO (e.g., direct `Number(req.query.limit)`), consider standardizing on the DTO validators from `@n8n/api-types/src/dto/pagination` to reduce drift in bounds and parameter semantics.

  • packages/@n8n/api-types/src/dto/pagination/pagination.dto.ts:1-72 — Provides standardized pagination validators and a shared max page size.
  • packages/cli/src/public-api/v1/handlers/projects/projects.handler.ts:1-215 — Uses `offset = 0, limit = 100` without showing a shared clamp here; standardizing would improve consistency.

The codebase contains webhook *inbound* handling (server/controller/service for receiving HTTP webhook requests), and it also has an *outbound* webhook-like sender for log streaming (Axios POST to a configured URL). However, there is no implemented outbound events/webhooks primitive matching the required contract: no evidence of a subscription/delivery worker with HMAC-signed versioned payloads, exponential-backoff retries with a cap + flag/alert, idempotent redelivery, and a documented event catalog. Therefore this primitive is absent as a coherent, integrator-consumable outbound-events system.

• high

  Introduce a first-class outbound events/webhooks delivery pipeline: (1) store webhook subscriptions per tenant/credential, (2) create a delivery worker that reads pending deliveries, (3) emit versioned payloads with HMAC (shared secret) signatures, (4) retry with exponential backoff capped at a limit, then flag-and-alert, and (5) implement idempotent delivery (e.g., delivery-id/request-id persisted) to prevent duplicates on retries.

  • packages/cli/src/webhooks/webhook-request-handler.ts:1-254 — Inbound-only webhook execution/response confirms the missing outbound delivery-worker architecture.
  • packages/cli/src/modules/log-streaming.ee/destinations/message-event-bus-destination-webhook.ee.ts:1-447 — Outbound sending exists, but the request/confirm/throw flow shown lacks HMAC signing, retry/backoff, and idempotent redelivery.
• med

  Add (and check in) a documented event catalog + webhook payload schema/versioning policy (e.g., AsyncAPI/OpenAPI-like or a dedicated event registry file) so integrators can build without contacting the maintainers.

  • packages/@n8n/api-types/src/push/webhook.ts:1-18 — There are webhook-related push message types, but no evidence (from the reviewed webhook destination/server code) of a public, versioned outbound event catalog and payload signing/retry contract.

The codebase has a partially consistent REST error contract: errors are classified and serialized through a centralized pipeline (classifyHttpError -> serializeInternalRestError -> sendErrorResponse). However, evidence also shows endpoint-specific ad-hoc error responses (e.g., MCP consent controller) that do not follow the shared envelope. Additionally, the audited error serializers/responder do not demonstrate a required correlation id field on every error, and the status-code mapping requirements (400/401/403/409/422/429 with correct semantics) are not confirmed in the shared serializer layer.

• high

  Enforce the shared error-envelope for all public REST endpoints by removing/rewriting ad-hoc controller-level {status, message} responses (like MCP consent) to use the centralized sendErrorResponse() / send() wrapper path.

  • packages/cli/src/modules/mcp/mcp.auth.consent.controller.ts:1-107 — sendErrorResponse() here returns { status: 'error', message } directly, bypassing the centralized serializer/envelope used elsewhere.
• high

  Add and propagate a correlation/request id on every error response in the shared serializer layer (e.g., include correlationId/requestId in serializeInternalRestError/serializePublicApiError and ensure it is present for all descriptor kinds).

  • packages/cli/src/errors/http-error-serializers.ts:1-86 — Internal/public serializers currently define code/message/hint/meta (and optional failures) but no correlation id field is present in the response body.
• med

  Verify and correct status-code mapping across the shared classifier/serializers to explicitly cover 400, 401, 403, 409, 422, 429, and ensure 5xx is only used for faults; encode these mappings in classifyHttpError() or ResponseError types so they are uniform across endpoints.

  • packages/cli/src/errors/http-error-serializers.ts:1-86 — The serializer layer sets 400 for userError and 500 for unexpected/server errors, but the mapping for 401/403/409/422/429 is not evident here.
  • packages/cli/src/errors/http-error-classifier.ts:1-93 — classifyHttpError() falls back to status || 400 for HttpError and uses 500 for unexpected/server errors; required HTTP-specific semantics aren’t shown.

The codebase contains an internal sandbox/test-mode mechanism for the instance-ai evaluation harness: sandbox base URL + test/API keys are resolved from env vars (`resolveSandboxConfig`), and an eval HTTP client authenticates against a provided sandbox baseUrl using test credentials. However, this appears to be harness-oriented rather than a clearly documented, third-party consumable “sandbox contract” for external integrators.

• high

  Make the sandbox primitive integrator-facing: add/confirm a documented sandbox base URL and test credential acquisition/rotation process, with a stable contract (where to send requests, which accounts/keys to use, data isolation guarantees, and lifecycle). Evidence: sandbox selection + required keys exist, but there’s no sign (in this audit) of a public, stable integrator contract beyond the eval harness.

  • packages/@n8n/instance-ai/evaluations/harness/sandbox-config.ts:1-105 — Central sandbox config exists, but it’s implemented as env-driven harness configuration rather than a documented external contract.
• med

  Add an explicit “sandbox/test mode” section to the relevant integration docs and/or repository-level docs that maps sandbox env vars to integration behavior (including which providers are supported and what test data isolation means), so a third party can integrate without reading internal harness code.

  • packages/@n8n/instance-ai/evaluations/clients/n8n-client.ts:1-200 — Authentication behavior (POST /rest/login + cookie capture) and test credential defaults exist in code, but should be documented as the stable integration steps for the sandbox primitive.

This codebase has real extension points: (1) CLI external lifecycle hooks loaded from configured external files and invoked through a central `ExternalHooks` runner, and (2) a documented workflow-builder plugin registry in the workflow SDK (validators/composite handlers/serializers) with a singleton registry for easy integration.

• high

  Add first-class, versioned documentation/specs for the External Hooks contract (the expected module export shape and available hook names/parameters), including stability guarantees and error-handling semantics for hook failures.

  • packages/cli/src/external-hooks.ts:33-112 — Shows dynamic loading and registration, but the contract discoverability/stability would benefit from explicit versioned documentation for external hook authors.
• med

  Ensure plugin registry extension points are accompanied by public SDK-facing docs that explain how external packages should create/register plugins, what lifecycle guarantees exist, and how priority conflicts are resolved.

  • packages/@n8n/workflow-sdk/src/workflow-builder/plugins/registry.ts:1-217 — The registry code is well-documented via inline comments, but discoverability typically needs external docs and versioning to be fully consumable by third parties.

No “Shared integration abstraction” for external-system connectors (one common interface + canonical entities like account/contact/invoice across multiple distinct external integrations) was found in the code areas inspected. While the repo contains shared adapter-style abstractions (e.g., CRDT sync provider wiring and various agent/tool/provider interfaces), those are not the integration-depth primitive you requested (they are generic infrastructure, not canonical external-system connector adapters over stable canonical domain entities).

• high

  Identify the product’s customer-facing external-system connectors (the dirs and runtime paths that implement SaaS integrations). Then implement/verify a shared connector interface + canonical entity model contract that every connector maps to (e.g., canonical Account/Contact/Invoice entities). Ensure each connector implements the shared interface rather than duplicating parsing/mapping/writes.

  • packages/@n8n/crdt/src/sync/base-sync-provider.ts:1-117 — Shows the repo’s pattern for shared abstractions, but this one targets CRDT sync rather than external-system connector contracts with canonical entities.
  • packages/@n8n/agents/src/integrations/langsmith.ts:1-377 — Example of a bespoke integration module; use as a comparison point when designing the canonical connector adapter pattern for actual external customer connectors.
• med

  Add “integration adapter contract” enforcement: require connectors to implement the shared interface and produce normalized canonical entities (with validation/dedup at the boundary). Add compile-time typing/tests to prevent one-off/snowflake mappings from bypassing the canonical layer.

  • packages/@n8n/crdt/src/sync/types.ts:1-40 — Illustrates how a shared interface is defined in this repo; apply the same rigor to external connector adapters over canonical entities.

The codebase contains a well-architected bidirectional sync primitive in the CRDT module (BaseSyncProvider), which synchronizes state between peers by applying incoming updates and sending outgoing updates back over a transport. I did not find evidence of this primitive as an external-system integration feature (read+write connector sync) in the sampled connector/node paths.

• high

  If the audit intent is specifically external-system integrations (connectors), expand the connector inventory beyond string/path heuristics (integration/adapter/sync/import/export) and directly inspect the sync execution paths for representative connectors that should require write-back, then verify presence of read+write behavior, stored cursors, idempotent upserts, and failure handling.

  • packages/@n8n/crdt/src/sync/base-sync-provider.ts:23-102 — This is bidirectional sync, but it is internal CRDT peer synchronization; it does not demonstrate external-system read+write connector sync.
• med

  Clarify scope: determine whether the dimension should treat CRDT peer synchronization as “bidirectional sync” for this audit, or only consider customer-facing external connectors. If only external connectors count, mark this primitive as N/A for the integration-depth portion.

  • packages/@n8n/crdt/src/transports/types.ts:1-30 — Defines sync transport as a “dumb pipe” moving binary updates between CRDT documents, reinforcing that this sync is peer-to-peer within the product rather than an external integration connector.

The codebase contains a clear metadata-driven mapping primitive in the EE provisioning/SSO role-mapping area. Mapping rules (expression + role + scope/type + ordering) are stored as config and interpreted at runtime by RoleResolverService via Expression.resolveWithoutWorkflow, selecting the first enabled rule that evaluates to true.

• high

  Add/verify end-to-end tests that demonstrate tenant-scoped behavior is driven purely by persisted mapping config (enabled rules, projectId selection, expression evaluation order) rather than environment- or tenant-specific code branches.

  • packages/cli/src/modules/provisioning.ee/role-resolver.service.ee.ts:1-150 — Rule evaluation order and expression-to-boolean behavior determine correctness of metadata-driven mapping at runtime.
• med

  Audit mapping-rule enablement and fallback semantics (instanceRoleRules vs fallbackInstanceRole; projectRoleRules with matched.has(projectId)) to ensure the expected determinism when multiple rules evaluate true.

  • packages/cli/src/modules/provisioning.ee/role-resolver.service.ee.ts:1-150 — First-match logic is used for instanceRole; for projectRole it uses matched.has(projectId) to prevent additional rules per projectId.

Per-integration reliability is only partially present. There is a retry-with-exponential-backoff manager for external secrets, but the implementation does not include a dead-letter/holding queue for failures after retries. The AMQP sender node (an external integration) does not apply retry-with-backoff + DLQ behavior when per-item message sending fails; errors are surfaced (or thrown) without parking undeliverable records.

• high

  Add retry-with-backoff for per-item AMQP publish failures and introduce a dead-letter queue/quarantine mechanism for messages that still fail after the retry budget is exhausted. Ensure failures are observable (metrics/alerts) and that undeliverable items are parked rather than only returned as errors or thrown.

  • packages/nodes-base/nodes/Amqp/Amqp.node.ts:205-278 — The execute loop sends one message per item, and the catch block either returns an error item or rethrows; there is no retry-with-backoff and no DLQ/quarantine parking.
• high

  Extend the ExternalSecretsRetryManager to support a dead-letter/holding area for operations that fail beyond configured retry attempts (and emit/record alerting for DLQ events). Right now it schedules retries indefinitely via backoff but has no 'give up + park' mechanism visible in this service.

  • packages/cli/src/modules/external-secrets.ee/retry-manager.service.ts:40-130 — Retry scheduling/logging exists, but there is no dead-letter queue/quarantine/parking step and no 'max attempts then park' logic shown.

The codebase contains a strong instance of the “Sync state & reconciliation” primitive in the n8n-memory adapter. It persists per-scope cursors (watermarks), uses idempotent upserts for derived memory entries (contentHash-based), and performs drift repair by dropping/superseding entries and copying/superseding sources according to a normalized reconciliation plan. Other sync-state mechanisms exist (e.g., CRDT peer sync), but the adapter-style cursor+reconciliation is clearly implemented at n8n-memory.

• med

  Add/verify explicit drift detection telemetry/visibility for this adapter (e.g., counters/logging for dropped vs superseded vs upserted counts per reconciliation run) so reconciliation correctness issues don’t remain silent.

  • packages/cli/src/modules/agents/integrations/n8n-memory.ts:760-1045 — The reconciliation computation is present (effectiveDrop, supersededIds, replacement upserts), but no per-run reconciliation metrics are visible in this excerpt; adding observability would strengthen operational verification of drift repair.
• low

  Ensure concurrency safety around cursor updates for the same observation scope (e.g., confirm locking or monotonic cursor update semantics across distributed instances).

  • packages/cli/src/modules/agents/integrations/n8n-memory.ts:940-1045 — Cursor updates use an insert-or-ignore plus an update conditioned on lastIndexedObservationCreatedAt/lastIndexedObservationId ordering, which helps monotonicity, but verifying end-to-end locking (task locks) would complete the reconciliation correctness story under concurrent writers.

The codebase does implement inbound validation/normalization at key API/config boundaries using Zod (DTO validation for “import-workflow-from-url” and Zod schemas for agent integration settings with strictness, custom refinement, and normalization/dedup). I did not identify evidence here of a full “dedup + bad record quarantine” pipeline beyond schema-layer handling for the sampled boundaries; deeper boundary-to-storage ingestion behavior would need confirmation in the handlers/repositories that persist these inputs.

• high

  For inbound workflow import flows, ensure the handler that consumes `ImportWorkflowFromUrlDto` performs idempotency/dedup (e.g., dedupe by (projectId, sourceUrl) or content hash) and quarantines failed/invalid imports to a dedicated failure store rather than allowing raw/unvalidated data to reach workflow tables.

  • packages/@n8n/api-types/src/dto/workflows/import-workflow-from-url.dto.ts:1-9 — DTO-level validation exists, but this evidence alone doesn’t confirm deduplication/quarantine at the persistence boundary.
• med

  For agent integration config, confirm that Zod validation failures are consistently mapped to a canonical error/quarantine mechanism (e.g., rejecting invalid integration configs before they’re stored or used) and that any normalization (like allowedUsers deduping) is reflected in the canonical persisted model.

  • packages/@n8n/api-types/src/agents/agent-integration.schema.ts:1-105 — Schema-layer normalization and constraint enforcement are present, but quarantine/persistence-side canonicalization still needs verification in the code that stores and applies these configs.

The codebase contains credential handling mechanisms consistent with per-tenant/per-credential isolation and refresh. For external secret providers, ExternalSecretsManager loads encrypted per-provider-connection settings, sets up the provider, and starts/stops periodic refresh (supporting refresh and revocation). For OAuth, OAuth service persists token data to the specific credential record (encrypt-and-save) and the OAuth client supports refresh-token based refreshing. However, from the evidence inspected, it is not fully demonstrated that tenant isolation is enforced specifically via a secret manager boundary for all OAuth credential refresh paths (the secret-manager requirement appears explicitly for external secrets, not necessarily for the core OAuth token lifecycle).

• high

  Verify tenant/workspace isolation for OAuth token persistence: trace from getCredentialForUpdate/findCredentialForUser (permission scoping) through credentialsRepository.update(credential.id) and confirm credential.id is tenant-scoped (not globally shared) and that revocation clears/deletes refresh tokens within the same tenant boundary.

  • packages/cli/src/oauth/oauth.service.ts:200-320 — encryptAndSaveData updates the credential by credential.id; need to confirm credential.id belongs to the requesting tenant/workspace via the upstream finder/permission logic (not shown in the snippet).
• high

  Confirm secret-manager-based refresh for “integration credentials” beyond ExternalSecrets EE: locate the component(s) that call token refresh in the runtime and check whether refresh-token material is fetched from per-tenant secret storage (or whether it is stored encrypted in the DB). If it’s DB-encrypted, document that it still satisfies the intended isolation requirement, or extend secret-manager integration if required.

  • packages/@n8n/client-oauth2/src/client-oauth2-token.ts:1-124 — refresh() exists, but this doesn’t show where refresh_token is sourced from (secret manager vs DB).
• med

  For external secrets, confirm per-tenant connection scoping: inspect SecretsProviderConnectionRepository queries/filters to ensure providerKey/settings are constrained to the tenant (not just “providerKey”).

  • packages/cli/src/modules/external-secrets.ee/external-secrets-manager.ee.ts:1-220 — ExternalSecretsManager looks up connection by providerKey and then decrypts settings; verify that providerKey lookup is tenant-scoped in the repository/service layer.

I did not find any implementation of per-integration observability (per connector/platform health, throughput, failures, and last-sync/last-run surfaced to ops/customers). There is an observability provider for the expression engine, and integration code (e.g., AgentChatBridge) logs errors and posts messages, but there are no per-integration metrics/status updates (success/failure rates, latency histograms, last-sync/run state) visible in the integration execution paths.

• high

  Add per-integration metrics and status reporting keyed by integration connection identity (e.g., integrationConnectionId + integration.type): counters for successes/failures, histogram for latency, and a gauge/status record for last successful/failed run time + error code. Emit these at the start/end of executeAndStream and in each error handler.

  • packages/cli/src/modules/agents/integrations/agent-chat-bridge.ts:240-420 — Core per-integration execution pipeline where per-connector success/failure/latency and last-run status should be recorded.
• high

  Instrument platform-specific posting lifecycles (streaming + buffered) with the same per-integration metric labels, so ops can distinguish failures caused by the agent stream vs. failures caused by the external platform post.

  • packages/cli/src/modules/agents/integrations/agent-chat-bridge.ts:420-560 — Streaming post lifecycle currently logs errors but does not expose per-integration throughput/failure metrics.
  • packages/cli/src/modules/agents/integrations/agent-chat-bridge.ts:560-720 — Buffered post lifecycle currently logs errors but does not expose per-integration throughput/failure metrics.
• med

  Surface last-sync/last-run status to an ops-visible channel (and, if applicable, to customers) by persisting a lightweight integration status record (timestamp, outcome, last error code/message) in an existing status store or monitoring table used by the product.

  • packages/cli/src/modules/agents/integrations/agent-chat-bridge.ts:240-420 — This is where the platform integration 'attempt' outcome is known; persist it to support last-sync/run visibility.

The codebase contains a concrete connector-breadth surface for the agents/LLM-provider category: `PROVIDER_CREDENTIAL_SCHEMAS` enumerates many external provider systems and their credential requirements. However, this appears to be provider-focused (auth/capability inputs) rather than a broader “integration catalog” across all table-stakes connector types for the vertical (identity/CRM/data warehouse/etc.); I did not find a single comprehensive breadth matrix for the whole product category in the limited evidence gathered.

• high

  Confirm whether there is a higher-level connector catalog that maps *external systems covered* vs *table-stakes expectations* for this market/vertical (beyond LLM provider credentials). If not, create/extend one (e.g., a single catalog or data-room document + runtime registry) so connector breadth is measurable and gaps are explicit.

  • packages/@n8n/agents/src/runtime/provider-credentials.ts:1-44 — Current breadth evidence is limited to LLM provider credential support; this may not cover broader connector categories implied by the primitive.
• med

  If breadth is intended to be measured for additional connector types (CRM/identity/warehouse/etc.), add analogous enumerations/registries for those connector families (or document intentional omissions), using the same “coverage is explicit” pattern as `PROVIDER_CREDENTIAL_SCHEMAS`.

  • packages/@n8n/agents/src/runtime/provider-credentials.ts:1-44 — Pattern exists for provider breadth (explicit enumeration), but nothing in the gathered evidence indicates the same pattern for other connector families.

The codebase uses an architected first-party integration contract (AgentChatIntegration) while outsourcing connector depth to embedded third-party adapter packages loaded from @chat-adapter/* (Slack/Telegram/Linear/etc.). This is consistent across multiple connectors and avoids spaghetti-style per-connector snowflakes, but the overall integration depth (API connectivity/adapter internals) is clearly ‘bought’ rather than fully built.

• high

  Confirm that adapter-purchased depth is intentionally bounded: document what responsibilities remain first-party (credential extraction, lifecycle hooks, normalization, UI metadata) vs what is delegated to @chat-adapter/* (API calls, protocol details). Add/keep a short README alongside the integrations module to prevent future connectors from drifting into bespoke wiring.

  • packages/cli/src/modules/agents/integrations/agent-chat-integration.ts:1-248 — Shows intended ownership boundaries via abstract createAdapter(), optional lifecycle hooks, and the shared contract used by all platform integrations.
  • packages/cli/src/modules/agents/integrations/esm-loader.ts:1-44 — Shows adapters are loaded from third-party packages, making connector depth largely outsourced.
• med

  Add consistency checks/tests ensuring new connectors follow the same adapter-boundary pattern (extract credentials → load adapter → createAdapter) and register in ChatIntegrationRegistry, so build-vs-buy posture remains uniform as connector count grows.

  • packages/cli/src/modules/agents/integrations/agent-chat-integration.ts:1-248 — Central registry/contract is the enforcing point; tests can ensure future connectors implement it uniformly.

I did not find a true “reproducible one-command build” for the main n8n app: the repo’s local bootstrap relies on multi-step devcontainer commands (corepack/pnpm install and build via lifecycle hooks) rather than a single documented command that (a) starts from a clean clone, (b) deterministically builds/boots using pinned dependencies (lockfile), and (c) is the first-class local boot workflow for contributors.

• high

  Add a repo-root, one-command bootstrap+boot entry point (e.g., `./scripts/boot-dev.sh` or `make dev` / `just dev`) that: (1) installs dependencies from a committed lockfile, (2) builds, and (3) starts the n8n server, with all environment requirements checked and documented. Ensure the command works without requiring devcontainer lifecycle hooks.

  • .devcontainer/devcontainer.json:1-20 — Current bootstrap is split across devcontainer lifecycle hooks (`postCreateCommand` and `postAttachCommand`) rather than a single command.
• med

  Ensure determinism by wiring dependency installation to a committed lockfile and using it in the one-command script (no unpinned installs, no implicit network-resolved version ranges).

  • .devcontainer/devcontainer.json:1-20 — Current setup uses `pnpm install` via devcontainer hooks; determinism should be enforced in the one-command script via lockfile usage.
• low

  If keeping the devcontainer, make its `postCreateCommand` and `postAttachCommand` delegate to the same one-command script so there is one source of truth for local reproducible boot.

  • .devcontainer/devcontainer.json:1-20 — devcontainer currently performs build/install actions directly; delegation would reduce divergence and improve reproducibility.

The automated CI pipeline primitive is clearly present. The repo has dedicated GitHub Actions workflows for master pushes and for pull requests/merge queues. The PR workflow runs build, unit tests, typecheck, lint, and broader checks (DB/e2e/dev-server-smoke/performance/security/workflow scripts) and includes a required-checks gate to validate that the expected jobs pass.

• low

  Consider documenting (in the workflow or README) exactly how branch protection is configured to require the 'required-checks' job (and whether additional jobs are required directly).

  • .github/workflows/ci-pull-requests.yml:300-366 — Shows 'required-checks' is intended for gating/validation, but merge-protection configuration is not visible in this file.

Automated deployment (CD) to production is not present as a distinct, runnable pipeline path in this repository. The codebase has CI workflows for building and publishing release artifacts (NPM, DockerHub, GitHub Releases) but no corresponding production deployment/rollout pipeline stage is wired in the workflow definitions we inspected.

• high

  Add a production deployment/rollout workflow/job wired into the existing release pipeline (e.g., triggered from release-publish or called via workflow_call). Make the deploy step target a specific GitHub Actions environment (environment: production) and include the actual deploy mechanism (Kubernetes apply/Helm, Terraform apply, serverless deploy, etc.), plus rollout/health checks.

  • .github/workflows/release-publish.yml:1-170 — Current pipeline automates publishing to NPM/DockerHub and GitHub Releases, but there is no production deployment stage to extend CD from release → prod.
• med

  If production deployment exists outside this repo, codify the production deploy trigger contract here (e.g., call a separate deploy workflow, or add deploy instructions/scripts and invoke them from CI). Ensure multiple team members can run it via the pipeline (not a one-person script).

  • .github/workflows/docker-build-push.yml:1-220 — This workflow is limited to building/pushing images. Without a follow-on deployment invocation, the path to production is missing from this repo's CD pipeline.

Infrastructure-as-code exists in the repository, but it appears scoped to benchmark infrastructure under packages/@n8n/benchmark/infra (Terraform/azurerm). The IaC is implemented as versioned Terraform configuration and a reusable VM module with pinned providers and concrete Azure resource definitions. However, the evidence suggests IaC may not cover the primary n8n production deployment path (infrastructure-as-code primitives were only detected in the benchmark infra subtree).

• high

  Extend/replicate the Terraform IaC pattern beyond the benchmark-only subtree so that production/staging infrastructure is defined in versioned code (single golden path), not only for benchmark environments.

  • packages/@n8n/benchmark/infra/benchmark-env.tf:1-55 — Current IaC evidence is limited to benchmark infra composition (dedicated hosts + VM module).
• med

  Harden IaC outputs/secret handling: avoid emitting SSH private keys as direct Terraform outputs; prefer storing keys in a secret manager and output only references or public endpoints.

  • packages/@n8n/benchmark/infra/output.tf:1-17 — The Terraform output includes tls_private_key.ssh_key.private_key_pem (sensitive), which is still a high-risk pattern for automation and review.
• low

  Ensure the IaC is fully parameterized and documented with a repeatable “apply” entrypoint (e.g., README + tfvars templates) so new environments can be created reproducibly without tribal knowledge.

  • packages/@n8n/benchmark/infra/modules/benchmark-vm/vm.tf:1-127 — The VM module is parameterized (location, prefix, dedicated_host_id, ssh_public_key, vm_size, tags), but reproducibility quality depends on how variables are provided and documented elsewhere.

I did not find evidence that this codebase enforces true environment isolation (separate dev/staging/prod environments with isolated data and credentials/accounts). The code mostly provides runtime environment detection (NODE_ENV) and occasional runtime switching between staging/production endpoints using hardcoded URLs, but that is not the same as isolated deployments with segregated state.

• high

  Replace hardcoded per-environment endpoints (e.g., staging vs production URLs) with environment-specific configuration that is supplied from versioned per-environment config/infra (dev/staging/prod stacks), and ensure each environment uses its own credentials/accounts/data store.

  • packages/cli/src/modules/mcp-registry/registry/mcp-registry-api.client.ts:1-75 — Uses hardcoded MCP_SERVERS_STAGING_URL / MCP_SERVERS_PRODUCTION_URL and process.env.ENVIRONMENT to switch at runtime.
• high

  Ensure the application’s configuration layer wires separate database connections/secrets per stage (dev/staging/prod) rather than relying on a single binary/runtime with only NODE_ENV checks.

  • packages/@n8n/backend-common/src/environment.ts:1-6 — Only detects runtime mode; does not implement isolated per-environment credentials or data wiring.
• med

  Add/verify a versioned per-environment configuration pattern (e.g., config templates and required variables) for staging/prod, and confirm that secrets are not shared between environments (separate secret sets, not just different endpoint constants).

  • packages/@n8n/agents/.env.example:1-3 — Provides a shared template for API keys but does not show environment-specific separation.

Local/production parity is present and well implemented via a VS Code devcontainer: local development runs n8n in containers (with Compose), includes a containerized Postgres dependency, and uses the repo’s Docker image/runtime conventions (production `NODE_ENV` and entrypoint).

• med

  Confirm that the `.devcontainer/docker-compose.yml` `build.dockerfile: Dockerfile` maps to the same production runtime Dockerfile you intend to mirror (e.g., verify whether it resolves to `docker/images/n8n/Dockerfile` or a different Dockerfile at repo root) and, if different, update the devcontainer to build from the same Dockerfile used for the production image.

  • .devcontainer/docker-compose.yml:1-25 — The dev stack builds using `dockerfile: Dockerfile`, but we also see a production runtime image Dockerfile at `docker/images/n8n/Dockerfile`; ensure these are consistent for full parity.

This codebase uses an explicit configuration layer that externalizes env-dependent settings: key modules under `packages/@n8n/config/src/configs/*` define config fields via `@Env(...)` decorators and read environment variables (including legacy compatibility) at runtime. A `.env.example` template exists for agent API keys, supporting the intended secrets/config injection workflow.

• high

  Do a targeted scan for any remaining environment-specific production literals (e.g., hardcoded URLs/endpoints/keys) outside the config layer (search for patterns like `http://`, `https://`, `API_KEY`, `SECRET`, `process.env` usage without the config decorators) and refactor them into the `packages/@n8n/config/src/configs/` pattern using `@Env(...)`.

  • packages/@n8n/config/src/configs/endpoints.config.ts:1-168 — Represents the desired pattern that hardcoded literals should be migrated toward.
• med

  Ensure every environment-specific secret used by agents/workers (provider keys, external service tokens) has a corresponding `.env.example` entry or documented env mapping, and that production values are never committed.

  • packages/@n8n/agents/.env.example:1-3 — Example of the template approach; extend/keep aligned with actual runtime-required env vars.

This codebase includes real feature-flag plumbing that decouples deploy from release: PostHog flag evaluation happens at runtime, and server-side env-var overrides (`N8N_ENV_FEAT_*`) provide an operator escape hatch. The frontend also gates behavior based on evaluated flag variants. Implementation is solid but the evidence inspected focuses mainly on the flag evaluation/consumption layer rather than verifying percentage/canary rollout at specific production code paths.

• high

  Trace a few concrete production user journeys where features should be gated (e.g., the specific flags mentioned in `@/modules/.../feature-flag` imports) and confirm the code paths are actually guarded by flag checks (and not merely evaluated/telemetry-only).

  • packages/cli/src/posthog/index.ts:100-170 — Current evidence confirms flag evaluation + env overrides, but additional verification is needed that key functional behaviors are wrapped by flag conditionals.
• med

  Confirm rollout behavior beyond boolean enable/disable: identify whether evaluated flags support percentage/canary variants (e.g., variant types or numeric rollouts) and ensure they are used to progressively expose code rather than all-or-nothing activation per deploy.

  • packages/frontend/editor-ui/src/app/stores/posthog.store.ts:45-98 — Client gating checks exist, but the snippet shows boolean `isFeatureEnabled` semantics; verify whether the variants include progressive rollout semantics.
• low

  Document the intended operational model for flag governance (where flags are defined, how long they live, and how rollbacks are performed) so the team treats this as a release mechanism rather than a permanent switch.

  • packages/cli/src/posthog/index.ts:118-171 — Env override escape-hatch is implemented; governance/documentation would strengthen the deploy-vs-release control loop.

Reversibility/rollback for database migrations is implemented and enforced. The migration system distinguishes reversible vs irreversible migrations via types (`down` required or forbidden), `wrapMigration` standardizes execution of both `up` and `down`, and test utilities provide an actual rollback mechanism (`undoLastSingleMigration` calling `undoLastMigration`). I did not identify a production-facing rollback *command/job* in the code slices read, but rollback readiness at the migration layer (including undo testing) is strong.

• high

  Confirm (and if missing, add) an operational rollback entry point that triggers `undoLastMigration`/migration rollback in production when a deploy is reverted (e.g., a CLI/job used by the release process). Right now we verified the undo capability and tests, but not the production rollback orchestration.

  • packages/@n8n/backend-test-utils/src/migration-test-helpers.ts:1-206 — Shows the undo mechanism exists for testing; the remaining gap to validate is whether production CD/release wiring calls into such a rollback path.
• med

  Audit a sample of real migrations to ensure all `ReversibleMigration` implementations truly restore backward-compatible schema/data (not just syntactically having `down`). Your evidence so far shows the contract and helper wiring; the next step is to validate actual migration correctness for representative backward-compatibility cases.

  • packages/@n8n/db/src/migrations/common/1658930531669-AddNodeIds.ts:1-44 — Example of a migration providing both `up` and `down`. A fuller audit across more migrations would validate backward compatibility rather than relying only on the existence of `down`.

Delivery cadence (DORA proxy) appears healthy: git history indicates frequent integration and sustained tagging/release activity, and the codebase includes well-automated CI on master and PRs plus automated release publishing and container build/publish workflows. These are consistent with low release friction and frequent small-batch delivery.

• med

  Verify that merged changes on main/master also trigger an automated deploy to at least a staging environment (not just build/test + publish). If deployment-to-staging is not wired on merges, add a CD workflow to reduce lead time from commit to production-like environments.

  • .github/workflows/ci-master.yml:1-69 — CI is strongly automated on master pushes, but this file alone does not show a merge-to-staging/production deployment path.

Deploy-tooling ownership exists and appears healthy: the repo’s CI workflows and Terraform IaC live as versioned code under .github/workflows and IaC directories, and git-history authorship across these deploy/infra paths is highly distributed (235 authors; top author share ~0.156), reducing the single-engineer CI/CD time-bomb risk.

• med

  Keep ownership distributed by ensuring new CI/CD and IaC changes are reviewed by at least 1-2 contributors outside the original author set (especially for high-impact workflows like Docker build/push and release workflows).

  • .github/workflows/docker-build-push.yml:1-160 — High-impact workflow that should continue to have multi-author review/ownership patterns.

The critical-path bus factor primitive is effectively present. Git-history signals (bus_factor) across critical directories (packages/core, packages/cli, packages/workflow, packages/frontend, packages/nodes-base, packages/@n8n) show many distinct contributors and no indication of bus-factor-1 gravity wells in the aggregated critical directories. Additionally, org ownership manifests (CODEOWNERS/OWNERS) cover critical backend/security areas, and core workflow execution is protected by substantial executable tests—together mitigating single-person knowledge concentration.

• high

  Validate that CODEOWNERS entries for the most business-critical runtime paths (packages/core/* execution engine, workflow execution, and CLI auth/webhooks) are backed by actual commitership by at least 2 human authors over time (not just code ownership labels).

  • .github/OWNERS:1-233 — Ownership coverage exists, but it should be cross-checked against real historical commitership concentration to ensure no single-person gravity wells remain within those directories.
• med

  Confirm there are meaningful tests (non-smoke) specifically for any other critical-path modules that are not as extensively covered as packages/core execution-engine (e.g., scheduling/queueing, webhook handling, and DB transaction/migration integrations).

  • packages/core/src/execution-engine/__tests__/workflow-execute.test.ts:1-3445 — Execution-engine is well covered by tests; use this as a template to check other critical services for equivalent executable coverage.

The repo shows high-churn files, but the git-history hotspots signal did not identify any “danger=true” files (i.e., no files that are both high-churn and touched by only one or two distinct lifetime authors). Therefore, there are no confirmed single-author hotspot sites to audit further, and the primitive appears absent.

• med

  Re-run the hotspots check with a longer lookback window (e.g., since: 24-36 months) to catch hotspots that are not currently within the default 12-month window.

• low

  If you introduce a new frequently-changing subsystem, ensure ownership is shared via CODEOWNERS and that behavior is encoded in tests/docs so it cannot become a gravity well even if one author dominates commits temporarily.

The repo shows strong “review diversity” characteristics at the process level (high PR-based landing: pr_referenced_share=0.713; many human integrators merged changes: distinct_mergers_human=22). In-repo governance also supports this via ownership manifests (OWNERS and CODEOWNERS) that route review to a wider set of owner teams rather than a single gatekeeper.

• high

  Ensure branch-protection / required-review settings (if present) mandate multiple approvers or rotating required reviewers for critical paths (e.g., core/workflow/db/auth). Ownership manifests help, but required-review rules are the enforcement layer that maximizes diversity.

  • git-history (git_org_signals review mode):N/A — Process is already good (distinct_mergers_human=22), but Git-based signals measure integration, not approvals; enforcement should be validated in CI/branch settings.
• med

  Audit that CODEOWNERS/OWNERS entries align with what actually changes most (hot/high-impact modules) and that owners in those entries remain active contributors; if not, update ownership routing so review context stays distributed.

  • .github/OWNERS:1-24 — OWNERS provides the mechanism for review routing; its effectiveness depends on the active presence of named owners across the highest-change modules.

This codebase has an explicit ownership clarity primitive implemented via .github/OWNERS and .github/CODEOWNERS. The manifest declares ownership for key critical areas (including core/workflow and database migrations) and provides a default catch-all owner to avoid unowned paths.

• high

  Verify that each critical-team entry used in .github/OWNERS/.github/CODEOWNERS corresponds to an actual team with >=2 active humans, and that those humans regularly commit in the declared areas (cross-check with bus-factor/history per critical path).

  • .github/OWNERS:1-200 — Manifest contains team-based ownership entries for critical paths; this should be validated against actual people/activity to ensure knowledge is not concentrated in a single individual.
• med

  Add/ensure CODEOWNERS/OWNERS coverage for any remaining high-critical directories not explicitly listed (if any exist), and ensure the catch-all default aligns with the org’s intended escalation/ownership model.

  • .github/OWNERS:1-200 — Catch-all ownership exists, but completeness for every critical directory should be verified against the repo’s actual critical components.

The codebase shows evidence of the retained-vs-departed knowledge primitive via an explicit ownership/coverage mechanism (.github/OWNERS and .github/CODEOWNERS). This helps ensure critical areas are not trapped as single-person knowledge. However, history-based signals indicate substantial “departed authorship share” (recency-based), so while ownership coverage exists, additional durability artifacts (e.g., runbooks/ADRs) are absent and could leave operational/decision context vulnerable.

• high

  Add operational runbooks and migration/upgrade runbooks for the DB/migrations and deployment workflows (since artifacts-mode reported runbook/adr categories as absent). Ensure they are referenced from codeowners/OWNERS areas and updated alongside changes.

  • .github/CODEOWNERS:1-6 — Migrations and workflows are covered by CODEOWNERS, but there is no corresponding runbook/ADR category present in tracked org-doc artifacts (per artifacts scan), which is a typical gap for retained knowledge durability.
• med

  For the most critical packages (those under packages/core, packages/workflow, packages/@n8n/db, packages/@n8n/utils, packages/@n8n/engine-like components), add decision records (ADRs) for major architectural choices so knowledge doesn’t reside only in authors’ heads.

  • .github/OWNERS:1-40 — OWNERS maps many critical packages to owner groups, but artifacts-mode indicated ADRs are absent; ADRs are the durable complement to ownership for retained-vs-departed knowledge.
• low

  Periodically audit ownership mappings for “gravity well” risk: check that each critical package has multiple distinct lifetime owners (not just one group alias) and that owners actually touch the code (not only review assignment).

  • .github/OWNERS:1-60 — OWNERS provides the manifest to audit; performing a regular validation reduces the chance that departed authorship concentrates in a way the manifest doesn’t reflect.

The repo contains strong architecture/“why” documentation in at least one critical area (the @n8n/agents Agent Runtime). However, the core @n8n/engine v2 package currently lacks the same level of durable architecture/why documentation (it describes itself as a scaffold), indicating an opportunity to add architecture rationale as the engine evolves.

• high

  Create/expand durable architecture (“why”) docs for packages/@n8n/engine v2: execution-loop design, invariants/assumptions, key tradeoffs, lifecycle/state machine, and operational intent (what correctness means for the engine).

  • packages/@n8n/engine/README.md:1-15 — Identifies @n8n/engine as the workflow execution engine (v2) but states it is currently a scaffold with public API/core interfaces still being defined—i.e., the architectural “why” documentation is not yet present at the same depth.
• med

  Add cross-links from engine v2 public entry points to the architecture/why doc sections (eventing/state machine/constraints) so rationale stays discoverable for new contributors and operators.

  • packages/@n8n/agents/docs/agent-runtime-architecture.md:1-90 — The @n8n/agents architecture doc is detailed and structured; mirroring its organization (overview, public API, loops/events, lifecycle) provides a reusable template for the engine v2 docs.

Operational runbooks do not exist anywhere in the repository as tracked org-doc runbook artifacts (the `runbook` bucket is absent). While ownership manifests exist, the codebase lacks written, service-specific operational runbooks covering deploy, incident response, and recovery—creating a risk of a gravity well during outages.

• high

  Create a runbook document set under the repo’s ops/doc structure for each critical service area (at minimum: core execution, workflow layer, database/migrations, and CLI deployment/operations). Each runbook should include: (1) how to deploy, (2) incident triage/checklist, (3) recovery + rollback steps, (4) links to dashboards/logs/alerts and exact commands.

  • .github/OWNERS:18-32 — Critical areas are explicitly owned here (core/workflow/db/cli), indicating where operational runbooks should exist.
• high

  Assign runbook CODEOWNERS (or equivalent) that match the critical ownership set, and ensure at least two people actively update each runbook after incidents or operational changes (to reduce knowledge concentration).

  • .github/OWNERS:1-6 — Ownership governance exists (OWNERS/CODEOWNERS). Use it to make runbooks maintainable by more than one person.
• med

  Add lightweight smoke verification for runbooks: e.g., a monthly checklist test that validates the documented recovery commands against a staging environment (or verifies links/commands are still correct).

  • CONTRIBUTING.md:1-120 — The repo has an established contribution process and operational documentation culture; use it to formalize runbook verification steps.

Onboarding reproducibility is present primarily via CONTRIBUTING.md, which documents requirements, a clean-clone development setup (pnpm install → pnpm build → pnpm start), and a reproducible dev workflow for iterating and validating changes. Implementation is good and concrete, but there isn’t evidence (from on-graph/code checks) of a single canonical “one command from clean clone” script; it’s documented as an explicit command sequence.

• high

  Add/ensure a single canonical bootstrap command (e.g., `pnpm setup && pnpm build && pnpm start` wrapped into one script) and document it prominently at the top of the onboarding section, so the ramp-up loop can be executed with minimal command coordination.

  • CONTRIBUTING.md:110-170 — Current onboarding reproducibility relies on a documented sequence: `pnpm install` → `pnpm build` → `pnpm start`, rather than a single one-command bootstrap.
• med

  Add a ‘fresh clone checklist’ section that cross-links prerequisites and environment setup (devcontainer, Node/pnpm versions, and `.env.local` handling) and explicitly names the expected state at the end (e.g., backend running + frontend accessible).

  • CONTRIBUTING.md:1-120 — Requirements and dev container guidance exist, and environment-variable instructions exist later, but the doc would benefit from an explicit end-to-end checklist tying them together into a single reproducibility story.

The primitive is present: the repo contains substantial test suites that function as executable specifications, including security-critical execution-context behavior and core workflow execution correctness. These tests are meaningfully asserted (not just smoke/import checks), indicating strong “executable knowledge” usage on critical paths.

• high

  Ensure any newly added or refactored critical execution/agent paths always include intent-pinning tests (edge cases + invariants), especially around encryption/decryption and workflow execution ordering/output shape.

  • packages/core/src/execution-engine/__tests__/execution-context.service.test.ts:1-170 — This shows the desired pattern: edge-case coverage with explicit expectations for credentials/secureArtifacts handling.
• med

  For the workflow execution engine and agent orchestration modules, require PRs to reference/extend the existing executable tests when changing behavior, so behavior changes remain discoverable in test diffs.

  • packages/core/src/execution-engine/__tests__/workflow-execute.test.ts:1-70 — The existing tests act as a behavior contract; extending them keeps the contract current.

History legibility is partially supported: git history indicates a meaningful share of commits include explanatory bodies (low low-effort subject rate; non-trivial body share), and some modules include rationale in docs. However, durable decision records (ADRs) appear absent across the repo (artifacts mode reported 0 ADR files), so the primitive is not fully implemented where it should be most critical (major architectural decisions).

• high

  Introduce ADRs (or an ADR-equivalent decision record format) for major architectural milestones (e.g., Engine 2.0 wiring decisions). Ensure each ADR links to the relevant PRs/commits so that the 'why' can be recovered from history even if commit archaeology is needed.

  • packages/@n8n/engine/README.md:1-15 — Engine 2.0 rationale is present, but there is no visible durable decision record artifact (ADRs absent repo-wide per artifacts scan), which is the key gap for decision_history_legibility.
• med

  For changes that replace/retire architectural components, enforce commit/body guidelines (e.g., require a short 'why/impact' section for non-trivial design changes) to complement the lack of ADRs and increase recoverability from git history.

  • CONTRIBUTING.md:1-120 — Contribution guidance exists; extend/enforce guidance specifically for design-change commit messages/bodies so intent is consistently captured in history.

No evidence was found in the codebase for generation/publication of an SBOM (e.g., via syft, cyclonedx/cdxgen) as part of CI/release. While the repo clearly maintains lockfiles (pnpm-lock.yaml and multiple uv.lock files) indicating dependency pinning, this audit did not locate any SBOM-generation step wired into GitHub workflows or release scripts.

• high

  Locate and add an SBOM generation step to the release/CI pipeline (preferably producing a CycloneDX or SPDX artifact during build). Ensure it includes transitive dependencies and is uploaded as a build artifact and/or published alongside release assets.

  • pnpm-lock.yaml:1-40 — Lockfile pinning exists (pnpm lockfile present), which is necessary for an accurate SBOM, but this file alone is not proof that an SBOM is generated in CI/release.
• med

  Add an SBOM freshness check: fail the pipeline if an SBOM artifact is missing or does not match the current lockfile resolution (or at least ensure the SBOM is regenerated on every release build).

  • renovate.json:1-95 — Dependency-update automation is present (Renovate config), but there is no indication here of SBOM generation/verification as part of the release process.

License compliance is not satisfactorily applied for this codebase’s proprietary SaaS risk profile: the transitive dependency license scan flags at least one network-copyleft dependency (@zone-eu/mailsplit, EUPL-1.1+) and one strong-copyleft dependency (jszip, GPL-3.0-or-later). The required mitigation/justification steps for these specific dependencies are not evidenced in the inspected lockfile contents.

• high

  Remove or replace the network-copyleft dependency @zone-eu/mailsplit@5.4.8 (EUPL-1.1+ OR MIT) from the dependency graph (preferably via direct dependency changes/upstream alternatives). If it must remain, produce a deal-legal justification package (license texts/NOTICE handling, distribution/SaaS risk analysis, and internal policy sign-off).

  • pnpm-lock.yaml:12000-12500 — Lockfile includes @zone-eu/mailsplit@5.4.8; dependency-license scan flags it as network-copyleft.
• high

  Remove or replace the strong-copyleft dependency jszip@3.10.1 (GPL-3.0-or-later OR MIT) from the dependency graph. If relying on the MIT alternative, document and validate that the distributed artifacts are actually under MIT terms (and that the GPL path is not applicable).

  • pnpm-lock.yaml:16000-17500 — Lockfile includes jszip@3.10.1; dependency-license scan flags it as strong-copyleft.
• med

  Add/verify CI enforcement that fails the build on strong/network-copyleft transitive dependencies unless an explicit allowlist + justification exists. Ensure the compliance report (SBOM/license inventory + NOTICE artifacts) is generated for release artifacts.

  • .github/scripts/pnpm-lock.yaml:1-120 — Repo uses pnpm lockfiles (multiple lockfiles exist), so CI can be wired to enforce compliance based on lockfile license scanning.

A dependency vulnerability scan over the repo’s lockfiles (OSV/GHSA via osv-scanner) reports many HIGH/CRITICAL findings (e.g., handlebars 4.7.8, @babel/traverse 7.21.4), but I did not find evidence in the checked-in code (via the accessible repo entrypoints) of a corresponding CI “known-vulnerability scan” primitive that triages/remediates these findings. Based on the limited wiring evidence, treat implementation as missing/unclear.

• high

  Add/ensure a CI job that runs a lockfile vulnerability scan (OSV via osv-scanner or equivalent), fails the build on untriaged HIGH/CRITICAL issues, and requires explicit triage/exception records tied to the exact pinned lockfile versions.

  • package.json:1-120 — No top-level CI/dependency vulnerability scan script is evident in the repository’s primary scripts entrypoint.
• high

  Create triage workflow rules for each HIGH/CRITICAL finding: either upgrade the vulnerable dependency to a fixed version in the relevant workspace lockfile(s), or document an exception with justification and (where possible) demonstrate reachability for the vulnerable API.

  • pnpm-lock.yaml:1-60 — Lockfile-based anchoring is required for this primitive; vulnerabilities are reported per pinned version and must be resolved/triaged against those pins.

The “known-exploited CVEs” primitive is satisfied at the dependency level: osv-scanner’s known-exploited CVE set reports known_exploited_count = 0 for this repo (i.e., no vulnerabilities flagged as part of the famous actively-exploited set were found in the pinned dependency graph). However, I did not independently anchor any specific known-exploited dependency entries to exact lockfile line ranges via code_read, so the implementation-quality grade is not perfect.

• high

  Confirm the result by pinpointing in each lockfile the exact pinned versions (and verify none match the known-exploited aliases) for the top CVE candidates returned by osv-scanner, using code_read to cite the specific lockfile lines.

  • /tmp/claude-501/virgil-cs-4998FI/repo/pnpm-lock.yaml:1-40 — Lockfile is present and was used for scanning; next step is to locate the exact pinned dependency entries for any packages that map to the known-exploited alias list.
• med

  Ensure CI enforces this primitive (e.g., a step that runs osv-scanner with a known-exploited/“known vulnerability scan” gate) rather than relying on ad-hoc manual scans.

  • /tmp/claude-501/virgil-cs-4998FI/repo/pnpm-lock.yaml:1-40 — Evidence of enforcement is not available from the data collected so far; add/verify a CI gate that fails builds when known-exploited CVEs are detected.

For this primitive, dependency reachability is evidenced on key call paths: the public API middleware layer uses `express` and swagger UI helpers, and the HTTP/request utilities and OAuth2 identifier resolvers actively call into `axios` rather than merely importing it for types. This indicates the codebase correctly exercises important dependencies in runtime flows (no clear 'imported but never called' anti-patterns observed in the sampled high-risk spots).

• high

  Run/extend the dependency reachability checks across the full manifest-vs-imports set: identify declared-but-never-imported and phantom imports, then confirm call-site reachability for any libraries with known high impact (HTTP, auth, crypto, templating).

  • packages/cli/src/public-api/index.ts:1-120 — Example of a high-risk dependency reachability site already exercised (express + swagger UI). This pattern should be systematically checked for the rest of the dependency set.
• med

  For each externally imported high-risk dependency (e.g., `express`, `axios`, `swagger-ui-express`), record the most important call-site files/functions and use them to rank CVE remediation blast-radius (hot-path first).

  • packages/core/src/execution-engine/node-execution-context/utils/request-helpers/axios-utils.ts:1-200 — Central axios-based helper establishes a hot-path call-site that should drive upgrade priority.

This codebase has the two key components of dependency freshness hygiene: (1) a committed pnpm lockfile that pins exact versions with integrity hashes, and (2) a Renovate configuration that enables OSV vulnerability alerts to drive regular dependency updates. However, the lockfile also contains at least one explicitly deprecated package entry (superagent), and a large transitive set has vulnerability findings, so freshness remediation appears to be ongoing rather than fully caught up.

• high

  Prioritize upgrading transitive dependencies with the highest severities (especially CRITICAL/HIGH) from the OSV scan results, and confirm via reachability/usage that vulnerable code paths are exercised where applicable. Start with the most central UI/build dependencies (e.g., handlebars and babel traverse) that are heavily reused.

  • pnpm-lock.yaml:20000-20080 — Lockfile contains an explicitly deprecated dependency entry (superagent), demonstrating that at least some staleness/deprecation remediation is still pending.
• high

  Add/verify CI enforces freshness controls: ensure there is a repeatable security/dependency freshness job (e.g., osv-scanner run against lockfiles, and/or a SBOM generation check) that fails when the OSV vulnerability set crosses a defined threshold.

  • renovate.json:1-95 — Renovate alerts are enabled, but freshness in CI still needs an enforced gate (not just notification). This file is the mechanism currently present.
• med

  Review lockfile maintenance settings and Renovate grouping so that major/minor updates don’t stall in review queues; ensure the update cadence is sustained across all workspaces (root plus nested pnpm-lock.yaml files).

  • renovate.json:1-95 — Renovate is configured with grouping and disabled lockFileMaintenance; tuning may be needed to keep multi-workspace pnpm dependencies current.

Upstream maintenance is implemented via an active Renovate dependency-update mechanism (including vulnerability alerting). However, this audit run does not provide direct “upstream abandoned/deprecated” flags from dependency metadata, so the finding is based on the presence of an ongoing update mechanism rather than proving every critical upstream is still actively maintained.

• high

  Add/verify an explicit “deprecated/abandoned upstream” signal in CI or dependency scanning results (e.g., fail the build or create tracked issues when osv-scanner flags deprecated packages). Current evidence shows vulnerability alerting and dependency updating, but not a dedicated deprecated-upstream replacement gate.

  • renovate.json:1-95 — Renovate configuration shown, but it is oriented to updates and vulnerability alerts; there is no evidence here of an automated abandoned/deprecated-upstream policy.
• med

  Ensure the dependency-updater actually keeps moving for the relevant ecosystems by periodically reviewing merged dependency-update PR rates (remediation velocity) and scheduling policy.

  • renovate.json:1-95 — Mechanism exists; continue monitoring merged PR velocity to confirm upstream maintenance is operational, not just configured.

Remediation velocity is implemented: Renovate is configured for automated dependency updates with vulnerability alerting (renovate.json). Additionally, the repo includes a PR approval + auto-merge workflow used to ensure dependency update PRs can be merged when CI checks pass (util-approve-and-set-automerge.yml). Off-graph git-history evidence indicates the dependency-update mechanism is active with non-zero recent merged update activity.

• high

  Add/verify an explicit CI gate or documentation that ties Renovate-created dependency PRs to the approve-and-automerge path (so the velocity signal remains reliable over time).

  • .github/workflows/util-approve-and-set-automerge.yml:1-50 — This workflow can approve and auto-merge given a PR number, but the audit should confirm that Renovate PRs consistently flow into it.
• med

  Ensure vulnerability alerts are treated as merge-blocking (for HIGH/CRITICAL) or have a tracked SLA, so the velocity mechanism translates into timely remediation outcomes.

  • renovate.json:1-95 — Vulnerability alerts are enabled (including OSV alerts), but this should be paired with an explicit operational policy/SLA in CI or workflows.

Supply-chain integrity is present: the repo commits pnpm lockfiles with `integrity` hashes, and CI installs with `--frozen-lockfile` (preventing lockfile drift). Python environments also use uv.lock files with explicit sha256 hashes. Implementation quality is solid overall, but full coverage across all workflows/sites can’t be proven from the evidence read so far (only specific workflows/lockfiles were directly inspected).

• high

  Verify that every CI/CD job that installs Node dependencies (pnpm) uses `--frozen-lockfile` and points to the intended lockfile (root vs per-package). Sample-check other install workflows (not just `release-update-pointer-tag.yml`).

  • .github/workflows/release-update-pointer-tag.yml:1-68 — This one workflow is compliant; the audit should confirm the same pattern in all other workflows.
• med

  Confirm Python install steps for every uv.lock consumer use hash-verified installation (and don’t allow resolution to regenerate lockfiles without review).

  • packages/@n8n/task-runner-python/uv.lock:1-120 — The lockfile itself is hash-pinned; ensure usage during builds is also strict.
• low

  Optionally add explicit supply-chain provenance checks in CI (e.g., verifying install logs against lockfile, or enabling package manager integrity enforcement flags) if not already globally configured.

  • pnpm-lock.yaml:20000-20080 — Integrity hashes exist; additional CI assertions would strengthen end-to-end assurance.

Dependency-confusion resistance is implemented at the dependency-resolution tooling layer: the repo pins pnpm as the package manager, includes a committed pnpm lockfile, and blocks npm installs via a preinstall script. This provides meaningful (but not fully proven here) resistance against slopsquatting/confusion by ensuring resolution is deterministic and uses the intended installer.

• high

  Also verify that the lockfile contains integrity hashes for resolved packages (and that CI uses the lockfile with a frozen/immutable install), so name-to-version resolution is truly deterministic for all workspaces.

  • pnpm-lock.yaml:1-11 — Lockfile presence is confirmed; however, deterministic integrity pinning should be confirmed by reading specific sections where integrity/resolved hashes are stored.
• med

  Audit all workspace manifests for any unscoped private package names (and ensure private packages are always namespace-scoped like `@org/...`), since slopsquatting risk is highest for unscoped/private-like names.

  • package.json:1-14 — Manifest-level enforcement exists for the package manager, but an explicit scan/read of all package manifests for unscoped private names is required to fully close the dependency-confusion gap.

The primitive is present: n8n documents and provides a Contributor License Agreement, stating that PRs can only be merged after the CLA is signed. However, based on the evidence collected so far, I can confirm the existence of the CLA artifact and how it is described in contributing docs; I did not find (in the snippets reviewed) the concrete bot/workflow enforcement code that triggers CLA comments and blocks merges (so the implementation certainty is slightly below perfect). Git history shows many authors, but without an employee roster in this audit run, individual unassigned-IP candidates cannot be conclusively separated from properly CLA-covered contributors.

• high

  Confirm the CLA enforcement mechanism is actually wired in CI/GitHub (e.g., a specific GitHub App/bot or workflow that posts the CLA request and blocks merge until signature). Read the relevant workflow(s) or bot configuration to verify enforcement is operational, not only documented.

  • CONTRIBUTING.md:520-526 — States enforcement intent (bot comment + merge gating), which should be verified by finding the actual workflow/bot configuration doing it.
• med

  Run an authorship-to-ownership validation with a provided roster (current employees/contractors emails) to identify any off-roster human contributors and then verify that CLA coverage exists for those contributors (or that an employment/assignment agreement exists).

  • N/A (tool output):N/A — git_dep_provenance authorship listing is available but a roster was not provided, so unassigned-IP candidates cannot be reliably flagged in this run.

No AI-coding-tool provenance tracking was identified in the codebase (e.g., no file/headers/markers for AI-generated code, no Co-authored-by / provenance trailers, and no AI-usage/provenance policy artifacts found via targeted searches for provenance-related naming).

• high

  Add an explicit, repo-wide AI provenance convention and enforcement: e.g., require a machine-readable provenance trailer or header (with tool/model + run id + prompt hash) for any AI-generated/assisted code, and document it in a policy file; update CI to validate markers on PRs.

No clear implementation of “configuration over code branches” for tenant/customer/brand variation was found in this codebase. Queries for per-customer/per-tenant code directories and customization override directories under typical paths (customers/, tenants/, overrides/, custom/) returned no matches, suggesting customer-specific behavior is not being handled via a tenant-driven config layer in this repo (at least not in the indexed code/data paths).

• high

  Re-run this audit including the repo’s runtime “instance/tenant” configuration sources (e.g., environment-based config, database-driven settings, node/workflow type registry, or brand/EE gating). The current scan focused on directory patterns for multi-tenant customization and only surfaced generic, app-internal mappings/constants—not tenant config layers.

  • packages/@n8n/ai-workflow-builder.ee/evaluations/cli/argument-parser.ts:1-160 — CLI arguments include generic featureFlags/config-like inputs, but this is not evidence of tenant/customer-driven configuration replacing code branches.
• med

  Search for actual tenant/customer identifiers used to gate behavior (then verify whether behavior branches on identifiers vs attributes/entitlements/settings retrieved from config/DB). If behavior is attribute-driven, the primitive may exist under different naming than the “tenants/customers/overrides” directory patterns.

  • packages/@n8n/ai-utilities/src/node-catalog/search.ts:1-220 — Contains an internal hardcoded display-name override map (MODE_DISPLAY_NAME_OVERRIDES), illustrating that customization-like variation is implemented as code constants in at least some places (not as tenant config).

I did not find any hardcoded customer/tenant/org/account identity branching in the inspected areas. For example, where an identity field like `customerId` is used (e.g., constructing Stripe API endpoints), it is treated as a passed-in/customer-provided parameter rather than a branch key (i.e., no special-casing like `if customerId === <literal>` was observed in the checked code).

I did not find any dedicated, centralized “pricing/plan logic” module in this codebase. The frontend consumes plan/limit data from cloud APIs (e.g., `/admin/cloud-plan` and `/cloud/limits`) and then computes remaining usage for display, but there is no single local module where pricing/discount/plan rules/constants are defined and reused across the system. There also appears to be no in-repo billing/pricing module (e.g., no `/billing`, `/pricing`, `/subscriptions` code directories detected), so the expected centralized pricing logic primitive is effectively absent from this repository.

• high

  If pricing/plan rules (discounts, tiers, entitlements, limits) are expected to vary by plan, consolidate them into a single billing/pricing module in-repo (e.g., `/packages/<...>/pricing/` or `/packages/<...>/billing/`) and ensure controllers/UI consume derived results from that module instead of duplicating calculations.

  • packages/frontend/@n8n/rest-api-client/src/api/cloudPlans.ts:1-109 — Plan metadata and limits are fetched from remote cloud endpoints; this repo does not show any local centralized pricing/plan-rule module behind these calls.
  • packages/frontend/editor-ui/src/app/stores/cloudPlan.store.ts:1-301 — The UI computes remaining usage (workflows/executions left) directly from fetched plan/usage fields, rather than referencing a centralized pricing/plan-logic module.

I did not find an implementation of “metering decoupled from the pricing model” anywhere in this codebase. While the repo contains token usage/cost concepts for the agents runtime (e.g., token usage types and `computeCost()` converting usage to USD using model cost data), the code does not show a generic usage/metering capture layer that is later mapped to charges by an independent billing/pricing module. In other words, usage and pricing are implemented together rather than via a decoupled metering→billing mapping boundary.

• high

  If the product requires customer billing/plan-based metering: introduce a dedicated metering layer that records generic usage events (e.g., token counts or execution counters) independent of any plan/price model, then implement a separate billing/pricing mapper that turns those usage events into charges. Keep the execution engine unaware of USD conversion/pricing constants.

  • packages/@n8n/agents/src/runtime/agent-runtime.ts:1-70 — Shows the runtime importing pricing/cost utilities directly, which is the coupling the primitive warns against.
  • packages/@n8n/agents/src/sdk/catalog.ts:1-210 — Shows pricing computation (`computeCost`) from token usage inside the pricing/cost module, rather than mapping externally from generic metering events.

This codebase uses feature gating via flags/entitlements in multiple key layers (backend module initialization, centralized flag evaluation via PostHog with env overrides, and frontend route gating/variant checks). The gating is done by enabling/disabling the same code paths via flags, rather than forking plan/tenant-specific implementations.

• med

  Where feature checks appear inline in route handlers/components, ensure they ultimately depend on a centralized flag/entitlement source (e.g., the same flag resolution pipeline used elsewhere) to keep flag governance consistent and retire flags cleanly.

  • packages/frontend/editor-ui/src/app/router.ts:110-190 — Some gating is directly embedded in router guards using PostHog variant/flag readiness; verify it consistently maps to the same entitlements/flag definitions used by the backend.

This codebase contains documented extension interfaces, most clearly via the `@ContextEstablishmentHook()` / `IContextEstablishmentHook` contract (a self-describing, version-ready hook interface with decorator-based discovery and DI registration). There is also an extension mechanism for expression runtime functions (`extend` + `ExtensionMap`) and a config-driven entry point for external lifecycle hooks (`EXTERNAL_HOOK_FILES`). Overall, extension boundaries exist and appear upgrade-safe, but not all extension points are equally “public plugin contracts” (expression runtime looks more internalized than the context hook system).

• high

  Verify and document the full external lifecycle hook loading path for `EXTERNAL_HOOK_FILES` (where files are loaded, how hook contracts are validated, and how versions/compatibility are handled) so this config surface becomes a truly stable documented extension interface rather than just a config knob.

  • packages/@n8n/config/src/configs/external-hooks.config.ts:1-21 — Current evidence only shows the configuration surface; the audit should confirm the downstream loader + contract validation exists.
• med

  For expression extensions, ensure there is a clearly documented public contract for third-party/partner extension authors (how to register new `ExtensionMap` entries, how docs/metadata are provided, and how compatibility is maintained across upgrades).

  • packages/@n8n/expression-runtime/src/extensions/extend.ts:1-195 — The runtime `extend()` and internal extension resolution exist, but this needs confirmation of a stable external registration interface.
• low

  Add explicit versioning/deprecation guidance to the documented hook interface documentation for context-establishment hooks (if not already present in the runtime registry) to strengthen upgrade safety for external implementers.

  • packages/@n8n/decorators/src/context-establishment/context-establishment-hook.ts:1-420 — The interface documentation mentions future versioning; the ecosystem would benefit from an implemented versioning/compatibility check surface.

The codebase contains clear customization isolation boundaries via (1) the expression runtime extension interface (extend/extendOptional with security blocklisting) and (2) a workflow-builder plugin registry abstraction. Both funnel custom behavior through stable, bounded contracts rather than per-customer code forks, supporting upgrade safety.

• high

  Document and enforce the stability guarantees of the expression extension boundary and plugin registry (e.g., versioning expectations, compatibility rules, and deprecation workflow) so third-party/custom code is upgraded predictably alongside core.

  • packages/@n8n/expression-runtime/src/extensions/extend.ts:1-195 — Central customization boundary for expression extensions; should have explicit compatibility/deprecation policy to reduce upgrade re-validation.
  • packages/@n8n/workflow-sdk/src/workflow-builder/plugins/registry.ts:1-217 — Central customization registry; add/confirm public contract documentation and compatibility/version strategy.
• med

  Add automated regression tests that simulate “custom plugin/extension + core upgrade” scenarios (e.g., plugin registration, resolution, serializer lookup order, and extension security constraints) to prove isolation over time.

  • packages/@n8n/workflow-sdk/src/workflow-builder/plugins/registry.ts:1-217 — Registry behavior (priority ordering, lookup, unregister semantics) is exactly what should be regression-tested for upgrade safety.

I did not find a theming/white-label system that is driven by tenant/customer configuration (i.e., serving the next brand via config rows rather than code changes). The front-end contains UI/editor theming implemented as code-defined themes (e.g., CodeMirror and ag-grid theme objects using CSS variables), which indicates styling configuration via build/runtime CSS variables rather than a white-label “theme selection + variant data” layer.

• high

  If white-label/partner-specific branding is a requirement, introduce a configuration-driven theming layer (e.g., tenant/brand theme manifest + CSS-variable token sets) and wire UI rendering to select the active theme from config instead of relying on hardcoded theme definitions in code.

  • packages/frontend/editor-ui/src/features/core/dataTable/components/dataGrid/n8nTheme.ts:1-14 — Defines the ag-grid theme in code (themeQuartz.withPart(...).withParams(...)) rather than selecting a theme variant from data/config.
  • packages/frontend/editor-ui/src/features/shared/editors/components/CodeNodeEditor/theme.ts:1-200 — Defines CodeMirror theme styling in code using CSS variables; there is no evidence of a tenant-configured theme manifest/selection mechanism.
  • packages/frontend/editor-ui/src/features/ndv/parameters/components/ExpressionEditorModal/theme.ts:1-54 — CodeMirror theme for input/output modal is constructed in code, not sourced from white-label theme configuration.

I did not find a tenant-configurable behavior surface implemented as a customer-facing settings/rules model that governs business behavior (workflows/fields/rules/limits) per tenant. The only clear “tenant” concept in the inspected code is infrastructure/config for licensing (e.g., tenantId env var), not a data-driven behavior extension surface for customers.

• high

  Do a targeted repo-wide check for a tenant-scoped settings/rules model (e.g., DB tables or config loaders for per-tenant feature rules/limits/workflow behaviors). If none exists, confirm whether this platform is intentionally single-tenant (per instance) and document the expected customization boundary; otherwise, introduce a formal configuration surface rather than behavior branching in code.

  • packages/@n8n/config/src/configs/license.config.ts:1-29 — Current “tenant” usage appears limited to licensing configuration, which doesn’t establish a general tenant-configurable behavior surface.

This codebase supports low-touch, configuration-driven onboarding for SSO provisioning/role management via a dedicated provisioning module. Admins can patch provisioning config through an API, the service validates and persists config into a settings store, and startup bootstrapping loads provisioning config without code edits—indicating marginal onboarding cost is primarily configuration, not engineering.

• high

  Confirm (in docs and/or UI flows) that onboarding customers can complete this provisioning setup self-serve using only the `/sso/provisioning/config` patch endpoint and/or environment variables—so the “onboarding path” is clearly low-touch end-to-end (not just technically config-driven).

  • packages/cli/src/modules/provisioning.ee/provisioning.controller.ee.ts:1-45 — Provisioning is patchable via API; validate that this is actually used as the intended onboarding path for new customers.
  • packages/cli/src/modules/provisioning.ee/provisioning.service.ee.ts:240-520 — Config patching is persisted and reloaded; documentation/UX should match this capability.

The repo contains a committed security document (SECURITY.md), but it is not a self-serve trust documentation set. It only covers reporting a security vulnerability and does not package the broader trust/compliance artifacts prospects typically need for procurement diligence (certifications/attestations, DPA/sub-processor transparency, pen-test summaries, and ongoing control/status evidence).

• high

  Expand self-serve trust documentation beyond vulnerability disclosure: create/maintain a trust-center-style set (either in-repo under a docs/trust path and/or a published trust page) that includes versioned DPA/privacy/legal commitments, a current sub-processor list with last-updated timestamps, certification/attestation summaries (or clear pointers to SOC 2/ISO artifacts), pen-test summary cadence, and operational control/status information kept current.

  • SECURITY.md:1-4 — Current SECURITY.md content is only vulnerability disclosure reporting, not procurement-grade self-serve trust evidence packaging.
• med

  Ensure the trust artifacts are maintained as an intentional product surface (not ad-hoc responses): add explicit “last updated” dates, versioning for sub-processors and attestations, and a single canonical URL that procurement can cite in reviews.

  • SECURITY.md:1-4 — No versioned trust-center elements (last-updated, attestations, sub-processors, control status) are present in the current artifact.

This codebase does not contain a data-room “Questionnaire response library” artifact (CAIQ/SIG/VSA response bank). The repository scan shows the `questionnaire` category is absent (expected for data-room materials that are typically not committed to source control).

• high

  Request the current Questionnaire response library (e.g., CAIQ/SIG/VSA response set) directly from the seller’s Security/GRC team or GC for packaging review. Ask for (1) the latest version date, (2) mapping to dominant frameworks/standards, and (3) versioned ownership/maintenance evidence.

No controls-to-contract mapping artifact (DPA/MSA commitments mapped to implemented controls + audit evidence) was found in the code-adjacent materials. The only discovered trust doc (SECURITY.md) is limited to vulnerability disclosure and does not package the required deal-closing traceability.

• high

  Create and version a “Controls-to-Contract mapping” document under a predictable repo path (e.g., docs/security/) that explicitly maps each DPA/MSA commitment (encryption, retention, breach notice, data residency) to (a) the implemented mechanism in the system and (b) the corresponding audit evidence reference (e.g., SOC 2 control IDs / test reports). Ensure the doc is maintained and date/version stamped.

  • SECURITY.md:1-4 — Shows current trust doc scope is insufficient; it’s the place where buyers expect links/traceability artifacts.
• high

  Publish/maintain the DPA/MSA itself (or at least the committed security exhibit) in a buyer-accessible location and cross-link it from SECURITY.md so procurement can validate commitments against the mapping document.

  • SECURITY.md:1-4 — Current doc contains no DPA/MSA references; procurement traceability is missing.
• med

  Add a short, maintained index page (e.g., SECURITY.md section) that lists the traceability artifacts (controls-to-contract mapping, trust documentation, and sub-processor inventory version) so reviewers do not have to re-derive evidence from scratch.

  • SECURITY.md:1-4 — Current SECURITY.md has no such index/links.

No code-visible, complete tenant-scoped “get ALL your data out” export mechanism was found. The codebase includes workflow/data-table export helpers used for source-control export, but they are scoped to caller-provided IDs and write selected resources to a local work directory rather than providing a full tenant-wide, async portable export handler.

• high

  Implement (or expose) a tenant-scoped export request endpoint/job that exports ALL tenant data (not just selected workflows/data tables) in a portable format, with clear async/job status and download delivery.

  • packages/cli/src/modules/source-control.ee/source-control-export.service.ee.ts:155-227 — Current export targets only `candidates` workflow IDs; it cannot satisfy “ALL tenant data” portability.
• high

  Add comprehensive coverage across tenant data types by integrating/expanding the existing export-to-work-folder primitives into a single “tenant export” job orchestration layer (so the orchestration ensures completeness rather than relying on selected IDs).

  • packages/cli/src/modules/source-control.ee/source-control-export.service.ee.ts:260-380 — Current exports for data tables are also ID-scoped (`id: In(candidateIds)`), not tenant-complete.
• med

  Publish a code-visible handler contract (request DTO + response/download mechanism) aligned to the procurement “data portability” primitive, instead of workflow-id-based DTOs and local folder output.

  • packages/@n8n/api-types/src/dto/packages/export-workflows-request.dto.ts:1-8 — Existing request schema is workflows-only (`workflowIds`), not a tenant-wide export request.

The codebase contains a user deletion endpoint (`DELETE /users/:id`) that performs a tenant-scoped cascade of primary application data (workflows, credentials, auth identities, and the personal project + user record). However, within the reviewed code, there is no packaged evidence that the deletion request also propagates to backups or other derived/async data stores, which weakens procurement readiness for 'erase-on-request, verifiably'.

• high

  Provide/implement (and link to auditable evidence) a true erase-on-request cascade that explicitly covers derived/async data and backup retention. Concretely: identify what data stores exist beyond the direct DB entities deleted here (execution logs, binary/object storage, search indexes, event/audit streams, backups/replicas) and ensure the user-deletion flow triggers their cleanup for the user/tenant scope.

  • packages/cli/src/controllers/users.controller.ts:200-360 — Current implementation shows cascade deletion of workflows/credentials and DB entities (AuthIdentity, personal Project, User), but does not demonstrate backup/derived-store cleanup from this call chain.
• med

  Add an auditable deletion job record and completion verification (e.g., a durable job with status + counts of deleted items per subsystem) tied to the erase request. This should be produced/retained for the customer/data-subject and for internal compliance review.

  • packages/cli/src/controllers/users.controller.ts:240-360 — Deletion is performed directly in the controller/service transaction and emits `user-deleted` and runs `externalHooks`, but the reviewed slice does not show a durable, verifiable “erase completed” artifact.
• low

  Clarify contract semantics: the endpoint appears to be admin-driven user deletion with optional transferee migration. If the procurement contract requires 'data subject self-serve erase', document and/or add a self-serve erase path that maps a data-subject request to the same cascade deletion mechanism.

  • packages/cli/src/public-api/v1/handlers/users/users.handler.ee.ts:90-110 — Public API wiring for `deleteUser` calls `UsersController.deleteUser(req)` and returns 204; this indicates an API exists but does not by itself establish self-serve erase or the full verifiable cascade required by the primitive.

No code-visible implementation of a tenant data-residency commitment was found. Region values exist only as generic infrastructure/provider configuration (e.g., S3 bucket region), not as a tenant attribute used to route data/compute to a pinned residency region. Because this repository appears to be the n8n product code (primarily self-hostable) rather than a multi-tenant hosted service with residency pinning, this primitive is not applicable as a code-derivable control in this codebase.

• high

  If you are auditing the *hosted* n8n service for residency commitments (EU/Canada/India), request the current residency enforcement architecture and the tenant-region-to-routing enforcement evidence from the seller (e.g., region-pinning data model + routing layer + deployment topology). This repo alone does not provide the required tenant-scoped enforcement artifacts.

  • packages/core/src/binary-data/object-store/object-store.config.ts:1-64 — Evidence shows only S3 bucket region configuration; no tenant region attribute or enforcement routing keyed on tenant region is present in the observed region-related code.

I found IP allowlisting enforcement in two places: (1) outbound SSRF protection driven by environment-configured CIDR allow/block lists, and (2) a per-Webook-node ipWhitelist option that blocks access (403) when a request IP is not allowed. However, I did not find evidence of the *enterprise access controls* primitive as defined (tenant-scoped network restriction enforced at an edge/boundary, plus an admin UI/control surface to manage it). Therefore, this primitive is treated as absent in this codebase.

• high

  Confirm whether there is an enterprise/tenant-level ingress IP allowlisting feature elsewhere in the codebase (e.g., reverse proxy/ingress middleware, instance-level config, or an enterprise settings module) and that it supports multi-tenant scoping. If not present, implement a boundary enforcement layer that applies a tenant-configured allowlist/CIDR to inbound requests uniformly.

  • packages/@n8n/config/src/configs/ssrf-protection.config.ts:1-78 — Existing allowlisting is for SSRF outbound protection, indicating allowance logic exists but not the enterprise inbound access-control primitive.
  • packages/nodes-base/nodes/Webhook/Webhook.node.ts:220-302 — Existing allowlisting is per-node (ipWhitelist) rather than enterprise boundary enforcement.
• high

  Add or surface an admin UI (and corresponding API) that allows security teams to manage the allowlist per tenant/enterprise plan, and ensure the enforcement reads from that tenant configuration (not from ad-hoc per-node settings or unrelated SSRF settings).

  • packages/nodes-base/nodes/Webhook/Webhook.node.ts:220-302 — Demonstrates allowlist control is currently node-configuration driven rather than enterprise admin-controlled.
• med

  Package deal-close evidence: provide a documented control description and code-to-control traceability for how the enterprise allowlist is enforced at the network boundary (middleware/edge) and how it is administered (UI/API).

  • packages/@n8n/config/src/configs/ssrf-protection.config.ts:1-78 — Current evidence is present as config/env + service logic, but it maps to SSRF protection rather than the requested enterprise access-controls primitive.

I did not find a public, current, versioned sub-processor list artifact (e.g., docs/subprocessors or SUBPROCESSORS.md) that would transparently back the DPA sub-processor clause. The repo-adjacent “subprocessors” scan returned code files unrelated to a maintained processor inventory, and there was no clear code-visible control or imported inventory matching a declared list.

• high

  Create/maintain an explicit, versioned sub-processor inventory in a repo-adjacent location (e.g., docs/subprocessors or SUBPROCESSORS.md) and ensure it is clearly tied to the DPA sub-processor clause. The artifact must be current and include a notification flow/versioning when changes occur.

  • packages/@n8n/ai-workflow-builder.ee/evaluations/evaluators/binary-checks/llm-checks/valid-data-flow.ts:1-37 — The only surfaced “subprocessors” related artifact appears to be evaluation code, not a declared, versioned sub-processor list backing DPA terms.
• med

  Cross-check the declared sub-processor list against actual third-party data sinks used by the product (SDK imports / integrations) and update the inventory to include any third party the system sends data to (analytics, monitoring, LLM providers, messaging, etc.).

  • packages/@n8n/ai-workflow-builder.ee/evaluations/evaluators/binary-checks/llm-checks/valid-data-flow.ts:1-37 — Provides no declared inventory; therefore a packaging step is required so procurement reviewers do not have to reconstruct the sub-processor inventory from scratch.

No compliance attestation readiness evidence (e.g., a current SOC 2 Type II report and a control-to-code traceability package) was found in the data-room compliance_reports bucket. This primitive is data-room follow-up (not code-visible), so its absence is expected from a repo scan and should not be scored as a code gap.

• high

  Request the current SOC 2 Type II report (and/or equivalent ISO27001/pen-test attestation if applicable) plus control-to-code traceability from the seller, ensuring the mapping matches the implemented Dim 5 audit evidence set used by your procurement/procurement-legal team.

• med

  Ask for the specific version/date of the attestation and the scope boundary (services, regions, and subprocessors) that matches the codebase deployment you intend to procure.

No procurement-grade Reliability / SLA evidence is packaged in this repo. The only relevant artifacts discovered are: (1) a SECURITY.md focused on vulnerability disclosure, and (2) UptimeRobot integration code, which does not function as published SLA/status terms or incident/postmortem evidence.

• high

  Provide (or link to) procurement-ready Reliability/SLA evidence: published status page URL(s), documented SLA/availability commitments, and a versioned incident/postmortem history (or a link to the incident archive). If these are maintained externally, add them to a trust/security page in this repository.

  • SECURITY.md:1-4 — No SLA/status/incident evidence is currently packaged here.
• high

  Create a dedicated doc (e.g., STATUS/SLA/RELIABILITY.md or update SECURITY.md) that explicitly includes: (a) uptime targets, (b) maintenance window policy, (c) definitions/exclusions, (d) escalation/support process, and (e) incident review/postmortem links.

  • packages/nodes-base/nodes/UptimeRobot/GenericFunctions.ts:1-42 — Existing code is an integration client; it should not be mistaken for procurement evidence packaging.

A portable export mechanism exists in code (ExportService that serializes DB tables to encrypted JSONL and compresses into entities.zip). However, in the code we inspected, there is no evidence of an on-demand, tenant-scoped export/download handler that is permission-gated and audited for customer data egress. As a result, the primitive is only partially implemented at the data-export layer and does not yet clearly satisfy the “portable or hostage” customer on-demand export requirement end-to-end.

• high

  Find (or add) the actual export/download HTTP/API handler(s) that trigger ExportService for a customer request, and ensure they are (1) tenant-scoped, (2) permission-checked, and (3) audit-logged. The handler should return a downloadable, portable archive (e.g., entities.zip) for the requesting tenant/account only.

  • packages/cli/src/services/export.service.ts:248-417 — This file contains the export archive generation, but the tenant scoping/authz/auditing requirements for the on-demand primitive are not evidenced in the inspected code range.
• med

  Document and align completeness: confirm which entity categories are included/excluded in exportEntities (it currently iterates through entityMetadatas and optionally includes data table rows). Add explicit inclusion/exclusion rules so the customer can rely on a complete export.

• med

  Harden export paging/fidelity for large tenants: exportEntities uses LIMIT/OFFSET paging based on offset increment by pageEntities.length. Review correctness and performance at scale; consider keyset pagination if available to avoid unstable pagination under concurrent writes.

  • packages/cli/src/services/export.service.ts:310-395 — exportEntities uses OFFSET/LIMIT with offset increment, which can be sensitive to concurrent modifications and may be inefficient for very large datasets.

The codebase has a real export implementation (SourceControlExportService) that writes workflow/variable/data-table/folder resources to JSON files for source-control-style exports. But for this primitive (“Export completeness & fidelity”), the evidence indicates the export surface is not a single tenant/account-scoped “export ALL customer data categories” handler; it appears candidate- and context-scoped with early returns and selective coverage. Therefore, portability is present for specific resource types, but completeness across the full customer data model is not demonstrated.

• high

  Identify (or implement) a single, tenant/account-scoped bulk export handler for reporting/data egress that enumerates every customer-exportable entity category and validates coverage against the data model (no silent omissions). The existing SourceControlExportService methods are candidate-scoped; the completeness primitive requires a full-account export surface.

  • packages/cli/src/modules/source-control.ee/source-control-export.service.ee.ts:120-190 — Workflow export is driven by `candidates: SourceControlledFile[]`, suggesting non-complete coverage for a full-account export primitive.
• high

  Ensure the bulk export endpoint (not just internal services) is tenant-scoped, permission-gated, and audited. Add explicit authorization checks and audit logging around the top-level export request/job creation.

  • packages/cli/src/modules/source-control.ee/source-control-export.service.ee.ts:1-220 — This service shows repository reads and filesystem writes but does not demonstrate a top-level, audited, tenant-scoped bulk export endpoint for ALL customer data.
• med

  Add automated “export completeness” tests that compare the exported file contents against expected counts/sets for each critical data category (including operational/history/analytics where applicable).

  • packages/cli/src/modules/source-control.ee/source-control-export.service.ee.ts:215-270 — There are explicit early-return cases (e.g., empty variables => count 0). Completeness tests should detect whether such behavior is correct for the intended primitive scope.

I did not find any code-visible implementation of the “Large / async export handling” primitive (async job + streamed export that does not buffer the full dataset in memory). While there is export functionality that returns a `Readable` tar stream, the tar writer buffers all entry contents in memory, and the workflow export command serializes the entire export dataset in-process.

• high

  Replace/upgrade the tar writer to be true streaming: do not store all entry `Buffer`s in `entries`; instead, write each tar entry to the pack as data becomes available (or pipe from upstream streams). Ensure backpressure is respected and the export does not hold the full dataset in RAM.

  • packages/cli/src/modules/n8n-packages/io/tar/tar-package-writer.ts:12-78 — Shows the in-memory buffering anti-pattern (`entries` array + `Buffer` per file) that will not scale to large exports.
• high

  Move large export endpoints to an async job model: enqueue export work, persist progress/status, and provide a download endpoint that streams the completed artifact (or streams while the job runs). This avoids long in-request execution and improves reliability at volume.

  • packages/cli/src/commands/export/workflow.ts:96-175 — Current export command buffers and serializes all workflows in-request (no job/progress/streaming export artifact).
• med

  Audit other bulk “export*” flows for the same memory-buffering pattern (collect-to-array + JSON.stringify / Buffer accumulation). Convert hot loops to iterator-based pagination/streaming reads from the DB.

  • packages/cli/src/modules/n8n-packages/n8n-packages.service.ts:21-49 — Exports are produced via exporters that feed the buffered `TarPackageWriter`; this wiring should be reviewed end-to-end for streaming compliance.

I did not find any scheduled/recurring *exports* mechanism in the codebase (schedule store + runner that batches and delivers tenant-scoped exported data to a destination, with retry/DLQ, etc.). The codebase does include cron/scheduling infrastructure for executing workflows/tasks, but not a scheduled data-export primitive.

• high

  If you expect a customer data export product feature, add/implement a dedicated scheduled_exports subsystem: (1) tenant-scoped schedule persistence, (2) a runner that materializes full export batches, (3) retry/DLQ semantics, (4) destination abstraction (S3/warehouse/webhook/drive/etc.), and (5) tenant+permission checks plus audit logging on every export job execution.

  • packages/core/src/execution-engine/__tests__/scheduled-task-manager.test.ts:1-1 — Existing scheduling infra appears oriented around executing scheduled tasks/workflows rather than exporting data; implement scheduled_exports as a separate data-egress subsystem instead of reusing workflow cron alone.

No real “warehouse sync / reverse-ETL” primitive (incremental, managed sync to customer warehouses/BI destinations) was found. The codebase contains warehouse destination integrations (e.g., Snowflake and BigQuery nodes) that execute user-driven SQL/insert/update operations, but not a dedicated sync/reverse-ETL layer with incremental syncing and sync-job orchestration.

• high

  Confirm whether n8n’s intended “reverse-ETL” is implemented via workflow-driven nodes only; if the product promises managed warehouse sync/incremental behavior, add a dedicated sync layer (sync state, incremental cursoring, scheduling/runner, retries/DLQ) rather than relying solely on ad-hoc executeQuery/insert/update node actions.

  • packages/nodes-base/nodes/Snowflake/Snowflake.node.ts:27-188 — Snowflake node exposes on-demand operations (executeQuery/insert/update) but no incremental sync/stateful warehouse-sync mechanism.
• med

  If warehouse sync configs/connectors are supposed to exist (e.g., dbt/airbyte/fivetran/singer-style), ensure they are represented by maintained configuration/projects and not just credential/node metadata; add or document a concrete sync configuration path with actual sync execution wiring.

  • packages/nodes-base/nodes/Google/BigQuery/GoogleBigQuery.node.ts:1-28 — BigQuery integration entrypoint is only a wrapper selecting node versions; it does not show a maintained reverse-ETL sync configuration/execution component.

This codebase contains a real in-product analytics/reporting primitive: the /insights REST controller plus corresponding public API handler expose reporting endpoints (summary, by-workflow, by-time) backed by an InsightsService that computes dashboard-ready aggregates. Access is gated by authorization scope decorators and license checks, and request date ranges are validated and checked against license retention/granularity constraints.

• high

  Confirm end-to-end tenant/project scoping and authorization for the underlying data queries (projectId filtering and whether the authenticated user is restricted to their own project). The controller passes projectId through to the service/repositories, but we should verify that the repository queries enforce ownership/tenant boundaries.

  • packages/cli/src/modules/insights/insights.controller.ts:18-55 — Controller passes query.projectId through to insightsService.getInsightsSummary({ projectId: query.projectId }).
  • packages/cli/src/modules/insights/insights.controller.ts:64-92 — Controller passes query.projectId to getInsightsByWorkflow.
• med

  Check the repository query implementations used by insightsService.getInsightsSummary/getInsightsByWorkflow/getInsightsByTime to ensure they are performant for real datasets (indexes/aggregation strategy) and that no unbounded history/range slips past license filtering.

  • packages/cli/src/modules/insights/insights.service.ts:66-120 — getInsightsSummary uses insightsByPeriodRepository.getPreviousAndCurrentPeriodTypeAggregates(...) and then computes derived report metrics.
• low

  Verify frontend/UI integration exists for these endpoints (tables/charts) and that the client is using the same reporting API contracts, not duplicating reporting logic or relying on internal-only routes.

  • packages/cli/src/modules/insights/insights.controller.ts:64-112 — The controller defines the public reporting endpoints that a frontend dashboard should consume.

Event-stream completeness (as a reporting/event coverage primitive) exists in the codebase as a typed event system built around EventService (TypedEmitter) plus relay layers (TelemetryEventRelay and LogStreamingEventRelay) that register handlers for specific event-name catalogs using the shared EventRelay.setupListeners wiring. Evidence shows substantial coverage via large eventName→handler maps. However, I did not find an off-graph, documented “event catalog” specifically for this primitive to diff against the actual emitted/handled set (git_doc_scan surfaced other schema/config categories but no clear dedicated documented event catalog for drift comparison).

• high

  Add/locate the documented external event catalog for this primitive (the “what we claim to emit” list) and then implement an automated diff test: (declared catalog events) vs (actually registered relay handlers / emitted event names) to detect drift.

  • packages/cli/src/events/maps/relay.event-map.ts:1-120 — RelayEventMap is an internal typed catalog; if it is the source of truth for documentation claims, it should be used for the declared-vs-implemented diff.
• med

  Create completeness assertions per relay layer (TelemetryEventRelay and LogStreamingEventRelay): ensure every intended RelayEventMap event name has a corresponding handler entry in the setupListeners map for that output.

  • packages/cli/src/events/relays/telemetry.event-relay.ts:106-190 — TelemetryEventRelay.init is where handler coverage is defined; it should be programmatically checked against the declared event catalog.
  • packages/cli/src/events/relays/log-streaming.event-relay.ts:63-120 — LogStreamingEventRelay.init similarly defines coverage; it should be programmatically checked for drift.
• low

  Extend or add tests that assert registered listeners include a representative set of RelayEventMap keys (and fail when keys are added to RelayEventMap but omitted from relay maps).

  • packages/cli/src/events/relays/event-relay.ts:8-21 — All relay coverage flows through setupListeners; test hooks here or around it can reliably validate completeness behavior.

Documented payload schemas for export/reporting-style data are present in-repo (e.g., maintained Zod schemas under packages/@n8n/api-types/src/schemas). However, the repo-wide “documented export/event schema” coverage for the full event catalog (e.g., telemetry/audit/workflow events) is not fully evidenced as a single maintained asyncapi/openapi/event-catalog-style contract in the code we inspected—so overall documentation quality/coverage appears partial rather than comprehensive.

• high

  Add/maintain a single, consumer-facing event catalog/spec (asyncapi/openapi or an EVENTS.md/schema doc) that enumerates the supported event names AND links each event name to a versioned JSON schema for its payload—then ensure code payloads are validated/serialized against those schemas to prevent drift.

  • packages/@n8n/api-types/src/schemas/insights.schema.ts:1-111 — Shows the desired pattern (explicit schema), but the evidence collected so far does not demonstrate that all event/export payloads are uniformly documented this way and tied to a catalog.
• med

  For each major event group (telemetry/audit/workflow execution/queue/etc.), ensure there is a corresponding documented payload schema (and add tests that fail when emitted payloads diverge from the documented schema).

  • packages/@n8n/api-types/src/schemas/insights.schema.ts:1-111 — Demonstrates schema/test-friendly Zod shapes; extend this approach to cover event payloads beyond insights.

The codebase includes an export endpoint for n8n packages (workflows/credentials) but does not implement an explicit “Export access control & audit” primitive on the export path: there is no visible permission/tenant authorization check and no visible audit/access-log write associated with the export request.

• high

  Add a permission + tenant/project scoping authorization check for the export endpoint (before export work begins) and ensure it is enforced for every requested workflowId/credential requirement. Record a denial reason consistently.

  • packages/cli/src/modules/n8n-packages/n8n-packages.controller.ts:11-27 — Export endpoint forwards req.user to the service without any explicit access-control gate visible at the handler layer.
• high

  Write an audit/access-log event for each successful export request (and optionally each failure) that includes tenant/account/project identifiers, exporting user id, the exported entity counts/ids (redacted as needed), and the request correlation id.

  • packages/cli/src/modules/n8n-packages/n8n-packages.service.ts:18-49 — Export generation happens here, but there is no audit/access-log emission in the observed export implementation.
• med

  Ensure exporter dependencies (WorkflowExporter/CredentialExporter) cannot accidentally broaden access: validate that their internal queries are scoped to the requesting user’s tenant/project and permission set, not merely “user object present”.

  • packages/cli/src/modules/n8n-packages/n8n-packages.service.ts:18-41 — The service relies on workflowExporter.export({ user: request.user, workflowIds }) and credentialExporter.export(...) but no explicit enforcement/audit is shown at this layer.

This codebase has a real export capability for selected workflows (and related credentials) packaged as a downloadable gzip/tar artifact (`/n8n-packages/export`). However, for the specific primitive of exit portability/no lock-in, the code-visible export path evidenced here appears *not* to be a full-account export covering all customer data needed to leave; the handler/service are driven by `workflowIds`. The repo scan did not find any exit-terms/contract clause documents in source (hand-off required to a buyer GC).

• high

  Implement or document a true full-account export endpoint (tenant/account-scoped) that includes all relevant customer data beyond workflow definitions—e.g., credentials, global variables, data tables, settings/config, and other exported entities required for leaving—packaged in a portable format (with completeness guarantees).

  • packages/cli/src/modules/n8n-packages/n8n-packages.service.ts:1-65 — Current export is driven by `workflowIds` and only wires `WorkflowExporter` + `CredentialExporter`, which is insufficient to claim full-account portability.
• high

  Ensure the full-account export path is explicitly permission-gated and auditable (write an audit-log entry on export initiation/completion, and confirm tenant scoping).

  • packages/cli/src/public-api/v1/handlers/n8n-packages/n8n-packages.handler.ts:1-90 — The shown handler demonstrates license/scope gating and streaming behavior, but the full-account export governance expectations for exit portability (explicit authz + audit evidence) are not shown in this slice.
• med

  Buyer-GC hand-off (contract half): confirm the MSA/termination/data-portability clause explicitly honors the customer’s right to export their complete data before lock-in/termination restrictions take effect.

  • : — git_doc_scan found `exit_terms` category as absent in the repo (no contractual clause artifacts to cite). This is a hand-off item to the buyer's GC, not a code gap.