The pattern
Agent-tooling CVEs tend to collapse into the same shape: untrusted or weakly reviewed input becomes trusted instruction, and trusted instruction reaches a privileged action. The exploit details vary, but the operating failure is consistent.
Security teams should map every path where an agent can read configuration, discover tools, install packages, run commands or open a code change. Those paths are now part of the execution boundary.
Why it matters
Traditional application controls were built for requests, users and services. Agent tooling adds a new layer: software that interprets context and then chooses tools. If that layer can mutate files, call CLIs or publish changes, the blast radius is larger than a chat transcript.
The lesson is not to ban automation. It is to make the allowed action set explicit and enforce it before the tool call runs.
Control model
Treat every agent tool call as a policy decision. Bind it to identity, scope, tool name, arguments, destination, policy version and evidence. If the request falls outside the approved boundary, hold it for review before public or privileged action happens.
Policy before action. Evidence after execution.