Detect prompt injection without exposing content.
Detect prompt injection, where invisible Unicode and hidden commands make what the human saw diverge from what the AI reads, by having Lemma hash the normalized input and verify at runtime the visible_eq between the intended and received input — catching tampering without disclosing the content.
Three voices from the front line.
- AI engineering / operations
“We want a way to detect prompt tampering via invisible characters and hidden commands”
- Security
“We need a layer that structurally blocks AI attacks coming through user input”
- Compliance
“We want to prove the input the AI processed matches what the user intended”
Hand over the source, or just the facts?
Nothing changes on the floor. Everything changes for the receiver.
① Your team just saves, as always.
- The usual step
- Fill in the record and save
- On save
- A proof is attached (API, behind the scenes)
- The document itself
- never sent
② They just open a link.
- Proven fact
- what the human saw equals what the AI read
- the prompt and input content itself
- not shown
- Login / keys
- not needed
- The document stays private — the record itself is never sent or disclosed.
- Independent verification — the receiver just opens a link. No account, no keys.
- Edits are detected — even a one-character edit fails verification.
The input is converted to a normalized form (Unicode NFC, with whitespace and invisible-character handling defined) and its fingerprint is committed. Before inference, the visibleEq between "what the human intended" and "what the AI receives" is verified at runtime; if they differ, execution stops first. Without disclosing the input content, the absence of tampering can be independently verified.
See the technical details ↗Why the usual methods fall short.
Only work that needs all three at once — pass without exposing, independent verification, tamper-evidence — is Lemma's domain.
| Method | Pass without exposing | Independent verification | Tamper-evident | What happens |
|---|---|---|---|---|
| Access control / permissions | △ | ✗ | ✗ | “Someone inside could have edited it” remains possible |
| Masking / redacted copies | △ | ✗ | ✗ | Redaction work grows; the original is still unproven |
| Encrypt and store / send | ✓ | ✗ | ✗ | To verify, the receiver needs it disclosed after all |
| WAF / input monitoring only | △ | ✗ | ✗ | Detection only — the receiver still cannot verify independently |
| Lemma (ZK proof)the only one with all 3 | ✓ | ✓ | ✓ | The receiver just opens a link |
How it works — and how to start.
We help design disclosure scope and retention, run the PoC, and support production.
Start with a 30-minute call.
Tell us one workflow worried about AI attacks via user input, in the first 30 minutes. No disclosure of the input content required.
Find the case that matches your industry and problem
Browse all 36 use cases →TRY LEMMA
Run it yourself.
No sales call needed — start hands-on with Lemma's products.