AI has already changed how developers write software. It is now changing how attackers exploit the decisions developers make while writing it.

That is the more important takeaway from Google Threat Intelligence Group's latest research on adversarial AI. GTIG found that threat actors are moving beyond simple prompting into agentic workflows that can plan, adapt, and execute with far less human involvement. At the same time, attackers are increasingly targeting AI coding assistants, open-source packages, and the developer environments where software decisions are made.

Why does adversarial AI change developer trust?

For DevSecOps leaders, this creates a different kind of application security problem.

The risk is no longer limited to whether insecure code enters a repository. It is also about whether a developer, or an AI coding assistant acting on their behalf, can correctly judge what should be trusted.

A dependency may look legitimate. A package may carry valid build attestations. A workspace file may appear routine. Yet GTIG documented cases where attackers manipulated exactly these trust signals. For example, UNC6780, popularly known as TeamPCP, used compromised developer accounts, malicious MCP packages, and stolen CI/CD tokens. GTIG found that compromised packages could even pass automated AI coding agent trust checks when attackers published them using valid tokens.

This is where developer-first code security needs to become more contextual.

Developers should not have to become threat intelligence analysts before accepting a package or approving a change. Security systems need to bring risk context into the workflow: Is this dependency actually reachable? What could the change affect? What is causing the vulnerability in the first place?

Flyingduck approaches that problem through capabilities such as Reachability, Impact Analysis and Root Cause Analysis. The point is not simply to generate another finding. It is to turn that finding into a decision a developer can act on without reconstructing the risk manually.

Why does AppSec need decision-first security?

GTIG observed a threat actor use an AI coding chatbot, prompts and agent instructions to plan, build and execute a mass credential-harvesting campaign in under six hours. Its multi-agent framework could manage vulnerability scanning, troubleshoot operational errors and rotate infrastructure with limited human intervention. GTIG also sees adversaries progressing toward increasingly autonomous exploitation, although fully autonomous attack pipelines are not yet broadly observed in the wild.

That changes the economics of DevSecOps security.

Detection-first security assumes there is enough time to find an issue, add it to a queue, review its severity, and decide what deserves attention. AI-assisted attacks and autonomous workflows continue to compress that window.

The answer is not to abandon shift-left but to make it more decisive.

Chris Hughes reaches a related conclusion in his analysis of AppSec in the age of agents. As AI automates more discovery and triage, judgement becomes a scarce resource. He argues that modern AppSec has to rely more heavily on exploitability, reachability, and business context instead of treating raw severity as the primary measure of risk.

This makes decision-first AppSec a strategic evolution of shift-left, not a replacement for it.

For DevSecOps leaders, that means understanding whether a vulnerability is exploitable, determining its application impact before remediation, and giving developers enough context to make a safe change quickly.

The next generation of application security will still detect vulnerabilities.

But detection will increasingly be the starting point.

The advantage will come from knowing what matters, why it matters, and what the safest next action should be.