AI Agents for Kubernetes: Access, Diagnosis, and Review

AI agents can read cluster state, diagnose failing pods, suggest configuration changes, and draft manifests for review. The key word is review: no agent should apply changes to a Kubernetes cluster without a person confirming the action. Tools like fenbs let you record the approved operating rules and change history that every agent session reads before touching a cluster.

Kubernetes clusters run production workloads. A misconfigured resource limit, a wrong namespace selector, or an accidental delete can cascade quickly. The goal with AI assistance is to speed up investigation and drafting while keeping every actual change in human hands.

What an agent can and cannot do in a cluster

Reading is low risk: agents can describe running pods, summarize recent events, inspect service configurations, and identify resources that look misconfigured. Generating a corrected manifest for human review is also useful. Applying that manifest, restarting deployments, or deleting resources are actions that must stay with a person who can assess the downstream effects.

• Describe pod status, recent events, and container logs within a scoped namespace.
• Identify mismatches between service selectors and pod labels.
• Draft a corrected manifest based on observed configuration.
• Summarize resource usage and flag pods that have restarted frequently.
• Propose a change to resource requests or limits with a reason.

Everything in that list produces output for a person to review, not a cluster change. If an agent has kubectl access, restrict it to read-only verbs at minimum, and consider a dedicated low-privilege service account with explicit verb and resource bindings rather than a broad role.

Controlling cluster access for an agent session

Before connecting an agent to a cluster, decide what it may read and from which namespaces. A Kubernetes RBAC role binding that allows only get, list, and watch on pods, services, deployments, and events in one namespace is much safer than a cluster-admin binding. Create a dedicated service account for agent use, and rotate or revoke its credentials after a session ends.

Use a separate context in your kubeconfig for agent sessions. That way the agent cannot accidentally switch to a production cluster when you intended a staging one. Audit logging on the API server will show what the agent actually called, which is useful if a session produces unexpected output.

Avoid giving an agent access to secrets unless the specific task requires it, and never paste secret values into a prompt or store them in a shared task record. If the diagnosis requires reading a secret, do that step yourself and share only the relevant non-sensitive conclusion.

Scoped investigation before proposing a change

Give the agent a specific symptom to investigate, not an open-ended instruction like "fix the cluster." A focused prompt produces a more useful result: "The payments service in the staging namespace has been in CrashLoopBackOff for twenty minutes. Describe the recent events and the last fifty lines of the container log, then suggest a cause."

Ask the agent to distinguish between what it observed and what it inferred. "The container exits with code 137, which usually indicates an OOM kill" is more useful than "the memory limit is wrong, increase it." The observation is verifiable; the proposed fix is a starting point for your review.

Reviewing change proposals before applying them

Treat every agent-generated manifest or configuration change as a draft, not an answer. Read the diff. Check that the change does exactly what the agent described and nothing more. Look for side effects in other namespaces, changes to selectors that could orphan pods, or resource increases that push a node past its allocatable capacity.

Apply changes in staging first and watch the affected workloads. Only carry the change to production after verifying the staging result. Keep the manifest diff in a task record so that if the change has to be reverted, you have the exact version to roll back to.

Keeping approved rules and a reviewed change history

When a change is approved and applied, record what changed, who approved it, and what the cluster looked like before. That record lets you answer "what changed on Tuesday?" without reconstructing it from memory or searching log aggregation tools. It is also the starting point if the change has to be partially reverted.

Decisions that hold across all cluster work — for example, "no agent may apply changes directly; all changes go through a pull request" or "resource limit increases above 2x must go to a second reviewer" — belong in a shared rules record rather than in individual session instructions. Writing them once means new team members and new agent sessions start with the same expectations.

How to do this with fenbs

Start with the one rule your team always has to remind people of before an agent session. Write it as a standing Decision in fenbs, then connect your agent and ask it to read the project context before touching the cluster.

1. Create a free account. Add your infrastructure project with a short description of the cluster environment and its purpose.
2. Add the current open incidents or change proposals as tasks. Include the namespace, symptom, and what has already been tried.
3. Write your first operating rules in Decisions and rules. Include access scope, the change-approval process, and any actions agents are not permitted to take. Mark each as a standing rule.
4. Connect your coding or terminal agent at Integrations. Use a read-only service account in the cluster. Approve read and write access to fenbs so the agent can record findings and update tasks.
5. After each investigation session, ask the agent to update the task with what it observed, what change it proposed, and whether any new rule should be considered. Record approvals and applied changes in the task before closing it.