[Disclaimer: The opinions, insights, and perspectives shared in this session are solely my own and do not reflect those of my current or past employers, nor do they convey any confidential information by any means.]

Note (07/11/26): Awaiting employer approval before sharing the detailed and complete session description to respect guidelines and comply with policies.

Overview:
In May 2026, the Sysdig Threat Research Team documented the first confirmed agentic threat actor (ATA) kill chain on Kubernetes: a compromised LLM harness exploited a vulnerable notebook, replayed stolen service-account tokens to dump the cluster's entire Secret store, and executed container escape - fully automated, with no human operator in the loop.¹ The original Kubernetes threat model assumed the thing inside the pod was a stateless web service. An agentic AI workload is categorically different: when an agent is compromised, the attacker inherits its tool surface, its credentials, and its authority to act. RBAC misconfigurations already account for over 35% of Kubernetes breaches² - agentic workloads amplify that blast radius in ways the cluster was never designed to contain.

Structure:
Layer 1: Why the Kubernetes Threat Model Breaks for Agentic Workloads
(Service Account Scope, automountServiceAccountToken & Token Replay)
Most agent pods are deployed with service accounts scoped far beyond what the agent actually needs - because nobody planned for the agent to be the attacker's entry point. We cover how token auto-mounting + over-permissioned service accounts create an immediately exploitable path from prompt injection to cluster-wide Secret access, how the ATA kill chain from the Sysdig incident actually executed, and the minimal RBAC pattern every agent pod should start from: `automountServiceAccountToken: false`, namespace-scoped Roles, and just-in-time credential provisioning per CNCF agentic standards.³

Layer 2: MCP Servers as Pod-Level Attack Surface
(Container Hardening, Namespace Isolation & Schema Trust)
MCP servers running inside the cluster are becoming a default integration pattern for agentic tool connectivity - and each one is a trust boundary that needs to be hardened independently. A minimally scoped MCP pod looks very different from what most teams ship: its own namespace, dedicated service account, restricted Pod Security Admission profile, and schema validation on every tool call. We cover container-based lateral movement (up 34% in 2025²), what a malicious or compromised MCP server can access in a default cluster configuration, and the hardening checklist to close those gaps.

Layer 3: Observability as a Security Control for Agent Workloads
(Detecting Agentic Failure Through Runtime Signals)
In agentic systems, the first observable signal of a security event is often not an alert - it's an anomaly in query volume, API call rate, or inter-pod traffic that no existing dashboard was watching for. We examine how to extend cluster observability for agent-specific signals: detecting uncontrolled agent spawning through pod creation rate, identifying token replay through API server audit logs, and using resource consumption spikes as a canary for compromised agent behavior. Runtime protection and configuration drift detection are the last line of defense when prompt injection bypasses every upstream control.

Attendees leave with:
- A threat model for agentic workloads on Kubernetes grounded in the 2026 CNCF agentic standards
- A pod-level hardening checklist: service account scoping, `automountServiceAccountToken`, Pod Security Admission (restricted profile), and namespace isolation for MCP servers
- Observability patterns for detecting agentic security events through runtime signals before exfiltration completes
- A just-in-time credential provisioning pattern as an alternative to over-permissioned service accounts

These patterns are not theoretical - a threat actor already ran this playbook on a production cluster in 2026. The question is whether your agent workloads are hardened before the next one does.

Citations:
¹ Sysdig Threat Research Team, "Agentic threat actor hits the orchestration plane: AI agent-driven container escape," May 2026. sysdig.com
² Vector Labs, "Running AI Agents on Kubernetes: The Security Architecture Gaps Most Teams Discover Too Late," 2026. vector-labs.ai
³ CNCF, "Cloud native agentic standards," March 2026. cncf.io/blog

Sources:
- Sysdig - Agentic threat actor hits the orchestration plane: https://www.sysdig.com/blog/agentic-threat-actor-hits-the-orchestration-plane-ai-agent-driven-container-escape/
- CNCF - Cloud native agentic standards: https://www.cncf.io/blog/2026/03/23/cloud-native-agentic-standards/
- CNCF - Why cloud native belongs at the heart of agentic AI: https://www.cncf.io/blog/2026/06/17/why-cloud-native-belongs-at-the-heart-of-agentic-ai-lessons-from-building-a-multi-agent-security-platform-on-kubernetes/
- Vector Labs - Running AI Agents on Kubernetes: https://vector-labs.ai/insights/running-ai-agents-on-kubernetes-the-security-architecture-gaps-most-teams-discover-too-late/
- KubeFence: Security Hardening of the Kubernetes Attack Surface: https://arxiv.org/pdf/2504.11126