Skip to main content

Data handling questions

What an inline LLM security layer can see, whether prompt content is retained or used for training, and which of those answers this site does not yet publish.

Published ·4 min read·SecureAI Guard
data handling
privacy
retention
FAQ

Every question on this page has the same root: a product that inspects prompts necessarily processes them, so "what does it see, and what happens to it afterwards" is the whole of the data-protection review. Where this site does not publish an answer, the answer below says so rather than reaching for a reassuring adjective.

Does SecureAI Guard see the contents of our prompts?

Yes, necessarily. Inspection means processing the content of prompts and completions, including whatever the application put in them — retrieved documents, conversation history, tool definitions and tool results. There is no version of this product that does its job without seeing that content, and a vendor in this category that implies otherwise is describing something else.

That statement is published on the security page and it is deliberately the first thing said there. A security layer that could not read the prompt could not detect anything in it.

Does that include our retrieved documents and conversation history?

Yes. Anything the application places in the model request is in the model request. In a RAG application that means the retrieved chunks; in a chat application it means the history the application replays on every turn; in an agent it means the tool definitions and the results of tool calls.

This is worth stating explicitly during a review because teams frequently model the prompt as "what the user typed". By volume it usually is not: retrieved context and replayed history are normally the larger part of the payload and the part more likely to contain regulated data. How LLM applications leak sensitive data is an inventory of the paths that follow from that.

Is prompt content retained, and for how long?

This site does not publish a retention period, and this page will not invent one. Retention, what is logged versus what is stored, and whether anything is kept after a decision is made are the questions the trust page exists to answer with dates against them — it is noindex today precisely because those answers are still marked as outstanding rather than filled in with plausible-sounding defaults.

What you should do with that: ask for retention in writing, ask separately about metadata and about content, and ask what a deletion request actually deletes. If the answer is not in the contract it is not a commitment. If retention is a gating requirement rather than a preference, see the next question.

Is our content used to train models?

The site publishes no statement that it is, and no statement that it is not, so treat the absence as an open question rather than as an assurance in either direction. Get it in the agreement. "Zero data retention" and "not used for training" are different commitments and are frequently conflated — see zero data retention for the distinction and for what the phrase does and does not cover.

We would rather leave this visibly unanswered than answer it from marketing instinct. A security vendor caught overstating its own data handling loses the deal and the credibility together.

Can we run it so that no prompt content leaves our network?

Yes — that is what on-premises deployment is for, and it is the only answer that fully removes this class of question. When the layer runs inside your boundary, retention, residency and subprocessor questions about the hosted service stop applying to it, because there is no hosted service in the path.

For the hosted service, data residency records what is settled and what is not. It is deliberately unpublished to search engines until the open items are answered.

Does it redact PII before the model sees it?

PII redaction is one of the controls this product publishes — see features — but the specifics that matter to a reviewer are not on this site: which entity types are recognised, whether detection is pattern-based or model-based, what the failure mode is on a near-miss, and whether redaction is reversible for the application that needs the original value back.

Ask for those four. PII redaction for LLMs explains why each of them changes the answer, and it is written to be usable against any vendor in the category rather than as a pitch for this one. The short version: redaction that is not reversible breaks half the use cases, and redaction that is reversible has to store the mapping somewhere, which puts you straight back to the retention question above.

Who are the subprocessors for the hosted service?

Not published on this site today. The subprocessor list belongs on the trust page alongside the DPA and the audit position, and it is one of the items that page marks as outstanding.

A subprocessor list is not a formality for this product category. A security layer in the path of prompt data inherits every downstream processor into your own transfer analysis, so an unnamed list is a genuine blocker for a GDPR assessment rather than a paperwork delay.

Is prompt content personal data under the GDPR?

Usually, and you should assume so until you have evidence otherwise for a specific application. Prompts routinely contain names, contact details, case identifiers, health or employment context, and retrieved documents that were personal data before they were retrieved. Nothing about being inside a model request changes their status.

GDPR and LLM data handling works through what follows: the lawful-basis question, why a DPIA is usually triggered for novel large-scale processing, and where the transfer analysis lands when the model provider is outside your jurisdiction. It cites the primary sources and records when each was checked.

Where to go next