Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

The first time a security team needs an AI agent audit trail is usually 72 hours after the agent has already done something it shouldn’t have. Detection fires. Someone pulls every relevant log from the SIEM (Kubernetes audit, container runtime, cloud audit) and three hours in realizes the events that actually matter were never written. Which prompt triggered the tool call. Which parameters the agent passed. Which output left the cluster.

Every AI-SPM tool runs posture and detection with a single arrow: runtime evidence flowing back to rank posture findings. The load-bearing direction runs the opposite way, and almost nothing runs it — posture flowing forward to tell the detection layer what an attack even looks like.

A security team running agents in production can already list the ways those agents get attacked: prompt injection, memory poisoning, tool abuse, model tampering, agent-to-agent coercion. The list is not the problem. The problem is that a security architect can recite all five and still not know which ones their detection stack will catch, because the way the field catalogs these attacks says nothing about whether the attack is catchable.

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.

On workload identity, a spec the industry has already started building around, and what the next layer looks like. I don't have a better answer than SPIFFE (Secure Production Identity Framework for Everyone) for workload identity, and that's where I want to start, because what follows is going to sound like I do.