AI With Guardrails
The assistant works from live cluster state, with secrets scrubbed and cluster data fenced off before anything reaches the model. The model proposes, a person approves, and every action runs through the same authorization and audit path as a manual command.
Assistant & Co-pilot
Explain
Point at one resource and get a summary, findings and fix suggestions, grounded in its live state.
Diagnose
Name a workload or namespace and get a likely root cause, the evidence behind it and proposed actions.
Ask & Chat
Questions answered from a live health snapshot. With just a cluster selected, chat still picks up CrashLoop, ImagePull, OOM and Pending-PVC signals.
Co-pilot
Describe a policy in plain English and get default-deny Rego that is parse-checked before you see it. Triage turns free text into a summary and up to three actions.
Operator Memories
Save notes about your environment. The assistant recalls them in chat, read-only.
Bring Your Own Model
Anthropic, OpenAI, Azure OpenAI, Ollama or any OpenAI-compatible endpoint such as vLLM. Self-hosted models work without a rebuild.
Guardrails
Secret Scrubbing
- Private keys, JWTs and Kubernetes ServiceAccount tokens
- AWS, GitHub, Slack, Google, Anthropic and OpenAI keys
- Bearer headers, password / secret / token assignments and passwords in URLs
- Secret objects have their data values replaced before prompting
- Scrubbing runs before cluster text is put into a prompt
Prompt-Injection Fencing
- Cluster-derived text is sanitised: control characters and newlines flattened, backticks dropped
- Every block of cluster data is fenced as untrusted, and forged fence markers are stripped
- The system prompt tells the model that fenced blocks are data, never instructions
- One shared funnel for chat, explain, diagnose, postmortem drafts and remediation explanations
Human in the Loop
- The model proposes actions. It never runs anything on its own
- An approved action runs through the same authorization and audit path as a manual command
- Cluster ownership is required, and privileged verbs need an admin
- Tools from external MCP servers can be run by admins only
- Provider API keys are write-only, encrypted at rest and never returned
- Quota and audit use the caller's verified tenant, not a field in the request
One-Click Remediations
Common failures are detected from Kubernetes events and turned into a proposed fix. Nothing changes until an operator approves it.
| Symptom | Proposed fix |
|---|---|
| Crash loop | Restart the owning Deployment |
| OOMKilled | Raise the memory limit ×1.5 on the Deployment, StatefulSet or DaemonSet |
| Failing rollout | Restart the Deployment |
| Node pressure | Cordon the node |
| Image pull / Pending | Informational, with the cause parsed from the event |
- A detector reads the archived Warning events every 30 seconds over a 15-minute window
- An LLM, if configured, writes only the explanation. It never picks the verb or its arguments
- The approve dialog shows the exact arguments that will be dispatched, and the browser cannot swap in a different verb
- A 30-minute cooldown after approve or dismiss; a symptom that returns after it comes back at higher severity
- Works without an LLM, using a template explanation
Model Context Protocol
Your Fleet as an MCP Server
- Every agent verb is an MCP tool named k8s.<verb>, with the target cluster as an argument
- Same ownership checks, privilege gates and audit trail as the REST API. MCP is not a bypass
- Bearer-token auth, re-checked on every request
- Supports the 2026-07-28 protocol and the 2025 legacy versions
MCP Extensions
- Register remote MCP servers over HTTP for the assistant to use
- Reach an MCP server inside a spoke through the agent. The target is a declared Service port, never a free-form URL
- Every call is logged in a hash-chained record with an integrity check. Arguments are stored only as SHA-256
- If the log entry cannot be written, the call fails. The manager never spawns local processes