Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Your coding agents run overnight on cloud dev boxes, with auto-approve on and an organization token in the environment, and the only thing standing between a public repository and that token is whatever the repository’s README tells the agent to do.

Prompt injection is three things happening at once. The definition written in 2022 described a model that followed an instruction hidden in the text it was asked to translate. The definition needed in 2026 describes an agent that read a support ticket and then queried a customer table it had never touched, using a service account nobody had revoked. Those are the same attack.

Prompt injection has not changed since 2022. What the model can do has. The instruction that hijacked a translation bot four years ago and the one that opened a homeowner’s windows last year are the same request: do something you are already allowed to do. The first system could only talk. The second could operate devices. Same sentence, different consequence. Here are ten real attacks, in order, and for each one the thing the system was allowed to do that made it work.

Prompt injection has a CWE, and the two incidents everyone cites were not filed under it. That is not a clerical detail. A CWE ID is a claim about root cause, and every entry carries a mitigation table that follows from the root cause it names. When a record says CWE-1427, it is saying the product failed to neutralise input before building a prompt, and it is implying that neutralising the input is the fix.

A prompt injection test suite can only report on the payloads it contains. That sentence is the whole problem with the number most teams have. Somewhere in a ticket there is a scan result: a scanner threw several hundred probes at the endpoint and a percentage got through. The percentage is real.

Here is a scene every security team knows. A reverse shell opens a connection to an external address, pulls a service-account token, and starts moving against your cloud identity. Two rows below it on the same dashboard sits a payload that hit a front-end container and never executed. Both are tagged high severity. Both are competing for the same analyst’s attention at the same moment.

Most teams buy detection on a single number. The datasheet says “millisecond detection,” the proof-of-concept fires the instant a test payload lands, and the box gets checked. Then a real AI agent incident runs in production, and the postmortem shows the attack completed its objective well before anyone contained it, even though the alert, technically, fired in milliseconds. The number was real. It just measured the wrong thing.

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 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.