Google Threat Intelligence Group published a new threat tracker on 8 September 2026 describing attackers moving from isolated prompts to agent-enabled workflows. Its clearest operational example is a suspected financially motivated actor that compromised a cloud environment and then used an AI coding chatbot, a prompt, and prepared instruction files to plan and execute mass credential harvesting in less than six hours.
Google says the agent managed vulnerability scanning, troubleshooting, and IP rotation without continuous human intervention. The report also describes malware that placed malicious files inside project directories used by coding assistants, changed startup hooks, and embedded instructions intended to manipulate AI tools or cause security scanners to skip analysis.
These are Google and Mandiant observations, not a complete measure of global attacker activity. Independent security coverage confirms the report and its central examples, but the underlying telemetry is controlled by Google and cannot be reproduced from the public article alone.
The attack workflow changed more than the tools
Automation in cyber operations is not new. The material shift in Google's report is that an agent handled connected decisions across a workflow. It could keep a scanning pipeline moving, respond to errors, rotate infrastructure, and continue harvesting credentials while the human operator stayed further from each step.
That reduced delay changes the defensive problem. A policy that waits for an analyst to inspect every alert may not keep pace once one instruction set can drive several actions. Teams need controls at the identity, network, tool, and task boundaries, with automatic stops for behavior outside the authorized purpose.
Google says the observed actor operated from compromised cloud infrastructure, allowing traffic to originate from legitimate addresses. That weakens simple reputation checks. It also means cloud accounts, compute quotas, service credentials, and AI tool subscriptions should be treated as high-value attack targets, not only as developer conveniences.
Project instruction files became part of the attack surface
The report links one supply-chain actor, tracked as UNC6780, to several techniques aimed at AI development tools. Google says the actor published malicious forks of MCP servers, modified hidden project folders used by coding assistants, and added startup commands that could execute when a workspace opened.
The same malware reportedly placed adversarial instructions in source comments to trigger safety refusals in LLM security scanners. That does not prove every scanner will fail. Google says its own safety systems reacted and that it took action against the campaigns. The example still shows why a refusal can become a form of evasion if the scanner stops before inspecting the code beneath the bait.
Repository trust should therefore include more than dependency names. Teams should review hidden agent directories, hook files, task instructions, CI workflows, MCP server definitions, and changes to trusted publisher configuration. Maetra's guide to prompt injection controls for AI agents explains why untrusted instructions must be inspected before they reach a tool-capable model.
Defenders need controls that survive agent speed
The report supports five immediate actions:
- Give every agent and automation identity the least privilege needed for its task.
- Block unapproved changes to project instruction files, hooks, CI workflows, and MCP configuration.
- Restrict network egress from coding agents and security scanners to required destinations.
- Detect unusual credential access, rapid IP rotation, new cloud workloads, and deleted workflow logs.
- Preserve the proposed action, policy decision, execution result, and downstream effect for investigation.
These controls should be connected. A secure prompt filter cannot compensate for an overprivileged cloud identity, and an audit log is weak if an attacker can delete the event at the same privilege level used by the agent.
The runtime AI security guide offers a broader control model for prompts, tool calls, credentials, and evidence. For this threat class, the central question is whether one compromised file or credential can silently redirect a long-running agent.
What is verified and what remains uncertain
Google reports that one campaign compromised thousands of third-party credentials and that a separate exposed command server later managed more than 23,800 harvested secrets. Those quantities should remain attributed to Google. The public report does not identify every victim, provide a complete sample, or establish how common autonomous attack frameworks are across all incidents.
It also distinguishes observed operations from experimentation. Some groups tried to design automated penetration testing agents, while Google says it disabled associated assets before the planned framework became an observed live operation. In information operations, Google saw interest in interactive bots but did not observe those capabilities deployed successfully.
That precision matters. The report supports the claim that attackers have used agents for a real credential campaign. It does not support the broader claim that autonomous agents now dominate cybercrime.
Maetra analysis
The strongest lesson is that task instructions are executable security context. A file named AGENTS.md, a hidden IDE directory, or an MCP configuration can influence an agent just as surely as a user prompt. Those assets need owners, change history, review rules, and runtime checks.
Teams should define what each defensive or development agent is allowed to accomplish, which tools and destinations it may use, and what evidence proves the effect. A change in task files, identity, network route, or repository trust should trigger a fresh evaluation instead of inheriting old authority.
Agent speed is useful for defenders and attackers. The safer advantage comes from combining automation with narrow permissions, deterministic boundaries, independent monitoring, and records that an attacker cannot rewrite from the agent's own execution context.