From Spain to Australia: AI agents raise the stakes for cyber fundamentals

From Spain to Australia, recent incidents are providing some of the clearest real-world examples yet of AI agents becoming part of the cyber incident landscape. In Spain, an AI agent was reportedly used as the instrument of an attack. In Australia, an autonomous AI agent carrying out a legitimate research task gained unintended access to a government system. And between the two, researchers found AI coding agents inside major organizations following external instructions and installing packages their operators had not intended them to.

The circumstances are different, and they should not be conflated. But together they raise an important question for businesses and cyber insurers: as increasingly autonomous software is given access to real systems, data, and permissions, are the cybersecurity fundamentals keeping pace?

Because while the technology – and what we are asking it to do – is evolving quickly, many of the principles that can prevent an incident or limit its impact are not new at all.

Hola, hacker. G'day, government.

In September, Spain's data protection authority, the AEPD, disclosed the first breach notification it had received in which an AI agent was reportedly used as the instrument of an attack.

According to the reporting organization, the agent searched for vulnerabilities, logged into an application, navigated it autonomously, modified personal data, and accessed invoices. The AEPD has not independently verified that account and cautioned that the involvement of a particular AI model does not mean the model or its provider was itself compromised.

Then came Australia.

An autonomous OpenAI agent conducting research gained unintended access to a government statistics portal containing non-public Medicare information. The incident occurred in June, but the Australian government was not notified until September. OpenAI says it found no record of patient data being accessed.

The response has gone beyond investigating the incident itself. Australia has launched a rapid review examining whether its existing legislation and governance are ‘fit for purpose’ for cyber incidents involving AI.

Between those two events came another warning sign.

Security researchers investigating AI coding agents found agents operating inside major organizations reading instructions from vendor documentation and executing commands that pointed to packages and domains nobody owned. Researchers registered some of those abandoned names and published harmless test packages. Within an hour, a Fortune 500 company had connected to one, followed by other organizations.

There was no phishing email or stolen password behind the researchers' experiment. The agents encountered instructions they regarded as authoritative and acted on them.

Different incidents. Different causes. But beneath the novelty of autonomous AI sit some remarkably familiar cybersecurity questions:

• What was the system allowed to access?
• What permissions did it have?
• How effectively was data segmented?
• What could it do with the credentials it had been given?
• And what limited the blast radius when something unexpected happened?

The corners that get cut

The pressure on organizations to adopt AI is considerable.

Businesses are looking to agents to write code, analyze information, automate processes, interact with customers and carry out tasks across internal systems. But for an agent to be genuinely useful, it often needs something more consequential than a prompt.

It needs access.

That can mean access to data, applications, APIs, file stores, email, code repositories, and internal systems. It can mean credentials. And increasingly, it can mean permission not simply to retrieve information, but to take actions.

This is where speed can come into conflict with some of the most basic disciplines of good cyber hygiene.

Least privilege is usually the first casualty. In engineering, it is a tedious discipline: every permission request gets assessed against the use case it is actually for, access starts as narrow as the job allows, and it widens only when something genuinely needs it to.

Agents can invert that process. Scoping permissions properly is fiddly. Handing over broad credentials is quick. And when the pressure is to get an AI tool working and demonstrate value, the quickest route can easily become the default.

The difference may only become apparent when something goes wrong.

An agent that can access one tightly controlled system has a limited blast radius. Give the same agent broad permissions across multiple systems and an unintended action, malicious instruction or compromised interaction can have very different consequences. After an agent incident, the useful question is not simply how something got in. It is why the agent could reach that data or system in the first place.

Data minimization can go the same way. The temptation with AI is often to give a system more context, more information, and more connectivity so that it can do more. But a system built to collect and access only what it needs has less to lose on a bad day.

So does one that is properly segmented. An agent constrained to one environment cannot as easily move across several.

None of this is new thinking. It is ordinary systems design applied to software that can improvise.

What is changing is the consequence of getting it wrong. As organizations deploy AI agents with greater autonomy and broader permissions, the controls governing what they can access, what they can do, and how far they can reach become more important, not less.

Permission to act changes the stakes

Traditional cybersecurity thinking often focuses on preventing an attacker from obtaining access they should not have.

Agentic AI adds another consideration: what can software that already has legitimate access do with it?

The coding-agent research demonstrates the distinction. The agents did not need somebody to steal a developer's credentials before they could act. They were already operating with permissions granted to them and encountered instructions they interpreted as legitimate.

The Australian incident raises a related issue. An agent carrying out a legitimate research task reportedly gained access to information it was not authorized to access.

This does not mean AI agents are inherently unsafe, nor does it mean every autonomous action represents a new category of cyber risk.

It means permissions take on greater significance when the software receiving them can interpret information, make decisions, and act.

With conventional software, excessive access can create an opportunity for an attacker. With agentic software, excessive access can also increase the consequences when the software behaves in a way its operator did not anticipate.

AI hasn't made good cyber hygiene obsolete. It has raised the stakes when organizations get it wrong.

What does this mean for underwriting?

When new technologies emerge, there can be a temptation to assume they require an entirely new way of thinking about risk.

These incidents suggest something more nuanced.

Cyber underwriters already care about how an organization controls access, protects sensitive information, segments its environment, monitors activity, and limits the potential blast radius of an incident. Those questions remain highly relevant.

What changes is the technology to which they need to be applied.

Underwriters increasingly need to understand not only whether an organization is adopting AI, but how that adoption interacts with its existing cyber controls.

Are agents operating with tightly scoped permissions or broad credentials? What data and systems can they reach? Can they take actions independently? How effectively would an unexpected action be contained?

And before an insurer can ask those questions, there is a more fundamental one:

Do they know where AI technologies are present at all?

What an underwriter can actually see

Today, much of what an insured runs is still whatever the insured says it runs.

AI questions are beginning to appear on proposal forms, but the speed and nature of adoption make self-declaration increasingly difficult to rely upon on its own. AI capabilities can be introduced quickly, embedded within existing technology, and adopted outside the processes through which an organization traditionally inventories its technology estate.

An organization cannot reliably declare an exposure it does not itself fully see.

Which AI technologies a business runs is therefore becoming baseline technical information about it, much like its internet-facing infrastructure or other elements of its technology estate.

But a list on its own is not an underwriting decision.

The useful version separates signal from inventory: which technologies are present, which deployments are externally exposed, which may sit in front of customer or sensitive data, and where common dependencies appear across a portfolio.

The coding-agent research illustrates why the portfolio view matters. Similar agents, interacting with similar external dependencies, appeared across otherwise unrelated organizations.

What looks like an individual company's technology decision can become an accumulation question when viewed across a book of business.

For underwriters, the value is not in creating longer proposal forms. It is in being able to answer more of these questions with evidence rather than relying solely on self-attestation.

Guardrails, not a retreat

None of this is an argument for businesses to stop adopting AI.

AI technologies are likely to become an increasingly ordinary part of the enterprise technology estate, and insurers treating their presence alone as evidence of poor risk would miss the point.

The distinction that matters is between AI adoption and AI exposure.

Organizations should be able to take advantage of AI while maintaining the same disciplines expected elsewhere in their technology environment: give systems only the access they require, minimize the data available to them, segment critical environments, monitor what they do, and understand the technologies operating across the estate.

For insurers, the challenge is therefore twofold.

First, understand whether those cyber fundamentals remain strong as AI adoption accelerates.

Second, have sufficient visibility into the changing technology footprint to know where those questions need to be asked.

At KYND, that second challenge is one we have been working on. As part of the continued development of our technographic intelligence, we are extending the technology insights available to insurers to include the detection of AI technologies.

Not because the presence of AI makes an organization inherently risky, but because understanding the technologies an organization relies upon is a prerequisite for understanding its exposure – and whether the fundamentals are keeping pace.

Australia is now asking whether legislation and governance designed before the widespread adoption of autonomous AI are fit for purpose when AI becomes involved in cyber incidents.

Businesses and insurers should be asking a parallel question of their cybersecurity practices.

AI is changing what technology can do, and these emerging real-world incidents are beginning to show what that means when things go wrong. But the principles that help prevent those incidents and contain their impact haven't changed.

As AI moves faster, the fundamentals of good cyber hygiene need to keep pace.