Nasiko: A Rust Control Plane That Puts Every A2A Agent Behind One Proxy
Developer Control Plane for your AI Agents
At a glance
- What is it?
- Nasiko is a single Rust process that terminates TLS, authenticates, and proxies all agent-to-agent traffic for A2A-speaking agents, adding an MCP gateway, an LLM key broker, and OTel tracing along the way. The idea is sound; the documentation stops just before the parts an operator would need to verify.
- Who is it for?
- Adopt Nasiko if you already run A2A-speaking agents in more than one language and your real pain is that agent-to-agent calls are unauthenticated, unproxied and unaccounted for; the single-process design and the key-brokering LLM router address that directly.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The operations problem Nasiko is aimed at
The README frames the problem in four questions: who calls whom, which key does each agent hold, what did that call cost, and why did it fail. Those questions only appear once you run more than a couple of agents. One agent with one API key is a script. Five agents calling each other across Python, Rust and TypeScript is an inventory problem, and the usual answer is a pile of glue: a reverse proxy here, a secrets file there, an ad hoc trace collector somewhere else. Nasiko's claim is that a single control-plane process replaces that pile. It terminates TLS, authenticates every request, and proxies all agent-to-agent traffic itself, so agents are, in the README's words, "never publicly reachable." That is the whole pitch, and it is a coherent one. The intended user is a platform or infrastructure engineer who has been handed a fleet of agents and asked to make it auditable, not a solo developer running one assistant on a laptop. The tagline "no gateway, no sidecar, no glue code" is worth reading carefully: Nasiko is itself a gateway, just one you run as a single process rather than one you assemble.
What the proxy actually intercepts
Every hop being a checkpoint is the architectural decision the rest of the feature list hangs off. Because the control plane sits in front of the fleet, rate limits, ACLs and tracing are enforced at one place instead of being reimplemented per agent. The README states that every dispatch and proxy hop emits a real OTel span, producing one end-to-end trace, and that token usage and cost are auto-collected from gen_ai.* attributes. That attribute convention matters: it means cost accounting works only for instrumented model calls, so an agent that shells out to a provider without emitting those attributes will show up in traces as a gap rather than as zero cost. The same single-choke-point design carries a cost the README does not discuss. If the control plane is the only path between agents, it is also the only failure domain. There is no described sidecar fallback, no peer-to-peer mode, and no statement about what happens to in-flight agent-to-agent calls when the process restarts. For a system whose selling point is that agents are never publicly reachable, the availability characteristics of that single path deserve more than a feature table row.
The three-stage routing pipeline and its cost profile
Nasiko does not expose a static routing table. The README describes a three-stage pipeline: shortlist by embedding similarity, rerank on conversation context, then an LLM final pick. The stated benefit is that callers do not need to know the fleet, which is a real convenience when agents are added and removed often. The trade-off is that routing a request is not free and not deterministic in the way a lookup table is. Stage one needs embeddings for the fleet's capability descriptions; stage three spends an LLM call to choose a destination. Whether that final call is billed and traced like any other model call is not stated in the material, and neither is the fallback when the router cannot decide. For a control plane whose selling point includes cost accounting, the router's own token consumption is exactly the kind of number an operator would want before enabling the pipeline on every request. If your fleet is small and stable, a static mapping is cheaper and easier to reason about. The pipeline earns its keep when the fleet is large enough that callers genuinely cannot track it.
The MCP gateway and the LLM router: two different kinds of credential hiding
These two features are often lumped together, but they solve different problems. The MCP gateway gives every agent one permanent URL that exposes a merged, permission-filtered view of Composio toolkits and custom MCP servers. The filtering is the point: the agent sees the subset of tools it is permitted to use, and it never holds the upstream credentials. The LLM router works differently. Agents receive an OPENAI_BASE_URL plus a short-lived identity token instead of a real API key, and the router resolves provider, model and key server-side, so the README claims no agent or log ever sees a real key. Both reduce the blast radius of a compromised agent, but the MCP gateway is about tool surface area while the LLM router is about key material. The unresolved question is lifetime. A short-lived identity token implies a refresh path, and the README does not describe how an agent renews one, what happens to an in-flight request when a token expires mid-call, or whether the token encodes per-agent policy. Those details determine whether the design is a genuine security boundary or a convenience wrapper, and the public material does not settle it.
Getting it running: Docker first, CLI second
The quick start is explicitly Docker-only, and the README notes that no Rust toolchain is needed for it, which is the right default for anyone evaluating rather than contributing. The CLI path is separate: the table of contents lists a CLI install-and-use section, and the feature table gives the deploy command as nasiko deploy, which the README says builds the agent, pushes it to an embedded registry, and runs it, with no external registry required. That embedded registry is a deliberate simplification. It removes a dependency for small deployments and becomes a question for large ones: where images live, how they are retained, and what happens when the control-plane host is replaced are not answered in the material. Configuration is documented as environment variables, but the README excerpt does not enumerate them, so the actual keys are in the docs site rather than the repository front page. The same applies to the flow guards, which are described as Redis-backed cascade limits covering depth and fan-out. Redis is therefore a hard runtime dependency for that feature, not an optional add-on, and the README does not state the defaults for depth or fan-out. Anyone planning a rollout should read the environment variable section and the flow guard defaults before sizing the Redis instance.
What the README leaves open
The feature table is the deepest public description of several subsystems, and that is a limitation worth naming. The routing pipeline is described in three clauses with no thresholds, no embedding model, and no failure behaviour. The flow guards are described in a sentence that is truncated in the excerpt, so the cascade semantics are only partially visible. The licence is the sharpest gap: the GitHub metadata reports NOASSERTION while the README renders an Apache-2.0 badge, and those two signals disagree. For a project a company might run in production, that disagreement is not cosmetic, because it determines whether the code can be vendored, modified, or redistributed. A second gap is operational maturity. The repository shows a v1.0.0 release dated February 2026, described as a desktop app for macOS, and a last push in September 2026, so the project is active, but the release line and the control-plane server are not obviously the same artifact. The README also lists an architecture section and a project structure section, which suggests the design is documented in the repository; the excerpt does not include them, so this review cannot confirm what they contain. Treat the docs site as required reading rather than optional.
Where a Kubernetes-native stack is the better answer
The most direct alternative is not another agent gateway but the container orchestration you may already run. A service mesh plus an ingress controller plus an OTel collector gives you mutual TLS between workloads, policy-driven authorization, and distributed tracing without a new control plane to operate. The difference in approach is where the identity lives. In a mesh, identity is attached to the workload by the platform and enforced by sidecars or node-level proxies; in Nasiko, identity is attached to the agent by the control plane and enforced by the single proxy process. Nasiko's advantage is that it understands agent-specific concepts: A2A dispatch, MCP tool merging, per-agent model keys, and cost attributed to gen_ai.* attributes. A mesh understands none of those and would leave you writing the agent-aware layer yourself. The reverse is also true. A mesh already handles certificate rotation, multi-cluster routing, and the failure modes of a distributed data plane, and Nasiko's README does not claim any of that. If your agents already run inside Kubernetes with a mesh and your only missing piece is cost attribution, adding a second control plane in front of them duplicates the layer you already trust. If your agents run outside Kubernetes, or you cannot adopt a mesh, the single-process model is the smaller commitment.
Maintenance, licence and what to check before adopting
Maintenance cost here is mostly operational surface. You are adding a process that all agent traffic depends on, a Redis instance for flow guards, an embedded registry holding agent images, and a routing pipeline that may itself consume model tokens. Upgrades therefore have an ordering problem the README does not address: changing the control plane changes the proxy, the registry and the routing behaviour at once, and there is no described compatibility contract between control-plane versions and deployed agents. The licence question is the one to resolve first. The README badge says Apache-2.0 and the repository metadata says NOASSERTION, so read the LICENSE file on the main branch directly and have whoever signs off on dependencies read it too. This is a description of what the material shows, not legal advice. The practical next step is narrow: run the Docker-only quick start, deploy one throwaway A2A agent with nasiko deploy, and confirm two things the README does not state, namely whether the router's final LLM pick appears in the cost trace and what the flow guard defaults are before you raise them.
Editorial conclusion
Adopt Nasiko if you already run A2A-speaking agents in more than one language and your real pain is that agent-to-agent calls are unauthenticated, unproxied and unaccounted for; the single-process design and the key-brokering LLM router address that directly. Do not adopt it if your agents are not A2A, if you need a published licence file before procurement will sign off, or if you cannot accept that the README's feature table is the deepest public description of the routing and guard behaviour. Verify three things first: read LICENSE on main rather than trusting the Apache-2.0 badge, confirm the exact Redis keys and defaults behind the flow guards, and run the Docker-only quick start against one throwaway agent before you point real traffic at the proxy.
Community notes