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.

As 2026 rolls on, our capacity to prompt ourselves silly appears to be limitless. We’ve already seen the financial, legal, and reputational damage to Deloitte as they partly refunded the Australian government for a 237-page audit report containing LLM-generated hallucinations like fabricated academic references, fake footnotes, and a false quote attributed to a judge.

Whether it’s vendors diagnosing GPU driver failures or network technicians troubleshooting switch configurations, organizations are often ready to do whatever it takes to get their infrastructure back to normal. For some, that may mean defaulting to the fastest access path available for third-party access, such as shared SSH keys, VPN credentials, or screen-sharing sessions.

You know your servers need hardening. Getting leadership to prioritise, fund, and support the effort is the harder challenge. Here’s our experts’ best advice for how to talk to the C-suite and board about the need for automated server hardening. You already know the servers are drifting. Configurations change. Exceptions pile up. Standards slip over time. The hard part is not identifying the problem.

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.