Three Camel applications and a SPIRE deployment run with Docker Compose in the trust domain example.org, and a local Ollama provides the model. There is deliberately no OPA server container: the policy is evaluated inside the assistant, from a WebAssembly bundle.

• The assistant exposes POST /assistant. A request must carry a JWT-SVID as bearer token, which the assistant hands to the Workload API (validateJwtSvid) to check its signature, its expiry and that it was minted for the assistant (the audience of the token). The SPIFFE ID of the caller comes back in the CamelSpiffeSpiffeId header and is kept as an exchange property, the subject. The body is a natural-language message. The assistant runs the LangChain4j agent on Ollama with three tools; the model decides which to call.

• Each tool is a Camel route. Before a tool runs, the shared authorization guard asks OPA, in-process, whether this subject may use this tool (and, for a refund, whether the amount is within a cap). A deny does not run the tool: it returns a short refusal that the model relays to the user.

• The public-chatbot is a low-trust caller (say, a widget on a public web page). It may only look orders up. Its message is a prompt injection: it asks for the order status and, in the same breath, tells the assistant to ignore its instructions and refund the order. The model may well try refundOrder, but the guard denies it, so nothing happens beyond the order status the caller is allowed to see.

• The support-console is a trusted internal caller. It may look customers up and issue refunds up to the cap. It asks for a refund of 50 dollars and to see the customer on the order, and both are allowed.

Both callers run the very same code and image; they differ only in the Unix user they run as, which the SPIRE agent maps to a different SPIFFE ID, which the policy grants different tools. Identity comes from the platform, not from the code.

The tools are plain Camel routes registered with the ai-tool component, which puts them in a shared registry the agent reads by tag. Each binding delegates to a work route that carries the authorization guard:

The policy is written in Rego (opa/tools.rego). It reads the authenticated caller and the tool from the input document that the assistant sends, and answers a boolean:

The refund cap lives in opa/data.json ({"limits": {"refund_max": 100}}) rather than in the policy. opa build packs that data document into the bundle, so the WebAssembly module carries both the rules and the numbers they read.

Every tool route opts in to a single route configuration, the ToolAuthorizationPolicy. Its interceptFrom runs before the tool’s own steps and evaluates the policy with the camel-opa component in wasm mode:

Two things are worth pointing out. First, evaluationMode=wasm with a policyBundle on the classpath means the policy is evaluated in-process, on a pure-Java WebAssembly runtime; serverUrl and failOpen do not apply because there is no server. That keeps a tool call fast and removes a decision point that could be unreachable. Second, what is sent to the policy is narrow and trustworthy: the subject is the SPIFFE ID the assistant established from the validated token before the model ran, carried as an exchange property, so it is not something the model or a prompt can set. The tool name is captured from the route id for the same reason.

The example is built with Maven:

This also runs the unit tests, which need neither SPIRE nor Ollama (see below), and copies the runtime dependencies to target/lib, from where src/main/docker/Dockerfile picks them up.

The WebAssembly policy bundle (src/main/resources/opa/tools-bundle.tar.gz) is checked in, so the build and the tests need no OPA toolchain. Rebuild it only when you change opa/tools.rego or opa/data.json, with the helper script (it uses the OPA container image, so only Docker is required):

The Rego policy has unit tests of its own in opa/tools_test.rego, which run with the OPA binary or its container image:

You need Docker with Docker Compose, and a local Ollama with a tool-capable model.

First, run Ollama on the host and pull a model that supports tool calling (for example llama3.2:3b, qwen2.5 or mistral). The assistant container reaches it through host.docker.internal, so Ollama must listen on all interfaces, not only on 127.0.0.1:

Then build the images and start everything, telling the assistant which model to use:

The spire container starts a SPIRE server, registers the three workloads, then starts a SPIRE agent that joins the server with a one-time token. Once the agent serves the Workload API, the assistant starts, then the two callers. The log is kept readable on purpose (see src/main/resources/log4j2.properties): the Camel startup chatter and the HTTP and model client internals are at WARN, and the plumbing (fetching a token, the answer echoed a second time on the assistant side) is at DEBUG. The two callers are staggered, so each one’s exchange reads as its own block rather than interleaving. What is left is the story, with a denied tool call (a WARN) standing out:

The DENIED refundOrder line is the point of the example: the public chatbot’s message told the model to issue a refund, the model tried, and the guard turned it down, so the caller gets only the order status it is allowed to see and no refund happens. The exact wording of the answers depends on the model; the decisions do not.

By default docker compose up streams every container, spire included. To watch only the Camel applications, keep SPIRE running but off the screen:

Or start detached and follow only the containers you care about (the assistant is the one with the authorization decisions):

A few things to try while it runs:

• Change what a caller may do by editing opa/tools.rego (for example, let the public chatbot use lookupCustomer, or lower the refund cap in opa/data.json), run ./build-policy.sh, then docker compose up --build again. Nothing in the Java code changes.

• Point a caller at a different question by editing CLIENT_MESSAGE in compose.yaml, and watch which tools the model chooses and which ones the guard allows.

• Watch the assistant log its own X.509-SVID every minute, and see the SPIRE agent rotate it before it expires.

• Turn the logging up to see the plumbing: lower rootLogger.level (or the individual loggers) in src/main/resources/log4j2.properties to DEBUG to see the JWT-SVIDs being fetched and the full answers.

Stop everything with Ctrl+C, then:

The unit tests run with the build and need nothing external. OpaWasmToolGuardTest is the important one: it sends exchanges straight to the tool routes with a caller and arguments, and checks the real WebAssembly policy allowing and denying each case, entirely offline.

There is also a manual smoke test, LlmToolCallingSmokeTest, that drives the whole loop against a real model. It is disabled unless you ask for it, because it needs Ollama running:

The applications can also run directly on your machine with mvn camel:run, as long as a SPIRE agent (or any other SPIFFE Workload API) is reachable, and Ollama is running. Point the SPIFFE component at the agent socket and the model at Ollama:

On macOS, replace the io.spiffe:grpc-netty-linux dependency in the pom.xml with io.spiffe:grpc-netty-macos (or io.spiffe:grpc-netty-macos-aarch64 on Apple silicon), which java-spiffe needs to talk to the Workload API socket.

If you hit any problem using Camel or have some feedback, then please let us know.

We also love contributors, so get involved :-)

The Camel riders!