The safest data is the data you never keep. We explain what zero data retention really means for an LLM security layer, the tradeoffs it involves, and why memory-only processing is a deliberate design choice.
There is an uncomfortable truth about any system that inspects sensitive data: the system itself becomes a place that sensitive data lives. A security layer that scans your prompts for injection and PII is, by definition, handling some of the most sensitive text in your stack. If it stores that text, it has just become another database an attacker would love to reach, another thing to breach, another scope for a regulator to ask about. The cleanest answer to "how do you protect the data you process?" is the one we chose: we do not keep it. Zero data retention is not a feature we bolted on; it is a design decision about where the safest place for your data is, and the answer is "not in our hands a moment longer than necessary."
What zero data retention actually means
The principle is simple to state: data is processed in memory to do its job, and then it is gone. It is not written to disk, not persisted in a database, not retained for later. The processing happens, the verdict is returned, and the input is not kept. We sometimes describe this as memory-only processing, and the point of it is that you cannot breach, leak, or be compelled to produce data that does not exist.
This matters most for a layer like ours precisely because of what it sees. To detect a prompt injection or redact a piece of PII, the security layer has to look at the content, the very content you most want protected. A retention-by-default design would mean your most sensitive text accumulating inside your security tool, which is a strange and self-defeating place for it to end up. Zero retention removes that accumulation entirely.
The tradeoffs, honestly
We are not going to pretend zero retention is free, because every architectural choice has costs and you deserve to know them.
Not retaining data means you cannot later go back and inspect the raw content of a past request from the processing layer, because it was never stored there. That is the entire point, and it is a real constraint. The resolution is to separate concerns: the security layer processes without retaining, while you keep whatever audit and logging your own compliance requires, under your own control, with your own retention policy. The visibility you need for governance lives where it should, with you, rather than being duplicated inside a vendor's store. This is a deliberate division, you own your records; we do not become a second copy of your sensitive data.
It also places a premium on getting the processing right in the moment, since there is no stored corpus to reprocess. We consider that a healthy pressure, not a drawback.
Why this pairs with data residency and sovereignty
Zero retention is one pillar; where processing happens is another. For organisations under the GDPR, KVKK, or sector rules, it is not enough that data is not stored, it also matters where it is handled and under whose jurisdiction. That is why we pair memory-only processing with EU data residency and flexible deployment, so that the data that does pass through is processed in the region and under the controls your obligations require, and, for the strictest environments, can be handled entirely within your own boundary.
What to look for in any security layer
- Memory-only processing. Confirm that the layer inspecting your sensitive data does not persist it. Ask the direct question.
- Clear separation of audit from processing. You should own your logs and retention; the processing layer should not quietly become a second copy of your data.
- Data residency you can specify. Where processing happens should match your regulatory footprint.
- Deployment flexibility. For the most sensitive workloads, the option to keep processing inside your own environment, including air-gapped, is the strongest form of this control.
Frequently asked questions
If you don't store data, how do you improve detection? Improving detection does not require retaining your specific traffic. Our detection evolves from dedicated adversarial research and datasets, not from keeping customer content. Your data does its one job and leaves; it is not raw material for our roadmap.
Don't I need stored data for compliance and audit? You often do, and you should keep it, under your control, with your policy. The point of zero retention in the processing layer is that the audit trail lives with you rather than being duplicated inside a vendor. Separation of concerns, not absence of records.
Is this the same as being GDPR compliant? It is a strong contributor, not the whole of it. Zero retention plus data residency plus appropriate controls is how the pieces fit together. Not storing data removes an entire category of risk, which makes the rest of compliance simpler.
How Promptention helps
Zero data retention is how we operate by design. Our processing is memory-only, your data is inspected to do its job and not kept, and we pair that with EU data residency and deployment options up to fully air-gapped on-premise, so the most sensitive workloads can be secured without your data ever leaving your boundary. The safest data is the data we never hold, and we built the product so that we never have to.
Promptention operates with zero data retention and memory-only processing, with EU data residency and on-premise deployment options.
