Prompt security vs. prompt injection

Why the confusion exists

Both terms describe controls around an LLM prompt. Both are commonly called "prompt security". They sit at the same architectural layer. But they protect against very different things, and conflating them leads to gaps in real threat models.

Prompt security — outbound privacy

Prompt security is concerned with what your application sends to the model provider. The risk is that you forward customer data, secrets, or internal identifiers to a third party that you do not fully control. The control is to detect and mask that data before the prompt leaves your perimeter.

• Threat: data exposure to a third-party provider
• Attacker model: typically none — the risk is your own behavior
• Control: detection, masking, redaction, routing, audit
• Where it lives: a gateway between your app and the provider

Prompt injection — inbound instruction hijacking

Prompt injection is concerned with adversarial input. An attacker hides an instruction inside data the model is asked to process — a customer email, a webpage, a file — and the model follows that instruction instead of yours.

• Threat: model executes instructions from untrusted input
• Attacker model: an external party crafting hostile content
• Control: input segmentation, output validation, capability limits
• Where it lives: prompt design, gateway, post-processing

Side by side

                    Prompt security        Prompt injection
Direction           Outbound (you → model) Inbound (input → model)
Risk                Data exposure          Instruction hijack
Attacker required   No                     Yes
Primary control     Masking, redaction     Isolation, validation
Affects compliance  Yes (PII, secrets)     Indirectly (data exfil)

Why you usually need both

A team that only masks PII is still vulnerable to an injected instruction that exfiltrates the rehydrated data. A team that only sandboxes instructions is still leaking customer records to the provider on every call. The two controls protect different stages of the same request.

How Privian fits

Privian addresses the privacy side: detection, masking, rehydration and audit. It does not currently defend against prompt injection. We say so on every page because conflating the two would give you a false sense of coverage. See Prompt Security for the product scope, and the concept page in the docs for the technical detail.

What Privian does — and does not do

Being precise here matters more than positioning. Privian today is a privacy-first LLM gateway focused on what leaves your stack, not on what an adversary tries to inject.

What Privian does

• Detects supported personal and sensitive values inside outbound prompts.
• Replaces detected values with deterministic placeholders before the prompt reaches the provider.
• Routes the masked prompt to your configured provider using your own credentials (BYOK).
• Rehydrates placeholders in the response on the way back so your application sees real values.
• Applies structural prompt-security checks at the edge and rejects requests that fail them with a structured error.
• Keeps no raw prompt or response bodies — only structural counters for observability.

What Privian does not currently claim

• Prompt-injection blocking — detecting or stopping adversarial instructions embedded in untrusted input.
• Jailbreak defense — preventing prompts engineered to bypass a model's safety behavior.
• Downstream model security guarantees — Privian cannot promise anything about how a third-party model behaves after the request leaves the gateway.
• General content moderation on responses.

If your threat model needs those controls, you will need a dedicated layer for them alongside Privian. For deeper category framing, see What is LLM security? and What is an LLM firewall?