Route and Manage AI Agent Resources
Wanaku is a governed action proxy that puts policy, identity, and audit between AI agents and the backend systems they act on.
0.2.0Add to Favorites
Why it matters
Centralize routing and resource management for AI agents, acting as a gateway between multiple MCP servers with extensive integration capabilities.
Outcomes
What it gets done
Provide unified access to AI agents and resources.
Bridge MCP servers for seamless inter-server communication.
Leverage 300+ Apache Camel components for broad integration.
Secure access with built-in authentication and authorization.
Source
Get it from source
Spark does not host a copy of it.
Open sourceReports
Agent outcome reports
No reports yet
Overview
Wanaku MCP Router MCP Server
Wanaku is a governed action proxy that sits between AI agents and the systems they act on, enforcing policy, identity, and audit on every tool call instead of letting agents reach backends directly. It auto-discovers tools from upstream MCP servers, isolates them by namespace, and authenticates actions through oauth2-proxy and Keycloak. Use it when AI agents need governed, audited access to real backend systems; skip it if you only need a single MCP server with no policy or identity layer.
What it does
Wanaku is a governed action proxy for AI agents: it sits between agents and the systems they act on, intercepting tool calls, agent-to-agent messages, and inference traffic. Integration developers build Apache Camel routes and publish them as tools; agents call those tools with parameters, but Wanaku runs the actual work - the agent never touches backend systems directly - so policy, identity, data controls, and audit happen in the proxy rather than in the agent itself.
When to use - and when NOT to
Use it when you need to put a governed, auditable layer between AI agents and the real systems they can act on - enforcing policy (LLM-powered evaluators plus WASM action scripts that classify, filter, and block tool calls), identity and auth (via oauth2-proxy and Keycloak, enforced before actions reach backends), and namespace isolation across teams, tenants, or environments. It also auto-discovers tools from upstream MCP servers and re-exposes them locally, so an agent's tool catalog can grow without the client knowing the tools are forwarded.
It's not a fit if you just need a single MCP server exposing your own tools with no policy or identity layer in between - Wanaku's value is specifically the proxy/governance boundary, and running it adds that layer's operational surface (oauth2-proxy, Keycloak, the management API) rather than removing it.
Capabilities
Agent isolation keeps agents talking to Wanaku instead of backend systems directly. Policy enforcement runs LLM-powered evaluators and WASM action scripts in the proxy layer to classify, filter, and block tool calls. Identity and auth flow through oauth2-proxy and Keycloak, enforced before actions reach backends, with Wanaku also serving RFC 9728 OAuth Protected Resource Metadata at /.well-known/oauth-protected-resource/{namespace}/mcp (set WANAKU_AUTH_ISSUER to your Keycloak realm URL to populate authorization_servers). Tool discovery auto-discovers tools from upstream MCP servers registered as forwards via the management API, and namespace isolation organizes tools and resources per team, tenant, or environment. The architecture is extensible through feature crates and a composable filter pipeline, there's a web admin dashboard for managing tools, resources, prompts, and forwards, and multi-arch container images (x86_64, aarch64) publish automatically.
How to install
On Linux or macOS, the early-access installer detects the platform, verifies the release checksum, and installs wanaku-server into $HOME/bin (override with WANAKU_INSTALL_DIR):
curl -fsSL https://raw.githubusercontent.com/wanaku-ai/wanaku/main/get-wanaku.sh | bash
Or run as a container: podman run -p 8080:8080 -p 8081:8081 quay.io/wanaku/wanaku-server, optionally mounting a wanaku.yaml to preload forwards. Building from source needs Rust 1.96+ and Yarn for the admin UI: cargo build && cargo run (the first build compiles the admin UI automatically if ui/admin/dist/ is missing). Once running, the MCP endpoint is at http://localhost:8081/mcp (or /{namespace}/mcp), the management REST API is at http://localhost:8080/api/v1/..., and the admin dashboard is at http://localhost:8080/admin/. Register an upstream MCP server as a forward with a POST to /api/v1/forwards, then refresh it to auto-discover its tools - all of them then appear in the local catalog with the calling client unaware they're forwarded. The project is Apache 2.0 licensed.
Who it's for
Platform and security teams operationalizing AI agents who need policy enforcement, identity, and audit sitting between agents and the systems those agents can reach, rather than trusting each agent to behave.
Source README
Wanaku - A Governed Action Proxy for AI Agents
Wanaku is a governed action proxy for AI agents. It sits between agents and the systems they act on, intercepting tool calls, agent-to-agent messages, and inference traffic. Integration developers build Apache Camel routes and publish them as tools; agents call those tools with parameters, but Wanaku runs the actual work - the agent never touches backend systems directly. Policy, identity, data controls, and audit happen in the proxy, not in the agent.
The project name comes from the origins of the word Guanaco, a camelid native to
South America.
Key Features
- Agent Isolation - Agents call tools through Wanaku; they never reach backend systems directly
- Policy Enforcement - LLM-powered evaluators + WASM action scripts classify, filter, and block tool calls in the proxy layer
- Identity & Auth - Authentication and authorization via oauth2-proxy and Keycloak, enforced before actions reach backends
- Tool Discovery - Auto-discover tools from upstream MCP servers; integration developers publish Camel routes as tools
- Namespace Isolation - Organize tools and resources across isolated namespaces per team, tenant, or environment
- Extensible Architecture - Plugin system via feature crates and a composable filter pipeline
- Admin Dashboard - Web UI for managing tools, resources, prompts, and forwards
- Container-Ready - Multi-arch images (x86_64, aarch64) published automatically
Quick Start
Install
Download the latest early-access build on Linux or macOS:
curl -fsSL https://raw.githubusercontent.com/wanaku-ai/wanaku/main/get-wanaku.sh | bash
The installer detects the host platform, verifies the release checksum, and installs wanaku-server into $HOME/bin. Override the destination with WANAKU_INSTALL_DIR.
Container
podman run -p 8080:8080 -p 8081:8081 quay.io/wanaku/wanaku-server
To preload forwards, mount a wanaku.yaml:
podman run -p 8080:8080 -p 8081:8081 \
-v ./wanaku.yaml:/etc/wanaku/wanaku.yaml \
quay.io/wanaku/wanaku-server \
--wanaku-config /etc/wanaku/wanaku.yaml
From Source
cargo build
cargo run
The first cargo build automatically builds the admin UI via yarn if ui/admin/dist/ is missing.
Endpoints
| Endpoint | Address | Description |
|---|---|---|
| MCP | http://localhost:8081/mcp |
MCP protocol endpoint (or /{namespace}/mcp for namespaced access) |
| Management API | http://localhost:8080/api/v1/... |
CRUD for tools, resources, prompts, forwards, namespaces |
| Admin UI | http://localhost:8080/admin/ |
Web dashboard |
Learn Wanaku
The easiest way to learn Wanaku is by following the guided tutorial.
The reference documentation, including the complete installation and configuration instructions, is available in the usage guide.
Configuration
Drop a wanaku.yaml in the working directory to preload forward definitions:
forwards:
- name: "upstream-mcp"
address: "http://remote.example.com/mcp"
If no config file is provided, the server starts with an empty registry that can be populated via the management API.
Management API Examples
Register a remote MCP server as a forward (its tools are auto-discovered):
curl -X POST http://localhost:8080/api/v1/forwards \
-H "Content-Type: application/json" \
-d '{
"name": "upstream-mcp",
"address": "http://remote.example.com/mcp"
}'
Refresh tools from the forward (auto-discover):
curl -X POST http://localhost:8080/api/v1/forwards/upstream-mcp/refreshes
All tools from the remote server now appear in your local catalog. The client has no idea they're forwarded.
Authentication
Authentication is handled externally by oauth2-proxy. Two instances sit in front of the MCP and management ports, sharing an SSO cookie:
- MCP proxy (
:4180→:8081) - protects MCP endpoints, any authenticated user - Management proxy (
:4181→:8080) - protects the admin UI and REST API, admin role required
Wanaku also serves RFC 9728 OAuth Protected Resource Metadata at /.well-known/oauth-protected-resource/{namespace}/mcp. Set WANAKU_AUTH_ISSUER to your Keycloak realm URL to populate the authorization_servers field.
See deploy/auth/README.md for setup instructions (Docker Compose and local development).
Documentation
The Wanaku Documentation website contains the full project documentation.
Contributors working on the project may want to refer to the development documentation:
- Getting Started - Development setup guide
- Architecture - System architecture and components
- Configuration - Environment variables and configuration reference
- Management API - API reference
- Admin UI - Admin dashboard development
- Features / Plugins - Feature crate system
- Plugin Development - Guide for writing new feature crates
- Evaluator Engine - WASM-based evaluator
- Action Policies - Deterministic MCP action rules
- Governance Posture - Enforcement modes and fail-safe behavior
- Contributing - Contribution guidelines
- Security - Security policy
Community
- GitHub Issues - Bug reports and feature requests
- Discussions - Ask questions and share ideas
- Examples - Example capabilities and integrations
Related Projects
- Camel Integration Capability - Build Apache Camel routes and publish them as tools that agents can call through Wanaku
- Java SDK - SDK for building capability services in Java
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.