Google Threat Intelligence Group’s latest report is useful because it avoids the cartoon version of “AI cyber risk”. The message is more practical and more uncomfortable: adversaries are not waiting for some future superintelligence. They are already using today’s models to accelerate vulnerability research, malware development, reconnaissance, fraud infrastructure and attacks against AI software components.
For executives, the important point is not that AI suddenly makes every attacker brilliant. It is that AI reduces friction in several parts of the attack lifecycle. Work that used to require more time, more people, or more specialist knowledge can now be assisted, repeated, and scaled. That changes the economics of attack.
The strategic risk is not that AI creates entirely new cyber magic. The risk is that it makes ordinary offensive work faster, cheaper, and easier to industrialise.
The Google report describes a maturing shift from experimental AI use toward more operational use by threat actors. Several patterns stand out.
None of this means that every attacker now has advanced capabilities. It does mean the baseline is moving. The lower-cost attacker becomes more capable, and the capable attacker becomes faster.
Many organisations still discuss AI security as a model-risk topic: hallucination, bias, privacy, prompt injection, and policy compliance. Those remain important. But the GTIG report points to a wider operational reality. AI is now part of the attacker’s tooling, and your own AI ecosystem is becoming part of the attack surface.
That creates two linked questions for leadership:
If those questions are not visible in the security roadmap, the organisation is probably treating AI as an innovation programme but not yet as an enterprise operating risk.
Existing controls still matter. Patch management, MFA, endpoint protection, logging, secure coding and supply-chain governance did not become obsolete. In fact, they became more important. But AI-enabled adversary behaviour puts more pressure on their weak spots.
For example, vulnerability management cannot rely only on monthly prioritisation rituals if attackers can use models to accelerate exploit understanding. Identity controls cannot assume that phishing quality remains easy to spot. Software supply-chain governance cannot stop at “we use reputable packages” when malicious pull requests, poisoned dependencies and compromised build environments are now part of the AI platform story.
The gap is often not the absence of controls. It is the lack of integration between AI adoption, software supply chain, identity, secrets management, detection engineering and incident response.
The report’s discussion of AI components and agent ecosystems is especially relevant for companies experimenting with autonomous tools. Agents become useful when they can use tools, read files, call APIs, run commands, update tickets, query databases or orchestrate workflows. Those same permissions create a new control problem.
If an agent can do useful work, a compromised dependency, malicious skill, unsafe plugin, prompt-injection chain or stolen API token may be able to do useful damage. This is why “agent security” should not be treated as a novelty topic. It is a normal privileged-access problem with new interfaces and faster execution.
Practical governance should cover:
The answer is not to ban AI tools. That would be both unrealistic and strategically weak. The answer is to update the threat model and make the defensive operating model more explicit.
Review the attack paths where speed matters: internet-facing systems, identity recovery flows, software build pipelines, support desks, finance approval processes and privileged admin tooling. Ask what changes when an attacker can automate research, generate code, test payloads and craft credible messages faster than before.
List the AI gateways, SDKs, agent frameworks, plugins, skills, wrappers, prompt libraries, model APIs and CI/CD integrations in use. Many organisations will discover that their AI estate is larger than the formal architecture diagram suggests.
Prompts are not just text. In agentic systems, prompts can define behaviour, tool use, escalation logic and data access. Skills and plugins are software. They deserve review, approval, ownership and rollback paths.
AI tools often sit near valuable credentials: API keys, cloud tokens, repository access, ticketing systems, document stores and customer data. Use short-lived credentials, scoped permissions and strong logging. Assume mistakes will happen.
Look for abnormal API aggregation, unusual model calls, suspicious automation in developer environments, new outbound network patterns, high-volume account activity, and unexpected tool execution by agents or CI jobs.
Can the team disable an agent safely? Rotate model API keys? Revoke plugin access? Identify which workflows used a compromised package? Rebuild from trusted dependencies? If not, the response plan is incomplete.
AI changes cyber risk less like a single new weapon and more like a productivity platform for offence. It helps attackers write, test, research, coordinate and scale. It also creates new targets inside the AI software layer that many organisations are adopting faster than they are governing.
Security leaders should avoid both extremes: dismissing the issue as hype, or treating it as science fiction. The practical middle is better. Update the threat model, protect the AI supply chain, constrain agent permissions, monitor the new telemetry, and make sure incident response can move as quickly as the systems being deployed.
In short: if AI is becoming part of how the business operates, it must also become part of how the business defends itself.
Source: Google Cloud Blog, “GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access”.
We help organisations navigate complex regulatory and technology challenges. Let’s talk.
Get in Touch