Trust

Security at PulserNode

You are handing us a key to production. Here is every boundary we put around it, written the way we would want to read it about somebody else's product.

Last updated 21 August 2026Effective 21 August 20269 sections

1. What you are trusting us with

One credential: the API key to an n8n instance you run. That key can read and change production workflows, which is exactly why the rest of this page exists.

The key is envelope-encrypted with contextual authenticated data, decrypted only at the moment of an outbound call to your instance, and never returned to a browser or written to a log. Disconnecting an instance revokes our access immediately.

2. Workspace isolation

Every request, row, queue job, distributed lock, retrieval query, audit event, and usage entry carries the authenticated workspace. Application checks come first, and PostgreSQL row-level security sits underneath as a second boundary rather than a substitute.

That means a bug in one layer is not automatically a cross-tenant data leak, which is the only version of isolation worth advertising.

3. Outbound calls to your instance

A control plane that fetches customer-supplied URLs is a server-side request forgery problem waiting to happen. Ours is constrained on every axis:

  • HTTPS only, on approved ports.
  • Every DNS answer must resolve to a public address, re-resolved per request so a record cannot flip to an internal IP between check and connect.
  • Redirects are handled manually rather than followed blindly.
  • The request path is preserved against its origin, so it cannot be rewritten mid-flight.

4. Redaction before storage

Diagnostics are recursively redacted before anything durable is written. Credential values and ordinary business payloads never enter the model, so they are not in the database, not in a prompt, not in a log, and not in a snapshot.

Encrypted raw diagnostic samples that survive redaction expire after 30 days. Audit events are kept for a year.

5. The AI boundary

Workflow content, error text, documentation, and fetched web text are all treated as untrusted data, because prompt injection is a real attack and not a theoretical one.

  • Deterministic classification runs before any model is consulted.
  • Model output is parsed into an allowlisted structured patch. Raw generated code and arbitrary API calls are rejected by the schema, not by a warning in the prompt.
  • Native changes require your explicit approval before they reach your instance.

6. Bounded repair

Guard replays workflows live, which can create irreversible third-party effects. So it requires explicit consent, a passing baseline, and idempotent test contracts before it runs at all.

  • Three attempts, then the circuit opens.
  • A fifteen-minute deadline per repair.
  • One repair worker per workflow, enforced by a distributed lock.
  • Rollback to the previous snapshot on any regression.

Full detail is in the repair section.

7. Billing integrity

Webhook signatures are verified in constant time against the raw request body, and every event is recorded by its event ID before it is applied. A replayed or forged billing event does not change your subscription.

8. Supply chain

Container images and packages are pinned, and dependency install scripts are explicitly allowlisted rather than run by default. A transitive dependency cannot execute arbitrary code at install time on our builders.

9. Reporting a vulnerability

Please do not open a public issue. Send impact, affected surface, reproduction steps, and a suggested mitigation to security@pulsernode.com.

Never include live n8n API keys, OAuth tokens, credential values, workflow payloads, customer identifiers, or decrypted diagnostics in a report. We do not need them to reproduce a finding, and holding them creates a second incident.

Good-faith research that follows our acceptable use policy will not be met with legal action.

The automation you keep putting off ships tonight.

Connect your n8n, describe the first one, and get back to your actual work.