Roo Code: Governing a Coding Agent Through a Gateway

What Roo Code is — and what changed

Roo Code was an intelligent code-generation and refactoring system that worked within VS Code using natural language commands and context information from your coding activity. It was popular, open-source, and powerful.

In May 2026, Roo Code’s vendor announced it was shutting the extension down and directed users to Cline, a closely related agent. Existing installs keep working, but there are no new releases. That makes this a two-audience topic: teams still running Roo Code who need to keep it under control, and teams moving to Cline who want to set governance up correctly from day one. The good news is that both are governed the same way, because both connect through a standard OpenAI-compatible endpoint.

Whichever way you operate, the fundamental issue is basically the same – although not because of the extension.

Why a coding agent needs governance

An IDE coding agent is one of the least-governed LLM clients in most companies. Think about what it does by default:

• It holds a raw provider API key, typed into each developer’s settings. Rotating or revoking access means touching every machine.
• It calls whatever model the developer picks, with no central policy on which models are allowed or how much they cost.
• It sends your source code to a model provider — proprietary logic, secrets in config files, customer data in fixtures — with no scanning or redaction.
• It generates heavy, bursty token usage as it reads files and iterates, and none of that spend is attributed to a team or capped.
• It leaves no audit trail anyone can review.

Multiply that across a fifty-person engineering org and you have real spend, real data-exposure risk, and zero visibility. The agent is useful; the lack of a control point is the problem.

What “governed” actually means

Governance here is not about restricting the agent — it’s about putting a control point between it and the model providers. That control point is the gateway.

Every Roo Code (or Cline) instance points at one gateway endpoint instead of a provider directly. The gateway then enforces policy on every request:

What the gateway governs for an IDE coding agent

• Cost tracking per developer, team, and model — so agent spend is a line item you can see and attribute, not a surprise.
• Budgets and rate limits that cap a runaway agent before it burns a month’s quota in an afternoon.
• A model allowlist — the gateway decides which models the agent may call, regardless of what the IDE dropdown offers.
• Secret and PII guardrails that scan prompts and code for leaks before they reach a provider.
• An audit log of every agent call, for security and compliance review.
• Fallback so a provider outage doesn’t stop every developer at once.
• No raw provider keys on laptops — developers hold a TrueFoundry token; the real keys live in the gateway.

Where teams get this wrong

They hand out provider keys to developers. Every laptop with a raw OpenAI or Anthropic key is a rotation headache and a leak waiting to happen. Issue gateway tokens instead.

They govern production LLM calls but ignore the IDE. The coding agent often sends more sensitive data than production — your actual source — yet runs with none of the guardrails. Bring it under the same gateway.

They assume the IDE can be locked down. Roo Code’s provider settings are per-user; there’s no documented admin lockout. Chasing client-side enforcement is the wrong layer. Enforce at the gateway, where it actually holds.

They skip code/secret scanning. A coding agent will happily paste an .env file into a prompt. Without guardrails, that secret leaves your perimeter.

‍