--- title: Guardrails with OPA Policies in Quarkus LangChain4j description: A tutorial on implementing hybrid input guardrails for LLM-based Quarkus applications using Open Policy Agent (OPA) policies compiled to WebAssembly. The... canonical: https://daily.dev/posts/guardrails-with-opa-policies-in-quarkus-langchain4j-takmwud8c twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Guardrails with OPA Policies in Quarkus LangChain4j | daily.dev og:description: A tutorial on implementing hybrid input guardrails for LLM-based Quarkus applications using Open Policy Agent (OPA) policies compiled to WebAssembly. The... og:url: https://daily.dev/posts/guardrails-with-opa-policies-in-quarkus-langchain4j-takmwud8c og:image: https://api.daily.dev/og/posts/tAkMwUD8C.png og:image:alt: Guardrails with OPA Policies in Quarkus LangChain4j og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Guardrails with OPA Policies in Quarkus LangChain4j **[Quarkus](https://daily.dev/sources/quarkus)** · 13 min read · 1 upvotes · 0 comments ## Summary A tutorial on implementing hybrid input guardrails for LLM-based Quarkus applications using Open Policy Agent (OPA) policies compiled to WebAssembly. The approach combines fast deterministic pattern matching (sub-millisecond, zero cost) with optional LLM escalation for ambiguous cases. OPA Rego policies detect prompt injection attacks via exact string matches and regex patterns, and when signals are weak, a custom OPA builtin delegates scoring to a secondary LLM. The Rego policy is compiled to Wasm using the Styra OPA Java SDK, integrated into a Quarkus LangChain4j InputGuardrail implementation. The post includes full Java code, Rego policy snippets, build commands, and live test examples showing all three code paths: instant block, instant allow, and LLM-escalated block. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How can I reduce LLM token costs and latency when detecting prompt injection attacks in a Quarkus LangChain4j application? Use deterministic pattern matching as a first line of defense before calling an LLM. An OPA Rego policy compiled to WebAssembly scores prompts against exact phrase and regex patterns; scores above 0.7 block instantly and scores of 0.0 allow instantly, both without any LLM call, costing under a millisecond and $0. Only ambiguous scores between 0 and 0.7 trigger a custom llm_score builtin that delegates to the LLM for deeper analysis. _daily.dev surfaces practical guardrail patterns for teams hardening LLM apps against prompt injection._ ### How do you call an LLM from within an OPA Rego policy evaluated as WebAssembly in Java? You register a custom Rego builtin function, such as llm_score, using the Styra opa-java-wasm SDK's OpaPolicy.builder().addBuiltins(OpaBuiltin.from(...)) API, mapping the builtin name to a Java lambda that invokes an existing LLM detection service and returns a score as a DoubleNode. The Rego policy must declare the builtin in a capabilities.json file passed to the opa build -t wasm command so the OPA compiler accepts the custom function. _developers wiring LLM fallbacks into policy engines can track integration patterns like this on daily.dev._ ### What is the performance and cost difference between LLM-only, Wasm-only, and hybrid prompt injection guardrails? LLM-only guardrails vary by model and deployment but commonly take seconds and incur per-call token costs, are probabilistic, and act as a black box requiring LLM API availability. Wasm-only guardrails run sub-millisecond, cost $0, are deterministic, and are auditable since the policy is a readable, version-controlled Rego file. A hybrid approach only pays the LLM's latency, cost, and black-box tradeoffs when the deterministic Wasm score is inconclusive. _comparing guardrail architectures for AI apps is easier when tradeoffs like these are tracked on daily.dev._ ## Similar posts on daily.dev - [How to Govern AI-Generated Infrastructure with Policy as Code and OPA \[Full Handbook\]](https://daily.dev/posts/how-to-govern-ai-generated-infrastructure-with-policy-as-code-and-opa-full-handbook--cgwuxyobm) · freeCodeCamp · 1 upvotes · 0 comments - [Governance That Ships: Embedding Policy as Code Into Your System of Record](https://daily.dev/posts/governance-that-ships-embedding-policy-as-code-into-your-system-of-record-k5du9rdlm) · JFrog · 0 upvotes · 0 comments - [What Is Open Policy Agent? Best Practices and Use Cases](https://daily.dev/posts/what-is-open-policy-agent-best-practices-and-use-cases-wqsdtv48j) · Orca Security Blog · 0 upvotes · 0 comments - [Guardrails: Enterprise safety shields with Llama Stack](https://daily.dev/posts/guardrails-enterprise-safety-shields-with-llama-stack-pyyaptds7) · Red Hat Developer · 1 upvotes · 0 comments - [AI Guardrails And Output Validation 2026: Production Patterns](https://daily.dev/posts/ai-guardrails-and-output-validation-2026-production-patterns-ybfm5oylu) · Alex CloudStar · 0 upvotes · 0 comments --- Tags: [#webassembly](https://daily.dev/tags/webassembly), [#prompt-injection](https://daily.dev/tags/prompt-injection), [#quarkus](https://daily.dev/tags/quarkus), [#langchain4j](https://daily.dev/tags/langchain4j) [View this post on daily.dev](https://daily.dev/posts/guardrails-with-opa-policies-in-quarkus-langchain4j-takmwud8c) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Guardrails with OPA Policies in Quarkus LangChain4j","url":"https://daily.dev/posts/guardrails-with-opa-policies-in-quarkus-langchain4j-takmwud8c","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/guardrails-with-opa-policies-in-quarkus-langchain4j-takmwud8c"},"datePublished":"2026-07-10T13:01:06.163Z","dateModified":"2026-09-14T07:48:43.133Z","description":"A tutorial on implementing hybrid input guardrails for LLM-based Quarkus applications using Open Policy Agent (OPA) policies compiled to WebAssembly. The...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/e7ab97eced21a845aaca4e155a5e5171?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/e7ab97eced21a845aaca4e155a5e5171?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Quarkus","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Quarkus","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/8adf82d719bb4a9492f44a28a27fd396","url":"https://daily.dev/sources/quarkus"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/guardrails-with-opa-policies-in-quarkus-langchain4j-takmwud8c","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"webassembly,prompt-injection,quarkus,langchain4j","timeRequired":"PT13M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Quarkus","item":"https://daily.dev/sources/quarkus"},{"@type":"ListItem","position":3,"name":"Guardrails with OPA Policies in Quarkus LangChain4j"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/guardrails-with-opa-policies-in-quarkus-langchain4j-takmwud8c#faq","mainEntity":[{"@type":"Question","name":"How can I reduce LLM token costs and latency when detecting prompt injection attacks in a Quarkus LangChain4j application?","acceptedAnswer":{"@type":"Answer","text":"Use deterministic pattern matching as a first line of defense before calling an LLM. An OPA Rego policy compiled to WebAssembly scores prompts against exact phrase and regex patterns; scores above 0.7 block instantly and scores of 0.0 allow instantly, both without any LLM call, costing under a millisecond and $0. Only ambiguous scores between 0 and 0.7 trigger a custom llm_score builtin that delegates to the LLM for deeper analysis. daily.dev surfaces practical guardrail patterns for teams hardening LLM apps against prompt injection."}},{"@type":"Question","name":"How do you call an LLM from within an OPA Rego policy evaluated as WebAssembly in Java?","acceptedAnswer":{"@type":"Answer","text":"You register a custom Rego builtin function, such as llm_score, using the Styra opa-java-wasm SDK's OpaPolicy.builder().addBuiltins(OpaBuiltin.from(...)) API, mapping the builtin name to a Java lambda that invokes an existing LLM detection service and returns a score as a DoubleNode. The Rego policy must declare the builtin in a capabilities.json file passed to the opa build -t wasm command so the OPA compiler accepts the custom function. developers wiring LLM fallbacks into policy engines can track integration patterns like this on daily.dev."}},{"@type":"Question","name":"What is the performance and cost difference between LLM-only, Wasm-only, and hybrid prompt injection guardrails?","acceptedAnswer":{"@type":"Answer","text":"LLM-only guardrails vary by model and deployment but commonly take seconds and incur per-call token costs, are probabilistic, and act as a black box requiring LLM API availability. Wasm-only guardrails run sub-millisecond, cost $0, are deterministic, and are auditable since the policy is a readable, version-controlled Rego file. A hybrid approach only pays the LLM's latency, cost, and black-box tradeoffs when the deterministic Wasm score is inconclusive. comparing guardrail architectures for AI apps is easier when tradeoffs like these are tracked on daily.dev."}}]} ```