oscerd opened a new pull request, #27332:
URL: https://github.com/apache/camel/pull/27332
## Problem
A route exposed with `ai-tool:` is invoked by an AI agent
(`langchain4j-agent`, `openai`, `spring-ai-chat`, or the
built-in MCP server) from model output — so the tool call is the security
boundary. Today an authorization check has
to be added per route (`.policy(...)` or a route configuration
`interceptFrom`), which is opt-in: a tool route whose
author forgets the line is silently unguarded — the wrong default for a
security control.
## Change
### Component-level `authorizationPolicy` (guard by construction)
- New `authorizationPolicy` option — a bean reference to
`org.apache.camel.spi.AuthorizationPolicy` — on the
**component** (applies to every tool route) with a per-**endpoint**
override.
- `AiToolConsumer` wraps the tool route's processor with the policy at
startup (`policy.beforeWrap` + `policy.wrap`),
so the check runs **inside the route** and is visible to tracing; the
wrapped processor is started and stopped with
the consumer.
- A deny (`CamelAuthorizationException`) is classified as a new
`AiToolResult.AuthorizationDenied` and returned to the
model as a **short, caller-safe refusal** — never a rethrow, a failed
exchange, or a stack trace, regardless of the
tool-execution error strategy. All four result consumers (openai,
spring-ai-chat, langchain4j-agent, MCP bridge)
relay it.
- Trustworthy input only: the **tool name** comes from the route (never
model output); the **caller identity** comes
from an exchange property set before the agent ran, which the model cannot
set.
### Works over the MCP server too
The MCP server (`camel-mcp-server`) serves tools from the same registry but
builds a fresh exchange with no caller
identity. The authenticated caller is now carried end to end, with no MCP
SDK change (mcp-core 2.0.1):
- **Vert.x streamable HTTP transport**: capture the authenticated
`RoutingContext` user into the MCP SDK transport
context via Reactor `contextWrite` (mirrors the SDK's own servlet
transport).
- `McpToolCallHandler` gains a **backward-compatible** `default
call(arguments, McpToolCallContext)` overload (the
single abstract `call(arguments)` is unchanged); `VertxMcpServerEngine`
reads the principal from
`exchange.transportContext()`; `McpServerBridge` stamps it on the tool
exchange as the `CamelMcpSecurityPrincipal`
property. The stdio engine is unchanged (no HTTP principal).
## Tests
- `AiToolAuthorizationPolicyTest` — a policy on an `ai-tool` route allows
(`subject=alice`) and denies
(→ `AuthorizationDenied`).
-
`McpServerMainAuthenticationTest.testMcpToolCallCarriesAuthenticatedPrincipalToTheToolRoute`
— an authenticated MCP
client's Vert.x user reaches the tool route as the
`CamelMcpSecurityPrincipal` exchange property, end to end.
- Full module suites green: camel-ai-tool (120), camel-mcp-server-api (27),
camel-mcp-server (45).
Documented in the camel-ai-tool component doc ("Authorizing tool calls").
Related: CAMEL-23944, CAMEL-24832 (the agent-path caller context, #27264),
CAMEL-24743 / CAMEL-24830
(OpaSecurityPolicy — a natural policy to plug in here).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
