Skip to content

1 · What is Agentic Cloud Ops?

12 minutes · presentation and discussion

The concept

What separates an agent from traditional automation (CI/CD) and GitOps?

A pipeline executes a predefined sequence. GitOps converges towards a declared desired state. An agent, by contrast, runs a loop:

flowchart LR
    O[Observation] --> D[Decision]
    D --> A[Action]
    A --> O

The difference is that the decision isn't written in advance. You give it a goal, not a procedure.

CI/CD GitOps Agentic Ops
Input A trigger Desired state in Git A goal in natural language
Logic Written up front Declarative diff Derived per run
Determinism High High Low
Handles the unexpected No No Often
Auditability Pipeline log Git history Requires deliberate work

The opportunities

  • Lower MTTR — the agent correlates events, logs and manifests in seconds.
  • Automatic optimisation — resource limits, autoscaling, cleanup.
  • Levelling knowledge — juniors get a senior's debugging patterns on tap.

The dangers

These are the real failure modes

  • Hallucinations that delete namespaces or CRDs.
  • No determinism — same prompt, different result.
  • Runaway loops — the agent fixes what it just broke, forever.
  • Prompt injection via log messages, annotations or container names.
  • Blast radius — one over-privileged service account is enough.

The guardrail that wasn't

A real example from this year, and the single best argument for everything that follows.

CVE-2026-46519 — mcp-server-kubernetes, CVSS 8.8

Three environment variables (ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, ALLOWED_TOOLS) filtered which tools appeared in the tools/list response.

But the filter was never enforced at execution time. A client could skip discovery and call kubectl_delete directly over the MCP protocol.

Fixed in 3.6.0 — the same day it was reported.

The server said it was read-only. The tool list looked read-only. The cluster was not.

A guardrail you can't verify is enforced is decoration.

Keep this in mind during Lab 2, where we build guardrails of our own.

Success criteria

  1. Human-in-the-loop at first. Approve every write until you know the agent's patterns.
  2. Good RBAC. Don't hand out cluster-admin uncritically. Start read-only, widen deliberately.
  3. Genuinely good system prompts. Define scope, forbidden operations, reporting format.
  4. Log everything. Every tool call, every argument, every result.
  5. A rollback that doesn't depend on the agent.

Discussion

Where in your own stack would you let an agent loose today — and what would stop you?