Get Started Free

n8n: connection and validation

Estimated reading time: 6 minutes

Limited coverage · Reviewed 2026-09-07

Installable n8n node 0.1.0 executes authenticated managed MCP prepare, checkpoint and explicit approved resume against an independently signed inert target.

Connect n8n through the managed companion

Create a workspace for n8n Open n8n setup · Start with the free sample

  1. Create your free workspace and verify your email. On the dashboard, run the local allow/block sample and inspect the saved audit and actual signing status. This requires no model or external target; it does not connect a client or create independently verified proof.
  2. Return to your saved n8n setup. Create its real managed-mcp installation, then download the configuration and local package commands bound to that installation. Agent association is optional. Configuration starts read-only.
  3. Load the creator’s scoped API credential on the controlled companion host and run the one-use connection challenge there. Credentials never belong in a public workflow, model prompt or exported configuration. Recorded credential proof does not attest native installation or a target effect.
  4. Install the reviewed local n8n-nodes-praesidia-managed package with its matching SDK and companion tarballs. Set N8N_CUSTOM_EXTENSIONS to the installed node package and restart your own instance. Add Praesidia managed action after a manual trigger, configure its credential store and start with Check connection. Keep workflow retries disabled.
  5. Inspect connection from the native client. To execute, bind an authorized registered target and obtain its public signing key independently. Preparation stops for a different human reviewer. Resume needs the exact stored approval, request commitment and explicit confirmation; ambiguous attempts must not be retried blindly.
  6. Refresh the workspace and inspect the server-returned action bound to this installation. A successful connection or copied guide is not execution evidence.

For n8n, Dify and Langflow, the operator supplies a reachable authenticated HTTPS companion endpoint and a separate companion bearer in the client secret store. One companion has one creator and installation; workflow or chat identities do not establish separate delegated users.

Exact local package, credential and native client instructions · Read-only public configuration template

Source paths in those instructions refer to the matching checkout supplied by your deployment operator. No public package or marketplace release is assumed. Free setup remains available; protected execution requires proof.actions and the appropriate role and scopes. Payments are currently unavailable. Provider usage may have separate charges.

Connection acceptance comes before a coverage claim

This distribution profile is separate from native runtime enforcement. Check the exact client version, transport, authentication, and tool surface with the operator. No marketplace listing or automatic interception is implied.

Setup instructions for this profile come from the SDK documentation your deployment operator provides.

  1. Configure a dedicated test connection with minimum scopes. Never paste a runtime secret into a public workflow or repository.
  2. Discover the tools and allow only the intended tool set. Confirm the exact transport supported by your installed client.
  3. Make one harmless managed call. Check denial and revoked credentials; a client that continues after a failed policy hook does not enforce that hook.
  4. Inspect the action ID in Praesidia. Report whether the test covered a managed call, native interception, or observation only.
  • Only explicit tools on the configured Praesidia companion are governed; unrelated native tools remain outside this boundary.
  • Packages are local release candidates. Real API/backend datastore installation-bound acceptance is pending the combined customer run; publication and deployed customer workspaces need separate acceptance.
  • One companion uses one operator-configured creator and installation. It does not infer end-user delegation from a workflow or chat identity.
  • Acceptance invokes the actual node execute interface with a synthetic n8n execution context; a deployed n8n editor, credential store and workflow scheduler have not been exercised.
  • Exactly one workflow item is accepted per invocation. Host retries must remain disabled; uncertain effects are read back without resend.

Alternative: earlier narrow source example

This separate example is not the managed companion setup above and does not establish an installation-bound connection. Preserve its narrower scope when evaluating it.

Download n8n-protected-http.workflow.json · All source instructions

Provide your operator's endpoint, registration, and credential reference. No secret belongs in these files. Preparation stops for review. Resume is a separate explicit phase gated on a fresh approval read. Configuration and isolated fixture checks do not establish a completed client authentication run.

Set up this alternative

Import n8n-protected-http.workflow.json into a disposable workflow. It uses manual trigger 1, Edit Fields 3.4, Code 2, If 2.2, and HTTP Request 4.2 node formats. It remains inactive and has no webhook or schedule. Replace the credential reference on all four HTTP nodes with an n8n Header Auth credential for Authorization: Bearer <personal caller credential>. Keep the value in n8n's credential store. The credential needs a real user, agents:invoke, workflows.execute, and the organization's proof.actions feature. The target must be registered by the deployment operator. Free registration alone does not supply those privileges.

  1. Edit public fields in Request settings: API origin, organization, registered target ID, harmless body, and a unique stable workflow run ID. Leave "phase": "prepare" and "resumeConfirmed": false.
  2. Run manually. Prepare and stop for review returns the action ID, approval ID, and request commitment. This branch ends without dispatch. Retain the exact target, body, and checkpoint alongside that response. A separate authorized human reviews the approval in Praesidia.
  3. After review, copy the original approval ID and original request commitment into Request settings. Keep the target/body/checkpoint unchanged. Select "phase": "resume" and "resumeConfirmed": true explicitly, then run manually again.
  4. The workflow reads the owned checkpoint. Pending, denied, expired, already consumed, or missing-approver states do not reach resume. A mismatched ID/commitment raises an error. The backend independently checks the original requester, tenant, exact request binding, live authority, and approval atomically before dispatch; this client check is not the security boundary.
  5. Review Read committed outcome and the action's actual evidence. If resume has a timeout or transport error, stop and read the existing checkpoint before considering another attempt. Never change a request under an existing approval or automatically retry a possibly dispatched effect.

The checkpoint runtime is custom; this example is an explicit HTTP workflow and makes no native n8n agent-tool interception claim. It does not depend on n8n's MCP transport. The current MCP Client Tool documentation labels its endpoint SSE, so Streamable HTTP compatibility must be separately tested.

Public request/response contracts are the Praesidia Protected HTTP Execution API, and node definitions are pinned for validation to n8n-nodes-base@2.15.1 with n8n-workflow@2.15.0. Imported execution/authentication against your n8n deployment remains a separate acceptance step.

Local SDK setup · Inspect evidence · Runtime catalog