n8n Security: What Project RBAC, External Secret Stores, and Log Streaming Cover

An n8n workflow with an AI Agent node in it is a piece of infrastructure that holds credentials, calls models, and acts on their output. n8n Enterprise secures that infrastructure with three mechanisms: project-scoped role-based access control over workflows and credentials, external secret stores for the credentials themselves, and log streaming that ships events to a syslog server, a generic webhook, or a Sentry client. I want to walk through what each one governs, then trace a single agent run to see which identity actually reaches the model.

TL;DR

n8n groups workflows into projects and grants access by project role, so editing rights on a workflow and its credentials follow the project role.
External secret stores keep credential material outside the n8n database, and from version 2.13.0 instance owners and admins can grant project editors and admins access to those secrets.
Log streaming is Enterprise-only on both Cloud and self-hosted, covering n8n.audit.*, n8n.workflow.*, node execution, worker, runner, queue, and AI node events.
The credential an AI Agent node uses belongs to the workflow, so the model endpoint sees that credential and never the person or system that triggered the execution.

Project RBAC scopes editing, not execution content

n8n's access model puts workflows into projects and derives a user's rights from their project role. That is the correct shape for a workflow platform, and it gives a security team a real boundary: a finance-automation project can be restricted so only the finance platform team can open, edit, or run its workflows, and the credentials attached to that project stay inside it.

The boundary governs the design-time surface. A user with no access to a project cannot read its workflows or its credentials, which prevents the most common failure mode where an engineer browsing a shared instance discovers a live production API key sitting in a node configuration.

What the boundary does not govern is what a workflow does once it runs. A workflow that a project admin authored and activated executes with the project's credentials on every trigger, regardless of who or what fired the trigger. A webhook-triggered workflow reachable by an unauthenticated HTTP call runs with exactly the same authority as one an admin runs by hand.

External secret stores move the material, not the authority

n8n documents external secret stores so credential values live in a dedicated vault rather than in n8n's own encrypted store, and n8n notes that from version 2.13.0 instance owners and admins can grant project editors and project admins access to external secrets.

Pulling a key from a vault at execution time is a genuine improvement over storing it in the workflow database. Rotation happens in one place, the vault holds its own access log, and a database compromise yields references instead of secrets.

The authority the credential carries is unchanged by where it is stored. An OpenAI or Anthropic key fetched from HashiCorp Vault at 09:14 grants the same model access as that value pasted into a node, because the model endpoint validates the bearer token and nothing else. Vaulting solves custody and leaves authorization exactly where it was.

What log streaming actually carries

Log streaming is available on n8n Cloud Enterprise and self-hosted Enterprise, and it supports three destination types: a syslog server over UDP, TCP, or TLS, a generic webhook using GET, POST, or PUT, and a Sentry client. Events are selected in Settings, Log Streaming, Events, and subscribed by prefix such as n8n.audit.* or n8n.workflow.*.

The event families cover a lot of ground:

Workflow events: started, success, failed, cancelled.
Node execution events: started and finished.
Audit events: user management, credentials, API keys, MFA, packages, workflows, variables, secrets, sharing restrictions, 2FA, and token exchange.
Worker events: started and stopped.
Queue events: job enqueued, dequeued, completed, failed, and stalled.
AI node logs: memory, parsing, retrieval, embeddings, document processing, tool calling, vector store, and LLM operations.

The AI node coverage is better than most workflow platforms offer and includes tool calling and vector store operations, which are the two places an agent run goes wrong. One configuration flag deserves attention during design: anonymizeAuditMessages strips sensitive payload data from n8n.audit.* events. Turning it on protects secrets in transit to a SIEM and removes detail an investigator may later want, so the choice belongs in a documented decision rather than a default.

Streamed events describe the platform's own operations. An n8n.node.finished event says a node completed. It does not carry an authenticated human principal, a data classification for the payload that node handled, or a policy decision, which is the distinction covered in AI audit log schema design.

Trace an agent run and the identity disappears

Take a support-automation workflow. A form submission hits a webhook trigger. n8n loads the project's credentials, an AI Agent node assembles a prompt containing the submitter's account history pulled from a CRM node, and calls the model. On the wire that is a POST to the messages path on api.anthropic.com, carrying an x-api-key header holding the n8n project credential.

The model endpoint sees a project credential. It never learns that the run was triggered by a form submission from an unauthenticated visitor, or by an internal user, or by a scheduled cron. Every execution of that workflow presents identically on the wire, which means the model provider's own logs, the vault's access log, and the streamed n8n.node.finished event all describe the same anonymous caller.

That is the post-authentication gap applied to an orchestration layer, and it is sharper here than in a normal application because n8n's whole purpose is to run without a human present. The broader problem of credentials acting as machine identities is covered in non-human identity for AI agents.

The second exposure is the tool side. An AI Agent node with tool-calling enabled can be steered by content that arrived in the prompt, which for a support workflow means text a stranger typed into a form. n8n's execution data redaction and RBAC do not evaluate model output before a downstream node acts on it, which is the attack shape described in indirect prompt injection defense.

What enforcement on the request path requires

For an n8n deployment handling regulated data, the control has to sit between the AI nodes and the model endpoints, resolve which principal the execution is acting for, classify the assembled prompt, evaluate both against a versioned policy, and record the decision. Project RBAC keeps deciding who may build the workflow. The vault keeps deciding where the credential lives. Neither can decide whether this particular payload should reach this particular model.

DeepInspect

This is the gap DeepInspect closes. DeepInspect runs inline as a stateless proxy in front of HTTP LLM endpoints, so pointing n8n's AI nodes at the proxy base URL puts every model call from every workflow through one policy evaluation point with no change to the workflows themselves.

Each call is checked against the identity the execution is acting for, the classification of the content in the prompt, and a versioned policy, and each decision produces a signed record that exports to the same SIEM already receiving the n8n.audit.* stream. Project RBAC keeps governing who edits what, external secret stores keep custody of the credentials, and log streaming keeps reporting what the platform did. DeepInspect adds the per-request authorization decision none of those three perform. Book a technical deep dive at deepinspect.ai.