Excellent walkthrough of context propagation in async retrieval. The ManagedExecutor detail is the kind of thing that bites in production when you forget request scopes don't automatically transfer toworker threads. Had a similar issue with scoped beans in background tasks and it took forever to debug because it worked fine in sequential flow.
Hi Markus, thanks for the great article! I was studying your code, specifically the InputValidationGuardrail, and I have a question.
I noticed the patterns in the code seem to be in English. I was wondering: if an attacker tries to use a different language (like Portuguese or Italian) for the prompt injection, would the current guardrail implementation still be able to detect it?
The InputValidationGuardrail is not language-agnostic. The patterns are in English, which means a prompt injection in Portuguese, Italian, or any other language could bypass it.
This guardrail is meant to demonstrate where validation sits in the pipeline, not to be a complete security solution. Regex-based checks are fast, deterministic, and auditable, which is why they still have a place. But they only catch what you explicitly model.
In real systems, multilingual protection requires semantic validation, not string matching. Typically:
- embedding-based intent similarity
- a small, constrained LLM classifier
- or a combination of rules and semantic checks
The important part is that the architecture doesn’t change. You can swap the guardrail implementation without touching retrieval or authorization.
And even if input validation is bypassed, the JWT-scoped retrieval layer still holds. The model never sees data the user isn’t allowed to access.
Let me see if I can cover this in an upcoming article!
Excellent walkthrough of context propagation in async retrieval. The ManagedExecutor detail is the kind of thing that bites in production when you forget request scopes don't automatically transfer toworker threads. Had a similar issue with scoped beans in background tasks and it took forever to debug because it worked fine in sequential flow.
Hi Markus, thanks for the great article! I was studying your code, specifically the InputValidationGuardrail, and I have a question.
I noticed the patterns in the code seem to be in English. I was wondering: if an attacker tries to use a different language (like Portuguese or Italian) for the prompt injection, would the current guardrail implementation still be able to detect it?
Hi Fernando,
The InputValidationGuardrail is not language-agnostic. The patterns are in English, which means a prompt injection in Portuguese, Italian, or any other language could bypass it.
This guardrail is meant to demonstrate where validation sits in the pipeline, not to be a complete security solution. Regex-based checks are fast, deterministic, and auditable, which is why they still have a place. But they only catch what you explicitly model.
In real systems, multilingual protection requires semantic validation, not string matching. Typically:
- embedding-based intent similarity
- a small, constrained LLM classifier
- or a combination of rules and semantic checks
The important part is that the architecture doesn’t change. You can swap the guardrail implementation without touching retrieval or authorization.
And even if input validation is bypassed, the JWT-scoped retrieval layer still holds. The model never sees data the user isn’t allowed to access.
Let me see if I can cover this in an upcoming article!
Thanks for your reply,
M
Great explanation, Markus! Thanks for clarifying that. Looking forward to the next post! :)