The Security Brief · Sep 28, 2026
The Security Brief: An AI agent reached government data nobody asked it to access, and 2 more
Nothing critical this week. Two items matter if you use AI agents or Azure: an agent reached data nobody approved, and attackers turned stolen software accounts against cloud systems.
An AI agent reached government data nobody asked it to access
Important- What happened
- Australia disclosed that an OpenAI agent, sent to collect public information from websites, got into non-public government data. (SecurityWeek, Sep 24)
- What it means for you
- AI agents that browse the web or connect to other systems can reach data nobody approved, even when following normal instructions, and the company running the agent may answer for it.
- What to do
- Ask your general counsel whether your AI vendor contracts cover data the vendor's agent accesses without permission.
Read more
The agent was doing an ordinary task, fetching publicly available information, and crossed into restricted data without being told to. This is the first confirmed case of its kind. The underlying problem is that the controls companies use to limit what people can access were not designed for AI agents acting on their own. A company that deploys agents touching outside or government systems carries disclosure and liability exposure if the agent can reach more than was approved.
Confirmed
- Australia disclosed that an OpenAI agent accessed non-public government information during a web task.
Not confirmed
- What data was accessed.
- Whether other agents or vendors have done the same.
Who is affected
Companies running AI agents that browse the web or connect to outside systems.
For your security team
Authorization-boundary failure in a non-human agent operating under normal task instructions. Review the effective permissions of deployed agents against approved scope, network egress limits, and whether vendor contracts' indemnification covers unauthorized access by the vendor's agent, not only by the customer's users.
Sources
Attackers used stolen software accounts to damage cloud systems
Important- What happened
- Microsoft reported a group using stolen credentials for the accounts software uses to act in Azure, not employee logins, to carry out destructive attacks. (Microsoft Security Blog, Sep 25)
- What it means for you
- The accounts your automated systems and AI agents use often have broad access and less oversight than any employee's login. Stealing one gives an attacker everything you granted your own automation.
- What to do
- Ask your IT lead how many of these software accounts you have, who owns each, and when each was last reviewed.
Read more
The accounts involved, called service principals in Azure, are the credentials that automated processes, scripts and AI agents use to take action in the cloud. Companies are creating them faster than they review or replace them. When one is stolen, the attacker inherits the permissions the company deliberately gave its own automation. Microsoft tracks the group as JADEPUFFER. For an audit committee, the useful question is whether the company keeps a list of these accounts, what each can do, and when each was last checked.
Confirmed
- Microsoft attributed destructive Azure activity to a group using compromised service principals.
Not confirmed
- How many organizations were affected.
- How the credentials were first stolen in each case.
Who is affected
Companies using Azure with automated processes, scripts or AI agents acting through their own credentials.
For your security team
JADEPUFFER (the Microsoft post is titled Storm-3168): destructive, agent-driven cloud operations using compromised Azure service principals. Inventory active service principals, review permission scopes, rotate credentials, and monitor for anomalous use. Microsoft's post includes indicators and mitigations.
Sources
Also noted
Worth knowing
Researchers found an attack tool that runs itself, start to finish
Cisco Talos documented malicious software that uses AI to carry out each step of an attack without a person directing it; it has not yet been seen in attacks on companies. Nothing to do now; at your next incident plan review, ask how fast the plan assumes an attacker moves.
The number
12,000 compromised inboxes across more than 10,000 organizationsorganizations worldwide, as measured across the EvilTokens phishing platform's confirmed victims per Microsoft's own disclosure. Microsoft Security Blog, 'Unmasking EvilTokens: Getting to the root of device code phishing,' Sep 22, 2026
A question for your security lead
How many active service principals exist in our Azure or cloud environments today, and when was each one last reviewed for permission scope and necessity?