Clarion Street

Agent Sprawl Has a Name — and the Open-Source Fix Arrived This Week

·7 min read

For most of this year the conversation about agent infrastructure has had one shape: a diagnosis. Agents need a control plane, an identity layer, observability, and governance, and this site has spent two months arguing each from a different angle, starting with the infrastructure gap. I will not re-argue any of it here. What changed this week is smaller and more useful than a new thesis. Red Hat gave the problem a name, and three open-source tools shipped to fix a specific piece of it each.

Red Hat’s October 6 developer article describes what happens six months after you deploy a couple of agents to OpenShift. You find 40 of them. You do not know what most do. Some duplicate each other’s work across namespaces. API keys move over plain HTTP. When something fails you cannot tell whether the model hallucinated, a tool errored, or a downstream service went down. Red Hat calls the condition “agent sprawl” [1]. The name matters because it turns a vague feeling that the infrastructure is missing something into a list of symptoms, and each symptom can be attacked on its own.

Rossoctl: which agents do I even have

Red Hat’s Rossoctl turns agents into first-class Kubernetes resources. It defines two custom resource definitions, AgentRuntime and AgentCard, and auto-populates a searchable catalog through the A2A protocol, so an orchestrator can discover and delegate to a specialist no matter which framework built it [1][2]. The security side is a six-layer stack: SPIRE short-lived certificates, Istio mTLS, JWS-signed AgentCards, and an AuthBridge that issues scoped OAuth2 tokens. Opt-in MLflow tracing captures orchestration flow, external calls, and model latency instead of just HTTP status codes [1].

The claim is that agents differ from microservices in ways a service mesh does not cover. Discovery happens at inference time, not deploy time. Identity includes capabilities and protocols, not just a network path. An agent can return valid JSON while hallucinating a tool or leaking data, which HTTP metrics never see. Whether or not you want all six layers, that diagnosis is right, and it puts a familiar crisis in a new place: Kubernetes fleets rather than MCP servers. The MCP-specific cousin of this mess, the one this site has called tool sprawl, is a narrower version of the same problem.

Red Hat’s own framing is honest about scope. For an isolated agent the full stack is, in its words, excessive. It is justified for multiple teams, cross-agent dependencies, or strict compliance and debugging. And the first step is not the controller. It is publishing an AgentCard [1].

Tuskira’s gateway: who gave this agent a key

Tuskira released an open-source, self-hosted gateway on October 1, and Help Net Security covered it on October 7 [3][4]. It sits between agents and everything they call, MCP tool servers and model providers, and its job is to keep credentials out of agent configs entirely. The failure it describes will be familiar to anyone running a team of coding agents. A team on Claude Code, Cursor, and a homegrown bot copies the model key and the MCP credentials into every config on every laptop and CI runner. Whoever gets one file gets the credentials, and nothing checks what the agent is allowed to do when it acts [3][4].

The gateway moves the decision to the moment of the call. It checks the gateway key, tied to tenant and role. It checks whether the profile may use the requested tool. If not, it denies and logs without reaching the backend. On an allowed call it attaches the real credential from an encrypted store, so the agent never holds the token. An agent talked into calling a tool it was never shown gets refused at execution time [3][4]. This is the identity problem I wrote about in September as agents as non-human identities, now implemented as a gateway instead of an argument.

Tuskira documents its own sharp edges, which is more than most vendors do. A key with no bound profile can name any profile in a request header, so you have to bind every key. The demo stack stores LLM request and response bodies, up to 1 MiB each, with a setting to turn that off. The shipped Docker Compose allows host and loopback outbound connections that should be removed on anything shared [4].

Moyai: what is this fleet costing

Moyai is LiteLLM’s cloud agent, open-sourced on October 7 with the receipt attached [5]. LiteLLM was running Devin internally, and the bill hit $101,872 in a single month. Moyai does the same work for about $700 a day, roughly $21,700 over 31 days, which LiteLLM frames as 79% cheaper. Those numbers are self-reported arithmetic against its own Devin bill, not a benchmark. The direction is believable; the precision is marketing, and I will come back to that [5].

What Moyai actually is: a self-hosted cloud agent. Each session gets an isolated cloud workspace with a terminal, filesystem, and browser. Sessions are durable, and the agent loop is a per-session choice. Hermes is the default. Claude Code, Codex, OpenCode, and Deep Agents run through the LiteLLM agent SDK. Every model request routes through LiteLLM, with provider keys kept server-side. A Slack or browser task becomes a pull request while the laptop is closed [5][6].

The interesting part is the separation of the loop from the harness. You are not locked to one coding agent. You pick it per session, and the infrastructure underneath stays the same.

The cost side of autonomy

Sprawl is the cost side of the autonomy everyone is buying. Every decision to give an agent more agency, more tools, more credentials, more parallel sessions, expands the attack surface and the bill. The three tools are each a way to buy autonomy without buying the sprawl. Rossoctl answers which agents I even have. Tuskira answers who gave this agent a key. Moyai answers what this fleet is costing me and whose inference it is.

This is a consolidation pattern the site has already traced. In September I wrote that five vendors had shipped the same three-layer governance stack and left open whether bundled governance was plumbing or a moat. Last week I wrote that two specifications had named the same runtime-governance layer. Those were platform-bundled answers and specification answers. Rossoctl, Tuskira’s gateway, and Moyai are a third kind: self-hostable building blocks, MIT or Apache-2.0, runnable in your own environment. They are plumbing-side answers to the question I left open, and that is the part worth noting.

What is not settled

Everything new here is vendor-authored. Rossoctl is a developer-blog architecture pattern plus a GitHub controller, not a generally available product with independent evaluation. Tuskira’s claims are its own documentation and press release. Moyai’s cost comparison is LiteLLM’s arithmetic against its own bill. I treat the direction as real and the specific numbers as marketing.

These are three point solutions, not one platform, and I do not want to overclaim. Moyai is a coding agent, narrower than “any agent.” Rossoctl is scoped to Kubernetes and OpenShift fleets, and Red Hat itself says the full stack is overkill for an isolated agent. None of the three solves the whole sprawl problem, and nothing here says the problem is solved.

There is also a real argument that “agent sprawl” is premature as a named crisis. Most enterprise “agents” are still workflows in Anthropic’s sense, and the infrastructure-gap panic applies less to them. These tools matter most to the genuinely agentic minority that has already reached production fleets. The cluster is also young. Tuskira’s repo was created October 1 and sat at 59 stars and 6 commits when the researcher snapshotted it. Star counts on launch day are not maturity. A fourth tool, or a week of news, could render this piece stale, so it is deliberately dated and narrow rather than a taxonomy.

Bottom line

The agent infrastructure conversation has spent months naming what is missing. This week the fixes started shipping, and they shipped small and separable rather than as one platform. Rossoctl, the gateway, and Moyai will not stop sprawl on their own, and none of them claims to. What they show is that the remediation layer is no longer something you wait for a vendor to bundle. It is something you can pull from GitHub and run yourself, one layer at a time.

Sources

  1. Rossoctl for agent discoverability, security, and observability on Kubernetes — Red Hat Developer, October 6, 2026
  2. Rossoctl — GitHub
  3. AI Agent Gateway: Open-source tool keeps credentials out of agent configs — Help Net Security, October 7, 2026
  4. Tuskira AI Agent Gateway — Tuskira
  5. Moyai is now open source — LiteLLM, October 7, 2026
  6. Moyai — GitHub