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.
