AI agents inside Australian businesses can already read the CFO’s inbox, pull files off the company drive, and push updates into customer records. In most cases, nobody is watching what they do with that access.
Australian enterprises have, over time, integrated these agents into the same SaaS estate that runs everything else: email and files, customer records, IT workflows, and collaboration. Each connection got sold internally as a productivity win. Each one also quietly handed a non-human identity the kind of standing access that, for a human hire, would trigger a background check, a manager’s sign-off, and a formal access review. For AI agents, that step is routinely skipped.
Five security research teams, working independently across different products and attack techniques, landed on the same conclusion without ever comparing notes: the danger in enterprise AI no longer comes from what the model says. It comes from what the agent attached to that model is allowed to do next.
Give an agent always-on access to email, cloud storage, source code, CRM data or finance software, and it can cause real damage just by carrying out an instruction that’s been manipulated — no need to “trick” the model itself.
For Australian organizations that have plugged agents into more than one of these platforms, it means a single compromised agent identity can hop between systems that were never built to trust one another.
Attacks the disclosures actually showed
The findings were concrete, not theoretical. One team demonstrated a working attack that hijacked an AI coding assistant using a poisoned DNS TXT record. Researchers at Wiz disclosed a CVSS 8.5 vulnerability in Amazon Q Developer, since patched, that allowed a malicious configuration file to execute automatically and potentially expose cloud credentials.
Push Security separately demonstrated “Poisoned Tenant,” in which attackers set up fraudulent AI organizations and sent invitations from a domain that passed every standard email authentication check. Accepting the invite was enough to hand the attacker owner-level control of the account. The campaign specifically targeted cybersecurity firms, which is precisely the sector Australian enterprises rely on for assurance that their own AI deployments are safe.
Australian identity governance wasn’t built for this
The harder problem lies in identity architecture. Enterprise systems were built around a simple pattern: someone logs in, works inside a defined session, then logs out. Agents break that pattern completely. They can run unattended for hours, jump from one connected system to the next, and act as a stand-in for whoever deployed them, without ever hitting the checkpoints a human session would trigger.
Researchers at Orchid Security have a name for the resulting blind spot: “identity dark matter,” agents holding human-level permissions in a layer that identity and access management tools were never built to see into.
This lands differently in Australia than almost anywhere else because large Australian organizations already carry substantial identity governance obligations. Banks and insurers report in accordance with APRA’s CPS 234 standard. Most enterprise security teams are measured against the Essential Eight maturity model published by the Australian Cyber Security Center. Many carry ISO 27001 certification as a baseline vendor requirement.
The problem, however, is that none of these frameworks were written with autonomous software identities in mind. Also, none currently require an organization to prove it can see what an agent did at the moment it acted, rather than what it was authorized to do when someone first enabled it. In simpler terms, these frameworks have not fully kept pace with the speed of agentic AI, which isn’t all that surprising, as similar frameworks are also trying to keep pace globally.
More must-read AI coverage
- SS&C Intralinks DealCentre AI vs. Datasite: Which platform is built for the future of dealmaking?
- SS&C Intralinks FundCentre AI vs. Juniper Square: Which platform better supports modern private markets fund managers?
- Why Data, Not Models, Determines AI Success
- The Rise of the AI-Native Factory: How Physical AI Is Transforming Manufacturing
The fix is access, not intelligence
The research points to the same starting control regardless of industry: least-privilege access, applied to agents with the same rigor Australian enterprises already apply to privileged human users. In practice, most current deployments grant agents broad, developer-level access by default, with no equivalent to the access review a new privileged hire would undergo. Scoping agent permissions for the specific task, documenting the request, and periodically reviewing it closes a large share of the exposure before an attacker ever gets involved.
Audit trails carry more weight than before, too. Because agents can be manipulated through the very data and instructions they’re authorized to read, the ability to reconstruct exactly what an agent did — and why — stops being a nice-to-have and becomes the evidence an Australian board or regulator will eventually ask for.
None of this sits neatly inside IT or security anymore. As agents take on tasks involving finance, HR, and customer data, accountability for how they operate rests with the business leaders who approved the use case, not just the architects who built it. The shift underway is from asking whether an AI model is safe to asking whether the business can control what its agents are allowed to touch.
The technology isn’t really the problem here, and it never was. What’s missing is the same discipline Australian enterprises already apply to their own people — deciding who gets access to what, and being able to prove it later. Right now, most AI agents skip that step entirely. That’s a gap that can be closed. It just hasn’t been yet.