Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

The early stages of an AI agent attack are silent. The poisoning, the hijacked intent, the reconnaissance: none of it executes, so none of it produces a runtime signal, and the kill-chain instinct every security team runs on says exactly the wrong thing here: break the earliest link. There is no early link to break. You cannot detect a stage that emits nothing.

A compromised agent doesn’t make a single call it isn’t allowed to make. It queries a table it’s authorized to read, calls a tool it’s authorized to use, sends to a domain that’s on the allowlist. Every call is legal. The attack is in the values it passes, and your tool-call log records all of it as a clean day’s work. A tool call has two layers. Almost every tool you run reads the first one: the call itself: which tool, in what order, at what rate.

Your AI agent just did something it has never done. It called a tool that is not in its usual set, or it opened a connection to a destination you do not recognize, or its output came back subtly wrong. So you do what anyone does: you search for what a compromised agent looks like, and you find a checklist. Unusual tool usage. Unexpected data access. Out-of-context responses. Elevated resource consumption.

An AI agent moving laterally through a Kubernetes cluster does not look like an intrusion. There is no foreign process, no exploit, no dropped binary — just the agent using the identity, network routes, and tools it was handed at deployment to reach targets it was technically allowed to touch. That is the entire problem. The controls you run were built to catch an outsider pivoting from host to host.

If you’re weighing open source against commercial tools for detecting attacks on your AI agents, you’re probably trying to answer a single question. Can we build this ourselves, or should we buy it? It’s a fair question, and the existing content on it isn’t much help. Most comparisons line up tools side by side and tally features. That tells you which tool is better at one slice of the problem. It doesn’t tell you whether you have a working detection program.

Most enterprise AI agent governance programs publish policies at the bottom three rungs of a runtime enforceability ladder while their architecture diagrams claim rung four. Almost no program reaches rung five, the only rung that produces evidence an auditor cannot dispute. The mismatch shows up in the audit committee meeting. The CISO walks in with the NIST AI RMF mapping, the AUP, the model cards, and the vendor risk assessments for every third-party API the agents call.

A CNAPP isn’t a single instrument. It bundles five separately-instrumented security domains — CSPM, CWPP, CIEM, CDR, and a fifth add-on module marketed as AI security — each watching a different observation point. So when leadership asks whether your CNAPP can secure the AI agents your team has shipped, you don’t get one answer. You get five.

Your platform team already runs a production-readiness review on every workload that ships to Kubernetes. When the workload is an AI agent, the PRR doesn’t get thrown out — it gets a delta. Most of the items still apply; specific ones need extension when the workload is non-deterministic, calls tools dynamically, and exercises identity at runtime in ways the manifest didn’t predict.

Most threat modeling assumes the attacker has to break something. AI agents change that assumption. An attacker who controls a prompt can make the agent misbehave without breaking anything at all. The prompt can be a customer support ticket the agent reads, a document it retrieves, or a tool response it processes — any input the agent treats as context is an attack surface. On Kubernetes, that attack surface has physical form.

Every guide to AI agent observability tells you what to capture — prompts, tool calls, token usage, traces, syscalls. Almost none address which of those signal sources you can still trust when the agent itself is part of the threat model. That distinction is the entire difference between observability that helps your SRE team debug a slow reasoning chain and observability that helps your security team investigate a breach.