How to detect prompt injection in your LLM stack
The short answer
Senthex runs 26 input/output shields on every call at the proxy — prompt-injection and jailbreak patterns, PII, secret-leak and unicode-steganography checks — each returning a verdict, score and rule version, with a configurable action: log, warn, block or redact. It is pattern-based and best-effort, not exhaustive: OWASP ranks prompt injection LLM01 precisely because no filter catches everything.
How do you detect prompt injection in an LLM app?
You put a control on the path the untrusted text travels. Senthex is a reverse proxy, so every request and response passes through it before reaching the model and before returning to your app. On each call it runs its shields and records, per shield, what fired, the score, and the rule version. You choose the action per shield:
- log — observe in shadow mode without changing behaviour;
- warn — flag for review;
- block — refuse the call;
- redact — strip PII or secrets before the model sees them.
Detection at MVP is pattern-based, not a second LLM judging the first — that keeps the latency budget small and avoids a recursive attack surface.
What kinds of injection does it look for?
The shields target the common attack families:
- Jailbreaks and "DAN"-style overrides that try to cancel your system prompt;
- Persona hijacks that re-cast the model into another role;
- System-prompt and data exfiltration attempts;
- Multi-turn attacks that build across messages;
- Unicode steganography that hides instructions in invisible characters;
- Secret leaks (API keys, tokens) on the request and response side.
We wrote a hands-on guide to testing your own LLM against these, so you can see what gets caught before you rely on anything.
Why detect at the proxy instead of in the app or the provider?
Two reasons. First, jurisdiction and coverage: a proxy applies the control before any token leaves your environment, and gives you one place to detect across every provider you use (OpenAI, Anthropic, Mistral, Gemini, OpenRouter) with a single audit log. Second, the integration layer: provider-side guardrails (Bedrock, Azure Content Safety, Vertex) sit inside the provider's trust boundary and are worth keeping on — but they generally don't see attacks that exploit your integration, like injection via document upload or tool-call abuse. Keep provider guardrails on and put a control in front of them.
The honest limits
No detection layer is a guarantee, and we don't sell it as one.
- Best-effort, never exhaustive. Pattern-based detection has false positives and false negatives; a determined attacker can find gaps. That is the nature of LLM01.
- Defence in depth, not a silver bullet. Senthex is one layer — keep your prompt hardening, least-privilege tool design and human review.
- Not "Article 15 compliance". Shields are a technical control that maps to Article 15(5) cybersecurity (resilience to alteration); they don't make your system compliant with Article 15 on their own.
Where can you stop prompt injection?
| Property | App code only | Provider-side guardrails | Senthex proxy (in front) |
|---|---|---|---|
| Runs before any token leaves your jurisdiction | Yes, but you build and maintain it | No — inside the provider boundary | Yes — EU-hosted proxy in front of the model |
| One control across multiple providers | No | No — per provider | Yes — OpenAI, Anthropic, Mistral, Gemini, OpenRouter |
| Per-shield evidence in an audit log | Whatever you build | Limited | Verdict, score, rule version per call |
| Catches integration-layer attacks (doc upload, tool-call abuse) | If you wrote checks for them | Generally not | Targeted by dedicated shields |
| Exhaustive / a guarantee | No | No | No — best-effort (OWASP LLM01) |
Frequently asked questions
How do I detect prompt injection in my LLM application?
Put a control on the path the untrusted text travels. Senthex proxies every call and runs 26 input/output shields — prompt-injection and jailbreak patterns, PII, secret-leak and unicode-steganography checks — each returning a verdict, score and rule version, with a per-shield action of log, warn, block or redact. It's pattern-based and best-effort.
Is prompt-injection detection 100% reliable?
No, and no honest vendor will tell you otherwise. Detection is pattern-based and best-effort, with false positives and false negatives. OWASP ranks prompt injection LLM01 precisely because no filter is exhaustive. Use it as one layer of defence in depth, alongside prompt hardening and least-privilege tool design.
Why detect at a proxy instead of relying on my model provider's guardrails?
Keep provider guardrails on — they're useful. But they sit inside the provider's trust boundary and generally miss attacks on your integration layer (injection via document upload, tool-call abuse). A proxy in front applies controls before any token leaves your jurisdiction and gives you one audit log across every provider.
Can it redact PII before the model sees it?
Yes — redact mode strips detected PII or secrets from the request before it reaches the model. PII detection is best-effort and language-dependent; like injection detection, it's a control to reduce exposure, not a guarantee of perfect coverage.
Does using Senthex make me compliant with EU AI Act Article 15?
No single vendor does. Shields are a technical control that maps to Article 15(5) cybersecurity (resilience to attempts to alter use, outputs or performance), and the per-call record supports Article 12 record-keeping — but the conformity assessment and documentation are your work.
Test it against your own traffic
Start on the Free plan (1,000 requests/month, no card), point your base_url at Senthex, and watch the shields score real calls. If you run agents or MCP tools, read how injection cascades across agents next.