# Kagent Makes Agent Creation Easy—and Governance the Hard Part

- Link: https://thestackobserver.com/kagent-makes-agent-creation-easy-and-governance-the-hard-part/
- Published: 2026-10-19T13:19:33-04:00
- Author: Stackxx

A recent CNCF walkthrough of kagent makes an AI agent appear in a Kubernetes cluster
with surprisingly little ceremony: describe the agent in plain language, let another
agent produce a custom resource, approve the proposed manifest, and wait for the
controller to report it ready. The demonstration is useful precisely because it 
makes agent creation look ordinary. Models, prompts, tools, and interoperability
settings become fields in a Kubernetes resource rather than a separate application
stack.

That simplicity also exposes the more important engineering problem. Creating an
agent is no longer the hard part. Establishing what it can do, who may create it,
how its actions are approved, and how operators prove what happened are the real
production gates. Kagent 0.10.2 offers a concrete way to examine that shift because
it applies familiar cloud native controls—custom resources, controllers, service
accounts, RBAC, and status conditions—to an AI workload.

The central lesson is not that every platform team should immediately allow agents
to create other agents. It is that agent platforms become easier to reason about
when their desired state and authority are separated. A prompt can describe behavior,
but enforceable infrastructure controls must bound that behavior.

## What kagent changes about the agent deployment model

Kagent represents a declarative agent as a Kubernetes custom resource. Its specification
can identify a model configuration, define a system message, select tools exposed
through an MCP server, and publish skills through the Agent2Agent protocol. A controller
reconciles that desired state and reports conditions such as **Accepted** and **
Ready**.

This is a meaningful change from the common pattern of treating an agent as a Python
process, a hosted workflow, or configuration hidden inside a vendor console. Kubernetes-
native representation gives platform engineers a resource that can be reviewed, 
labeled, promoted, observed, and governed using many of the mechanisms they already
operate. The agent becomes part of the cluster’s control plane vocabulary.

The CNCF tutorial pushes that model one step further by defining an “agent builder.”
The builder receives a natural-language request and creates a second Agent resource.
It has three Kubernetes tools: list existing agents, apply a manifest, and read 
the result. The manifest is not silently accepted. The apply action is configured
to require human approval, so execution pauses until a person reviews the proposed
resource.

That sequence matters more than the novelty of an agent writing YAML. The model 
proposes desired state, a human authorizes the mutation, Kubernetes evaluates the
request against RBAC, and the controller reports whether the resource was accepted
and became ready. Each stage has a distinct job, and no single stage is trusted 
to provide every safety property.

## The prompt is policy guidance, not a security boundary

The builder’s system prompt contains detailed constraints. It instructs the model
to create only one Agent resource, use a specific namespace, avoid overwriting existing
agents, grant only read-only tools to the new agent, and stop after an error. Those
instructions improve reliability. They are still instructions interpreted by a probabilistic
system.

The walkthrough offers a useful failure example. In one run, the model referenced
the wrong tool-server name even though the prompt supplied the correct one. The 
controller rejected the resulting resource because the referenced server did not
exist. Nothing catastrophic happened, but the episode illustrates why a syntactically
plausible manifest and a confident model response are not evidence of a valid deployment.

Kagent’s layered controls show a better pattern:

 * **Tool allowlists constrain the action surface.** If a destructive Kubernetes
   tool is not exposed to the model, the model cannot call it through that server,
   regardless of what a user requests.
 * **Human approval controls the mutation point.** Requiring approval for the apply
   tool creates a review boundary immediately before state changes.
 * **RBAC constrains the resulting API request.** Even an approved request is limited
   by the service account. In the tutorial, that identity can write Agent resources
   but cannot create Deployments or read Secrets.
 * **Controller status provides authoritative feedback.** The agent reads the resource
   back and reports actual conditions rather than assuming that an accepted API 
   request produced a working runtime.

These layers catch different failure modes. An allowlist narrows which capabilities
the model sees. Approval lets a human reject an unexpected argument or manifest.
RBAC remains effective if both the prompt and reviewer miss a problem. Status conditions
distinguish “the API accepted an object” from “the agent is operational.” Defense
in depth here is not abstract security advice; it maps directly onto the agent’s
lifecycle.

## Why Kubernetes is a good fit—and where it is not enough

Kubernetes is well suited to expressing desired state and reconciling it continuously.
Custom resources give agents stable names, namespaces, labels, ownership, and conditions.
GitOps systems can review and promote them. Admission policies can validate fields
before persistence. Service accounts can isolate runtime identities, while network
policies can limit which model endpoints and tool servers a workload can reach.

Those properties can make agent deployment repeatable. A platform team can define
approved model configurations, package permitted tool servers, and offer templates
that encode default limits. Developers get a familiar delivery path, while operators
retain the ability to inventory active agents and inspect their configuration.

But Kubernetes authorization answers only a subset of agent governance questions.
It can decide whether a service account may create an Agent resource or read a Secret.
It does not, by itself, determine whether a particular employee may ask that agent
to query a customer system, whether model usage should be charged to one team, or
whether an A2A request crosses an organizational boundary. It also does not automatically
record the semantic intent behind a tool call.

The tutorial deliberately runs in an unsecured local mode where requests effectively
share one user identity. That is acceptable for a laptop exercise and unacceptable
as a production blueprint. In a shared environment, identity must survive the entire
path: from the human or service making a request, through the agent runtime, to 
the tool and downstream API. If every request collapses to the same Kubernetes service
account, audit logs can show which workload acted but not necessarily which principal
initiated the action.

## The production control plane needs more than manifests

Platform teams evaluating kagent should treat the custom resource as one layer in
a broader agent control plane. Four operational capabilities deserve explicit designs
before a pilot expands beyond a sandbox.

### Identity propagation

Determine how user identity is authenticated at the entry point and represented 
downstream. A shared agent identity may be appropriate for narrow read-only automation,
but privileged actions often need delegated identity, workload identity, or a policy
decision tied to the initiating principal. The design should prevent an agent from
becoming an identity-laundering proxy.

### Policy at the tool-call boundary

RBAC protects the Kubernetes API, but many agent tools call SaaS APIs, databases,
observability systems, or internal services. Those calls need their own authorization
checks. Tool names alone are not sufficient: a “query” tool may be harmless for 
one dataset and sensitive for another. Policies should evaluate arguments, resource
scope, environment, and requester context.

### Traceable approvals

Approval should be reserved for consequential actions and should record who approved
what. A generic confirm button can become ineffective if operators see too many 
prompts or cannot inspect the exact request. Good approval UX displays the tool,
arguments, target resource, expected effect, and the identity under which it will
run. Rejections and timeouts should also become auditable events.

### Agent-aware observability

Cluster metrics and pod logs remain necessary, but operators also need traces across
model calls, A2A messages, MCP tool invocations, approvals, and downstream responses.
Useful telemetry should connect a user request to token cost, latency, tool selection,
policy decisions, and the final result. The kagent release stream is already adding
runtime tracing and metrics, signaling that day-two operations are becoming part
of the product rather than an afterthought.

## A practical adoption path for platform teams

The safest first use case is not a general-purpose autonomous operator. Start with
an agent that has a narrow, read-only job and a small set of well-defined tools.
Cluster diagnostics is a reasonable example: list resources, inspect events, read
selected logs, and summarize findings without making changes.

Build the initial deployment around explicit constraints:

 * Create a dedicated namespace and service account for the agent runtime.
 * Expose only the individual tools required for the use case; do not rely on a 
   prompt to avoid unused capabilities.
 * Use namespace-scoped RBAC where possible and verify permissions with authorization
   checks.
 * Separate model configuration from agent behavior so providers, credentials, quotas,
   and data-handling requirements can be managed centrally.
 * Require approval for state-changing tools, then test both approval and rejection
   paths.
 * Capture resource status and downstream results before reporting success to the
   user.
 * Instrument model, A2A, and MCP activity with correlated identifiers and cost 
   data.

Next, test failure behavior rather than only the happy path. Give the agent an invalid
tool-server reference. Reject an approval. Remove a permission. Introduce a model
timeout. Confirm that it stops instead of improvising a workaround, that the user
sees the authoritative failure, and that the audit trail explains the decision chain.

Only after those controls hold should teams consider write access. Even then, prefer
narrow domain-specific operations over a generic shell or unrestricted Kubernetes
client. An action such as restarting one approved workload can be represented by
a purpose-built tool with validated parameters, making policy and review substantially
clearer.

## The real milestone is operational legibility

Kagent’s builder demonstration is compelling because it compresses agent creation
into the same declarative workflow used for other cloud native resources. The agent
has a manifest, a controller, a runtime identity, and observable readiness. That
makes AI automation less exotic and gives platform teams a workable integration 
point.

Yet the demonstration’s strongest conclusion is that ease of creation raises the
stakes for governance. When anyone can request a new agent in one sentence, organizations
need reliable answers to basic questions: who requested it, which tools it can reach,
which identity it uses, who approved its actions, what it cost, and whether its 
claimed result matches system state.

Kubernetes provides useful primitives for those answers, especially desired state,
RBAC, admission control, isolation, and reconciliation. It does not provide the 
complete answer. Production agent platforms must carry identity and policy across
model, protocol, tool, and API boundaries. Kagent makes the deployment object legible;
platform engineering must make the authority around that object equally legible.

## Sources

 * [CNCF: From zero to agent builder: Running kagent on your laptop](https://www.cncf.io/blog/2026/10/12/from-zero-to-agent-builder-running-kagent-on-your-laptop/)
 * [Kagent documentation](https://kagent.dev/docs/kagent/)
 * [Kagent releases on GitHub](https://github.com/kagent-dev/kagent/releases)