n8n node — an authorization checkpoint you can drag

A team with no Python can gate an agent action:

AI Agent  →  [Vavitien]  →  Send Email
                  └ denied →  notify a human

The signing key stays inside your n8n instance. The action, its details and your policy id go to the service; the key does not.

Status: built, exercised and packaged — not published. It is not on npm, not on the website, not in LAUNCH_GATES.md, and not mentioned to counsel. Publishing is a deliberate act — see Before publishing below.

TypeScript with a dist/ build as of 2026-08-20, which is what n8n's registry expects; the tests run against the COMPILED output, so they guard the artifact that would actually ship rather than a source that no longer runs.

What is proven, and by what

node    integrations/n8n/test/node_smoke.js          # routing, stubbed service
.venv/bin/python integrations/n8n/test/verify_against_sdk.py   # signature vs the SDK
.venv/bin/python integrations/n8n/test/round_trip.py           # a real server, real HTTP
node    integrations/n8n/test/n8n_contract.js        # n8n's own engine

| Claim | Evidence | |---|---| | A proof signed in JavaScript verifies in the Python SDK | verify_against_sdk.py — 8 checks | | key_id derivation agrees across the two languages | same | | Tampering is caught: payload, action, audience, signature byte, added key | same — five corruptions, five rejections | | The same proof twice is replay_detected | same | | Allows and denies route to separate outputs | node_smoke.js | | A real server allows, denies, and refuses a foreign audience | round_trip.py — 6 checks over real HTTP | | An unknown policy fails closed | same | | A bad credential throws instead of masquerading as a denial | same | | n8n builds a workflow with the node and resolves its parameters | n8n_contract.js — n8n's own Workflow engine | | Both secret fields are masked in the credential form | same | | Every parameter default is declared, not implied by execute() | same |

The last two files are new and each found a real defect on its first run — see below. Every check in them was verified by mutation: delete the icon, unmask the private key, reduce the outputs to one, remove a default, and the matching assertion fails.

round_trip.py starts vavitien.asgi on a loopback port with SQLite backends and an ordinary policy (an amount ceiling and an audience), registers the JavaScript agent's public key through the server's own /register_key, and then drives the node exactly as n8n does. The public key is derived by the JS signer, not by Python — deriving it on the Python side would have tested Python's derivation twice and the node's not at all.

Two defects these found

The verify path was wrong for self-hosters. The hosted service exposes /v1/verify; a self-hosted vavitien.asgi server exposes /verify. The node had the hosted path hardcoded, so anyone pointing it at their own server — most of the audience for a no-code block — got a 404 with nothing to explain it. It is now a credential field with both options.

A description said "resource id". n8n's house style is ID, and their registry review lints for it.

What is still NOT proven

• A workflow author still cannot obtain a signing key without writing code. The credential needs an ed25519 private key ("64 hexadecimal characters") for an agent that is already registered. Nothing in the node mints one, and the console mints only an in-memory demo agent and never displays the private half. So the no-code claim has a code-shaped hole in the middle of it: this node removes the days of SDK integration and leaves a five-minute wall a non-programmer cannot climb. The console already shows an API key exactly once during guided onboarding; agent keys need the same treatment. Close this before publishing, or the premise is false.
• Never run inside a live n8n instance. n8n_contract.js uses n8n's real Workflow engine and node-types registry, which is a large step past a hand-rolled fake, but it is not the same as installing the package into a running n8n and dragging the node onto a canvas.
• Never run against the hosted API. The round trip is against a local vavitien.asgi server. The beta endpoint is IP-restricted, and no end-to-end signed decision through the public endpoint has been demonstrated for any client.
• No retry or timeout policy. A slow or flapping service surfaces as a workflow error; n8n's own retry settings are the only mitigation today.
• Not tested against n8n version drift. Written to node API version 1.

Deviations from n8n's linter

npm run lint runs eslint-plugin-n8n-nodes-base, the ruleset their registry review uses, against the TypeScript sources. Two rules are knowingly unsatisfied, and both are recorded here and in the code rather than suppressed in config:

cred-class-field-documentation-url-miscased wants documentationUrl camelCased, and its autofix rewrites the URL into httpsVavitienComDocs. It directly contradicts cred-class-field-documentation-url-not-http-url, which demands a URL. The first rule's own description settles which applies: "Only applicable to nodes in the main repository." It is for nodes inside n8n's monorepo, where the field is a docs slug. This is a community node published to npm, so the URL form is correct. Do not run --fix on the credentials file.

node-class-description-outputs-wrong wants a single output. The rule's own description reads "must be one, or two for If node, or four for Switch node" — it is keyed to node NAMES, not to capability, and n8n fully supports multi-output nodes. Two outputs is the entire point here: a denial should route somewhere useful rather than throw, so the workflow author can send it to a human. Do not "fix" this.

node-filename-against-convention is now satisfied — it wanted Vavitien.node.ts, and the source is TypeScript as of 2026-08-20.

Before publishing

1. ~~Convert to TypeScript with a build step~~ — done 2026-08-20. npm run build compiles to dist/ and copies the icon; prepublishOnly runs the build and the tests, so a broken package cannot be published by accident.
2. Decide the npm name and take it: n8n-nodes-vavitien. Note the SDK's PyPI name was already lost once — vavitien was deleted and cannot be reused.
3. Point documentationUrl at a page that exists. It currently names https://vavitien.com/docs, and the site is not hosted yet.
4. Prove one round trip against the hosted API from an allowlisted address.
5. Only then: the website may link to it. A visitor arriving from n8n's registry lands on a site whose console screens are marketing mockups — publishing the node before that is resolved sends people to the weakest page we have.

Keep it if

• A real prospect says some version of "we run our agents in n8n and cannot write Python." One is enough; their tool list becomes the template.
• The first integration shows the gating decision fits in six form fields. If a real policy needs more, the block is a toy and the SDK is the product.

Delete it if

• The first three customers all have engineers. Then this serves nobody, and every week it stays it accrues maintenance against n8n's release cadence.

The thing that would be worst to get wrong

Someone will assume this checks whether the refund is deserved. In code the developer knows they are signing a claim; in a drag-and-drop block that intuition is absent. The node carries a notice field saying so in the UI — Vavitien checks the action against rules you wrote and records that the check happened; it cannot tell whether the action is a good idea.

Do not remove that notice to save vertical space. It is the self-attestation limit, which the claims register requires wherever verification is described, rendered for an audience that has never read the register.