When Attackers Get AI: What Google’s GTIG Report Means for Enterprise Defence

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.

What GTIG observed

The Google report describes a maturing shift from experimental AI use toward more operational use by threat actors. Several patterns stand out.

  • AI-assisted vulnerability discovery and exploit development. GTIG reports threat actors using AI as a force multiplier for vulnerability research, including a zero-day exploit that Google assesses was developed with AI assistance.
  • AI-supported malware and evasion. Adversaries are using models to help write operational tooling, generate decoy logic, create obfuscation, and support polymorphic behaviour.
  • AI-enabled attack orchestration. Malware such as PROMPTSPY shows how models can interpret device state and return structured actions, moving closer to autonomous operational loops.
  • Better reconnaissance and social engineering. Models help attackers research organisations, map roles and relationships, identify target environments, and generate more credible lures.
  • Industrialised access to AI services. Actors are building middleware, proxy services, account-pooling systems and automated registration pipelines to obtain or resell premium model access at scale.
  • Attacks against AI components themselves. AI wrappers, open-source skills, plugins, API gateways and CI/CD dependencies are increasingly attractive initial-access paths.

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.

The board-level interpretation

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:

  1. How does AI change the speed and shape of attacks against us?
  2. How exposed are our AI tools, agents, dependencies and credentials?

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.

Where traditional controls start to feel thin

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.

AI agents add a permission problem

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:

  • Tool permissions: agents should get the minimum tools needed for the task, not a general-purpose key to the building.
  • Dependency provenance: skills, plugins, wrappers and model gateways need source review, version pinning and security scanning.
  • Secrets isolation: agents should not casually inherit broad environment access or long-lived production credentials.
  • Execution boundaries: file access, command execution, network calls and external posting should be gated by policy and logs.
  • Monitoring: agent activity should produce telemetry that security teams can actually inspect.

What to do now

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.

1. Refresh the threat model for AI-assisted adversaries

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.

2. Inventory the AI software supply chain

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.

3. Treat prompts, tools and skills as operational assets

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.

4. Harden secrets and service accounts around AI workflows

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.

5. Improve detection for AI-shaped activity

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.

6. Run incident-response exercises for AI components

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.

The leadership takeaway

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

Previous PostNext Post

Related Articles

Article

The Axios Attack: Why You Cannot Trust Your npm Dependencies by Default

Read →

Article

OpenClaw Security: What Enterprise Teams Must Do Before Deploying AI Agents

Read →

Article

AI Risk Is Not Just ISMS With Better Marketing

Read →

Related Services

Service

Software Development Maturity Assessment

Learn More →

Service

Privacy & IT Security Assessments

Learn More →
Miloš Cigoj
Miloš Cigoj Founder, Excellence Consulting  ·  Operational Excellence & AI Strategy

Interested in this topic?

We help organisations navigate complex regulatory and technology challenges. Let’s talk.

Get in Touch