# Nasiko: a Rust control plane that proxies every A2A agent call

> Nasiko puts a single process in front of your A2A agents so none of them is publicly reachable, and handles routing, credentials and tracing in that one hop. Here is what the repository documents, what it leaves open, and who should stay away.

**Nasiko-Labs/nasiko** — Developer Control Plane for your AI Agents

- Repository: https://github.com/Nasiko-Labs/nasiko
- Website: https://www.nasiko.com
- Stars: 9,096 · Forks: 1,949
- Language: Rust
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/nasiko-labs-nasiko

## The operations problem Nasiko is aimed at

Two agents are a demo. Ten agents are an operations problem, and the README lists the questions that follow: who calls whom, which key does each agent hold, what did that call cost, why did it fail. Those questions get answered differently in every team, usually with a reverse proxy, a secrets file, a tracing library and a spreadsheet.

Nasiko's answer is to make one process the only path between agents. It terminates TLS, authenticates every request, and proxies all agent-to-agent traffic itself, so the README states agents are never publicly reachable and every hop becomes a checkpoint for rate limits, ACLs and tracing. That is the whole pitch, and it is a real architectural decision rather than a feature list: you give up direct agent-to-agent connections in exchange for one place where policy and telemetry live.

The intended user is an engineer running a fleet of agents on their own machines or cluster, using the A2A protocol, who is willing to run Postgres, Redis, an S3-compatible store and an OpenTelemetry collector alongside it. The README is explicit that agents can be written in Python, Rust, Go or TypeScript, and that there is no proprietary agent format. That matters more than it sounds: the control plane's value depends on it not forcing a rewrite of the agents themselves.

## One ingress, an embedded registry, and a three-stage router

The repository is a Cargo workspace with 21 members, and the layout maps closely onto the README's feature table. agent-proxy, llm-router, mcp-gateway, flow, hitl, oidc, oci, orchestrator and runtime are separate crates, with server tying them together. Reading the workspace is the fastest way to see where a given behaviour lives.

Deployment goes through the oci crate and an embedded registry: `nasiko deploy` builds, pushes and runs an agent without an external registry, per the README. Routing is a three-stage pipeline. A shortlist is produced by embedding similarity, then reranked on conversation context, then an LLM makes the final pick. The stated benefit is that callers do not need to know the fleet, which is the actual difference from a static routing table.

Two credential boundaries sit in the same process. The MCP gateway exposes one permanent URL that gives every agent a merged, permission-filtered view of Composio toolkits and custom MCP servers, while the agent itself never holds those credentials. The LLM router instead hands an agent an OPENAI_BASE_URL plus a short-lived identity token, and resolves provider, model and key server-side. If you have ever rotated a provider key across a dozen agent containers, that indirection is the feature to look at first.

Observability is not a sidecar. Every dispatch and proxy hop emits an OpenTelemetry span, so a request becomes one end-to-end trace, and token usage and cost are collected from gen_ai.* attributes. Flow guards add Redis-backed cascade limits on depth and fan-out, which is the kind of thing that only becomes necessary once an agent can trigger another agent.

## Installing Nasiko with Docker and deploying a first agent

The README offers a Docker-only quick start that needs no Rust toolchain. Copy the environment template first, because the compose file expects a .env in the repository root.

```bash
cp .env.example .env
docker compose up -d
docker compose logs -f server
```

The UI is served at http://localhost:8080 according to the compose header comments. The .env.example file marks its own required block: SECRETS_ENCRYPTION_KEY, an AES-256-GCM key used to encrypt agent secrets at rest, JWT_SECRET, ADMIN_USERNAME and ADMIN_PASSWORD. The file gives the generation commands directly, for example `openssl rand -base64 32` for the encryption key, and it ships a working placeholder value that you should replace rather than keep.

The compose stack brings up pgvector/pgvector:pg16 on 5432, redis:7-alpine on 6379, a rustfs S3-compatible store on 9000, and an OpenTelemetry collector on 4317 and 4318 feeding Tempo and Loki. Postgres and rustfs both come with default credentials in the compose file, so treat a first run as a localhost-only exercise.

If you work from source instead, the justfile is the entry point. The infra recipe starts only the backing services, and run-stack starts infra and the server together.

```bash
just infra
just run-stack
```

Both recipes source server/.env if it exists and fall back to server/.env.example, then run `cargo run -p nasiko-server`. The justfile also defines a fresh recipe that deletes Postgres and S3 volumes and every container matching nasiko-agent- before restarting infra; it is guarded by a confirmation prompt, and it is the recipe to read before you run it on anything you care about. Once the server is up, the README's deployment path is a single `nasiko deploy`, which builds, pushes to the embedded registry and runs the agent.

## What the repository does not settle

The licence is the first unresolved item. The README displays an Apache-2.0 badge, but the repository metadata reports NOASSERTION, meaning no licence was detected from the LICENSE file. Those two signals disagree, and the README's own badge is not a legal statement. If your organisation has a licence allowlist, this is the thing to resolve before anything else, and the answer is in the LICENSE file in the repository root, not in the badge.

Versioning is the second. The workspace Cargo.toml sets version 0.1.0 for all members, while the only listed release is v1.0.0, described as a desktop app for macOS and dated 2026-02-12. A source build from main and the macOS desktop release are therefore different artifacts, and the README does not explain how they relate.

There are gaps in the documentation as given. The README's troubleshooting section is listed in the table of contents but the content is not present in what the repository shows here, so there is no documented rollback path for a bad deploy and no documented procedure for removing an agent from the routing pool. The .env.example marks AGENT_JWT_SECRET as optional with a development fallback, which is convenient locally and worth a deliberate decision before production. Flow guards are described as Redis-backed cascade limits, which makes Redis a hard dependency for that behaviour rather than an optional cache.

Finally, the design has a single point of failure by construction. A control plane that proxies every hop is exactly as available as itself. The README does not document a high-availability mode for the server process, so anyone planning multi-node production should treat that as an open question to answer from the source, not from the README.

## Where an A2A gateway like this is the wrong tool

The A2A requirement is the sharpest boundary. Nasiko is built around the A2A specification, and the README's promise is that anything speaking A2A can be deployed. If your agents use a different transport or a framework-specific protocol, the control plane has nothing to proxy and the value proposition collapses to a container runner you could replace with a compose file.

A second mismatch is scale in the other direction. If you run two agents that call each other in a straight line, the proxied ingress, the three-stage router and the Redis cascade limits are overhead with no corresponding problem. The routing engine exists because callers should not need to know the fleet; when the fleet is one or two, the caller already knows.

Third, the stack is opinionated about infrastructure. Postgres with pgvector, Redis, an S3-compatible store and an OpenTelemetry collector are part of the quick start, not optional add-ons in the compose file. A team that has standardised on a different database, or that cannot run an OpenTelemetry collector, is signing up for a second operational surface alongside the agents it was trying to simplify. The README does not describe a reduced deployment that drops any of these, so assume the full set.

There is also no hosted option described in the repository. The homepage is listed, but nothing describes a managed service, so this is software you run yourself.

## How this differs from a plain reverse proxy or service mesh

The obvious alternative is what most teams build first: nginx or Envoy in front of the agents, a secrets manager for provider keys, and an OpenTelemetry SDK inside each agent. That approach is more familiar and does not add a database.

The difference in mechanism is where the intelligence sits. A reverse proxy routes on host, path or header, and it has no notion of which agent should handle a request based on what the conversation is about. Nasiko's router shortlists by embedding similarity, reranks on conversation context, then asks an LLM to pick, which means routing decisions depend on the request's content rather than its URL. A reverse proxy also cannot mint a short-lived identity token so an agent never sees a real provider key; that requires the proxy to understand the LLM call itself, which is what the llm-router crate does.

A service mesh is the closer comparison, since it also centralises mTLS, policy and tracing across a fleet. The distinction is the unit of work. A mesh governs network connections between services; Nasiko governs agent dispatches, and its flow guards count cascade depth and fan-out rather than connection counts. If your problem is retries and mTLS between ordinary services, a mesh is the mature answer. If your problem is that an agent can recursively trigger four more agents and nobody can say what that cost, the mesh has no concept to express it.

## Conclusion

Adopt Nasiko if you already run more than a handful of A2A agents on your own infrastructure and the credential sprawl is the thing hurting you: the LLM router's design, where agents receive an OPENAI_BASE_URL and a short-lived identity token instead of a provider key, is the part worth evaluating first. Do not adopt it if you need a hosted service, a non-A2A agent protocol, or a licence position you can state without reading the file. Before committing, verify three things in your own checkout: whether Cargo.toml's workspace version 0.1.0 against the v1.0.0 desktop release is intentional, whether the LICENSE file matches the Apache-2.0 badge the README displays, and whether docker-compose.yml lets you replace the default nasiko/nasiko Postgres credentials and the rustfs root password before anything leaves localhost.

## FAQ

### What is Nasiko and what problem does it solve?

Nasiko is a single control-plane process that sits in front of A2A-speaking agents. According to the README it terminates TLS, authenticates every request and proxies all agent-to-agent traffic, so agents are never publicly reachable and every hop is a checkpoint for rate limits, ACLs and tracing.

### How do I install Nasiko without a Rust toolchain?

The README documents a Docker-only quick start: copy .env.example to .env and edit it, then run docker compose up -d, with the UI at http://localhost:8080. The .env.example file marks SECRETS_ENCRYPTION_KEY, JWT_SECRET, ADMIN_USERNAME and ADMIN_PASSWORD as required settings.

### Which agent languages does Nasiko support?

The README states you can bring agents written in Python, Rust, Go or TypeScript, because the control plane speaks the A2A protocol and imposes no proprietary agent format. The requirement is that the agent speaks A2A.

## Sources

- [Issues](https://github.com/Nasiko-Labs/nasiko/issues)
- [Nasiko-Labs/nasiko on GitHub](https://github.com/Nasiko-Labs/nasiko)
- [Project website](https://www.nasiko.com)
- [README](https://github.com/Nasiko-Labs/nasiko/blob/main/README.md)
- [Releases](https://github.com/Nasiko-Labs/nasiko/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nasiko-labs-nasiko