Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Editing IAM policies cannot fix the most common architectural mistake in shipping AI agents on Kubernetes. It happens in thirty seconds: a platform engineer reuses an existing ServiceAccount with an IRSA annotation for Bedrock access because creating a new one takes thirty minutes plus a Terraform pull request. The new agent ships under the existing identity.

Your risk committee meets Thursday. The agenda has a new item: AI agent risk posture. You open the register. The fraud detection agent shipped in March is on it. So is the customer service agent. Neither row is useful — “likelihood: medium, impact: high, control: service account scoped via IAM.” Three months ago that was approximately right. Last week the platform team added two MCP connections, the model was upgraded, and the agent now touches data classes the entry never anticipated.

Most “hardening” advice for AI agents is a checklist of things to configure before the agent runs. CIS Kubernetes Benchmark gates. Pod Security Standards baselines. NetworkPolicy templates. None of it’s wrong — it’s just one of four phases, the one your stack already covers. The other three are Observe, Enforce, and Reconcile. They’re where AI agents actually get breached, and they’re where most stacks have nothing.

Every AI workload security PoC reaches the same conversation. Platform engineering pushes back: the AI team won’t accept extra latency on inference. The security engineer hunts for benchmarks and finds a contradiction. Langfuse publishes 15% overhead. AgentOps publishes 12%. The security vendor quotes 1–2.5%. None is lying. They measure different layers.

It’s 2 a.m. and the SOC has a Tier 3 page. A customer-service agent on the production cluster has just wired refund payments to seven addresses outside the approved disbursement list. The runbook is unambiguous: isolate the pod, image the disk, image the memory, root-cause within 48 hours.

Your AI agent runs on AKS with a managed identity that can read Azure Key Vault, and you assume prompt injection is a theoretical risk—until a malicious prompt drives that agent to steal credentials from the Azure metadata endpoint in under a minute. Most teams discover this gap when their SIEM shows a single request to 169.254.169.254, but they cannot trace it back to which agent tool or prompt triggered it, or how far the stolen token traveled across their Azure environment.

For six weeks, a mid-size hospital system’s CDS agent issued recommendations biased by a poisoned guideline summary. No detection alert fired. The drift — denial recommendations in cases sharing one specific clinical attribute — traced back to a guideline an outside contributor had quietly reweighted in editorial review. Every existing detection stack reported green. DLP: no PHI left the cluster. EHR audit log: agent reading and writing within scope. Network egress: normal traffic.

A healthcare CISO opens her AI-SPM dashboard at the start of the quarter. Every clinical AI agent in the cluster reads green: full AI-BOM coverage, every permission scope reconciled, the HIPAA compliance tag clean across the fleet. The ambient scribe, the prior-authorization assistant, the oncology decision support agent — all monitored, all green, all the way through. Six months later, the Office for Civil Rights opens an investigation.

Observe-to-enforce builds behavioral baselines from observed agent traffic — what tools the agent calls, which networks it reaches, which syscalls it executes — and converts them into per-agent enforcement policies. Baselines persist at the Deployment level because pods churn and the envelope has to outlive any single restart. The methodology runs as a four-stage progression: discovery, observation, selective enforcement, continuous least privilege.

It is 11:47 p.m. and the on-call security engineer is staring at two dashboards. On the left, LangSmith — the ML team’s debugging stack — showing the agent’s prompts, model responses, tool calls, and tokens consumed. On the right, the runtime detection console showing eBPF-captured syscalls, network connections, and process trees from the same Pod. Both are populated.