CAMEL-23621: filter tool argument headers against declared parameters#23535
Conversation
gnodet
left a comment
There was a problem hiding this comment.
Good security hardening for the LangChain4j tool invocation path. Filtering incoming JSON fields against toolSpecification.parameters().properties().keySet() is the right approach — it ensures only declared tool parameters are forwarded as headers, preventing injection of Camel-internal headers like CamelFileName through LLM-generated tool arguments.
The WARN log for skipped undeclared fields is helpful for debugging without silently swallowing. Test case demonstrating that CamelFileName injection is blocked validates the fix well. Upgrade guide entry included.
LGTM.
Fully automatic review from Claude Code
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
Backport of #23535 to camel-4.18.x. Filters LLM tool argument field names against the tool's declared parameter schema before setting them as Exchange headers, preventing prompt-injection attacks from injecting arbitrary Camel control headers. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary
Behavioral change
Tools defined without parameter.* declarations will now have zero argument headers set from LLM tool calls. Previously, all LLM-provided argument field names were set as Exchange headers without filtering. This is a breaking change for routes that rely on implicit argument passthrough, e.g.: from("langchain4j-tools:test1?tags=user&description=Does not really do anything") Any LLM-provided arguments for such tools will be silently dropped. To restore argument flow, declare the expected parameters explicitly via parameter.=.