You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Andrea Cosentino (Jira)" <ji...@apache.org> on 2026/09/03 16:31:00 UTC

[jira] [Resolved] (CAMEL-24613) camel-langchain4j-agent-api: guardrail robustness (English false-reject with allowMixed=false, no guardrail-class interface check)

     [ https://issues.apache.org/jira/browse/CAMEL-24613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrea Cosentino resolved CAMEL-24613.
--------------------------------------
    Resolution: Fixed

> camel-langchain4j-agent-api: guardrail robustness (English false-reject with allowMixed=false, no guardrail-class interface check)
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-24613
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24613
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-langchain4j-agent
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>             Fix For: 4.23.0
>
>
> Two low-severity robustness issues in the agent-api guardrails:
> 1. LanguageGuardrail with allowMixed(false) and allowedLanguages={ENGLISH} falsely rejects plain English. The ENGLISH and LATIN_SCRIPT enum patterns overlap (ASCII letters match both), so detectedLanguages ends up {ENGLISH, LATIN_SCRIPT}; the mixed-content check then treats LATIN_SCRIPT as 'not allowed and not ENGLISH' and fails with 'Mixed language content is not allowed.'. Only in the non-default allowMixed(false) configuration. Fix: treat LATIN_SCRIPT as satisfied when ENGLISH is allowed (or de-overlap the patterns) before the mixed-content check.
> 2. AgentConfiguration.parseGuardrailClasses loads class names via Class.forName with no check that the class implements InputGuardrail/OutputGuardrail; a wrong or unrelated class name is silently accepted and only fails deep inside langchain4j later. The single shared parse method also cannot distinguish input vs output, so an output-guardrail name given to the input list is accepted. Fix: validate the loaded class against the expected guardrail interface and log/skip mismatches (as it already does for ClassNotFoundException).
> _Reported by an automated functional audit._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)