kagent Agent Builder: Three Guardrails a Prompt Can't Replace

While testing an agent that writes other agents, a CNCF blog author watched the model produce a manifest pointing at a tool server that didn’t exist, despite a system prompt that spelled out the correct name. A script approved it blindly, and the Kubernetes controller rejected it anyway. For platform teams being asked to offer builders that turn one sentence into a running agent, that failure is the lesson: the prompt is a request, and the real controls live in the cluster.

How It Works

The CNCF walkthrough builds a no-code style agent builder on a laptop with kagent, a CNCF Sandbox project that runs AI agents as Kubernetes resources. In kagent, an agent is a custom resource: a system prompt, a model, and a list of tools. Apply it, and the controller turns it into a running pod that speaks the A2A protocol. Once agents are YAML, the author writes, an agent that builds agents “is simply an agent that can write one kind of YAML.”

The lab runs on a kind cluster with kagent 0.10.2 and a local Ollama model. Model choice mattered. In the author’s runs, qwen2.5:7b-instruct invented its own tool format, qwen2.5:14b-instruct sometimes answered without calling the apply tool, and qwen3-coder:30b-a3b got it right on every run.

The builder is one Agent resource with three guardrails, each catching what the previous one misses:

• Allowlist: the tool server exposes 22 Kubernetes tools, but the builder sees three: list agents, apply a manifest, and read a resource back. If the model reaches for a delete tool, it isn’t there.
• Approval: requireApproval pauses the run before any apply, and the UI shows the exact manifest with approve and reject buttons.
• RBAC: the chart gives the tool server cluster-admin by default. The lab replaces that with a read-only role plus one rule allowing writes to agents.kagent.dev only, so even an approved mistake can’t create a Deployment or read a Secret.

The system prompt adds softer rules: check existing names first, emit exactly one Agent with read-only tools, put free text in YAML block scalars, and report errors instead of creating my-agent-v2 to see what happens.

What This Means for You

Building the agent took one YAML file and a couple of Helm installs. The author’s point is that this is now the easy part. The lab deliberately leaves security out of scope: kagent runs in its default unsecure auth mode, so every request acts as the same user, and the bundled PostgreSQL keeps its built-in password. Nobody knows who asked for an agent, what its model calls cost, or who decided it should exist.

That gap grows with every builder, framework, and assistant a company adopts. The author argues for a governance layer in front of all agents rather than inside each one, and points to agentgateway, a Linux Foundation project that proxies LLM, MCP, and A2A traffic with authentication, CEL-based authorization, and OpenTelemetry for every call. Stack Archive covered agentgateway joining the Agentic AI Foundation earlier.

Source: CNCF Blog

Content created with AI assistance and reviewed for accuracy.