Privent
Runtime Data Control for n8n Workflows
97 followers
Runtime Data Control for n8n Workflows
97 followers
Control what your AI workflows can access, send, and remember. Privent classifies the data your n8n workflows send to LLMs and MCP tools, decides what your policy allows, then enforces it: allow, mask, tokenize, or block.
Every decision produces evidence you can hand to an auditor. Official n8n integration, live today.
Built for teams that need proof, not just prevention.
This is the 2nd launch from Privent. View more
Privent 2.0
Launched this week
AI agents send raw data to LLMs on every run: emails, records, API keys, secrets. n8n's own Guardrails node can redact that, but redaction is permanent, the data never comes back.
Privent tokenizes PII and secrets before they reach the LLM, then reverses it safely at a trusted sink. Official n8n Integration Partner, live today. Local mode runs fully offline.
Built for teams running agent workflows in production who cannot afford a single leaked record.
Free Options
Launch Team
the reversible-tokenization vs permanent-redaction distinction is the actual pitch here, but it made me wonder about a specific failure mode - if the LLM doesn't just echo the token back verbatim but paraphrases around it in its response (rewrites the sentence, changes word order, summarizes multiple tokenized fields into one line), can the reversal still find and swap back the original values, or does detokenization depend on the token surviving untouched in the output?
@galdayan This is exactly the right edge case to probe.
Detokenization depends on the token surviving intact
in the output. If the LLM paraphrases around a token
or summarizes multiple tokenized fields into a single sentence,
the reversal fails for those specific values.
We handle this in a few ways. For use cases where
the LLM output needs to be human-readable with
original values restored, we scope tokenization
to fields that are unlikely to be narrated back
(identifiers, codes, structured references)
rather than fields that are likely to appear
verbatim in generated prose.
For fields where paraphrase risk is high,
the safer path is to pass them out-of-band entirely,
inject them back post-LLM rather than tokenizing
through the model call.
The reversal-dependency on token survival
is a real constraint and we document it as such.
The architectural answer is knowing which fields
to tokenize versus which fields to route around the model.
Happy to walk through how we handle this
in specific workflow patterns if that would help.
@asilozyildirim makes sense - so field classification really has to happen at design time, not runtime. for a workflow that evolves over months (new nodes, new fields flowing through), is there a way to flag a newly added field that should've been routed out-of-band before it ships, or does that rely on the workflow author re-auditing the schema periodically?
@galdayan Good question, and it's the right one for a node-based model. Worth splitting two things first. Classifying the value, is this content sensitive, happens at runtime, we scan what actually flows through, so a new value in a field we already cover is caught live. What is design-time is coverage, which fields and paths route through us at all. Your drift scenario is exactly the coverage side, and you are right that it is the weak spot: add a node that sends data down a path that never touches our nodes, and by default we do not see it.
Two layers on how we handle that. Today, the thing that keeps it from being pure "remember to re-audit" is the audit trail. Every egress and every sink gets logged and we compute an egress-coverage number, so a new node sending data somewhere unprotected shows up as a new sink and coverage drops. That is automatic drift detection, but I will be straight, it is after the fact, not a pre-ship block.
The real fix for "cover new fields without re-auditing" is to stop relying on per-path design-time config at all, and we just finished building exactly that: an in-engine interceptor that sits on every tool call and egress by default, shipping very soon. Once it is in the engine, a newly added node is in scope automatically, scored the moment it runs, with nobody re-wiring anything. Design-time config becomes the exception, not the requirement.
On flagging before it ships specifically: the signal you would gate on already exists today, the coverage number plus new-sink detection are queryable, so a pre-deploy check against them is doable now, and with the in-engine layer landing, new paths get picked up automatically at runtime instead of needing a manual re-audit. A turnkey schema-diff gate that flags a new unclassified field at PR time is the next step on top of that. Happy to go deeper on any of these.
@gorkemyagci appreciate the honesty on "after the fact, not a pre-ship block" - that distinction matters more than most vendors admit to. on the turnkey schema-diff gate you mentioned as next step: in the meantime, is the coverage number + new-sink detection exposed via an API a team could wire into their own CI today, or is that still something we'd have to poll/scrape from a dashboard until the gate ships?
Short sweet and solves a very real problem. Congrats for shipping 🙌 one question how does Privent handle structured JSON payloads where secrets or PII are nested deep inside dynamic key-value pairs?
@vikramp7470 Great question.
Privent's detection runs on the serialized payload, not just
top-level fields. For nested JSON, ACARS combines structural
pattern matching (regex + Luhn + IBAN on extracted string values)
with NER and semantic scoring across the full flattened key-value
space.
Deeply nested secrets like API keys or tokens are caught
at the regex layer regardless of nesting depth.
PII in dynamic key names is trickier. We use
value-based classification rather than key-name heuristics,
which means an unexpected key like "x_ref_id" holding an SSN
still gets flagged on the value.
Where it gets genuinely hard: highly dynamic schemas where
the same key holds different data types across calls.
We handle this with session-level context scoring
rather than per-call isolation, which improves accuracy
on polymorphic payloads.
Happy to go deeper on the architecture if useful.
Quick tool for the PH community!
Before setting up Privent, if you want to test whether your current n8n workflows are actually exposing sensitive data, we built a free n8n Risk Scanner.
No setup required—get your instant report here:
👉 https://www.privent.ai/get-free-report/run?ref=PRODUCTHUNT
Let us know what risk score you got! 👇