CISO Intelligence: The Default Is Now the Vulnerability
The most instructive story is a flaw that has already been fixed. A researcher found that a single prompt to a public-facing chatbot built on AWS Bedrock AgentCore could reach the Instance Metadata Service, pull temporary credentials, and then use the platform's own default permissions to take over every agent in the account and region. The report went to AWS in December, the defaults were changed in February, and there is nothing to patch now.
Read the sequence again, because the interesting part is not the bug. It is that the researcher could not answer the simplest question about his own attack: how many agents are actually deployed this way. There is no directory. The security-through-obscurity that protected the platform's customers from exploitation also blinds every customer from governing their own estate.
Agents are cloud principals, and they are running as root
Zenity Labs described the flaw at SecTor 2026. An agent running in a Firecracker MicroVM lacked the network isolation that would have stopped it reaching the metadata endpoint. From there the temporary credentials carried permissions across every AgentCore resource in the region, not just the one agent. The researchers could invoke other agents, read their sessions, reach secrets in Secrets Manager, and plant poisoned memories.
The 2019 Capital One breach ran the same playbook with an SSRF flaw. The difference now is that the thing being manipulated is a helpful assistant with a mandate, and the credential it holds is as broad as the platform could make it. AWS has since moved new agents to IMDSv2 and narrowed the default role. Existing agents need to be checked by hand, because nothing upgrades them for you.
This is the pattern that recurs through almost every story here. Convenience defaults and least privilege are in direct conflict, and the default wins unless somebody changes it deliberately. If you cannot enumerate your agents, you cannot apply least privilege to them, and you cannot tell whether the one you can see is the one an attacker would use.
The agentic supply chain already has victims
CrowdStrike has published details of a campaign against South Korean financial firms that used ARTEX, an open-source Chinese agentic pentesting tool, alongside Claude and a rotating set of model backends including DeepSeek and GLM. The actor built pentesting prompts, ran them at scale, and exfiltrated data. Shinhan Bank and Yegaram Savings Bank reported breaches affecting 25,000 and 40,000 people.
The tradecraft is worth noting because it is not exotic. The attacker found the target services, asked a capable model to help, and repeated the process across multiple victims in a short window. What used to require a skilled human for each intrusion now requires one competent operator and a toolchain.
The forensic consequence arrived the same day, and from an unusually practical direction. Jim Clausing at SANS has published two Python scripts for reconstructing what an AI agent actually did, one for OpenCode's SQLite session database and one for Hermes conversation records. Both pull out the conversation, the tool calls, the model usage and the logs. This is the work that will decide whether you can answer a regulator or a court about what your agent did and why. Test them now, on your own estate, before you need them under pressure.
The economics of exposed AI infrastructure
A cryptomining botnet called PoeLLM has infected more than 3,400 servers since April, most of them running vulnerable versions of LiteLLM and Ollama. Hundreds more run Gotenberg, a PDF converter, and Gitea. The malware reads its command and control address out of a poem hidden in a GitHub repository, which tells you how little sophistication this requires. The campaign is the work of a single Italian-speaking operator who appears to be in it for the money.
Three thousand, four hundred exposed AI servers is not an accident. It is what happens when teams deploy infrastructure because a project needs it, without anyone treating it as an internet-facing production service. LiteLLM had a known command injection flaw, CVE-2026-42271, and CISA warned about it. The update did not get applied. Meanwhile the servers are scanning for new victims and brute-forcing logins in the background.
The research team's conclusion is the one to put in front of your engineering leadership. As AI spreads through development and operations, the attack surface grows with it, and the security of these services cannot trail behind convenience.
OAuth is the quiet part of the same problem
An AI note-taker reads your calendar. A task tool reads Slack. A developer tool reads your repositories. Each consent is granted once and lasts indefinitely. Disabling the user in Google Workspace or Microsoft 365 suspends the grants that came from that platform, but not the third-party grants, which keep working quietly for months with no log entry at all.
In the Vercel breach, the root cause was a single compromised OAuth token from a third-party AI tool that an employee had connected to their enterprise workspace months earlier. Nudge Security's figures put the scale in perspective. The average employee creates 88 OAuth grants, of which 31 carry data-level permissions. At a thousand-person company that is 88,000 access paths, and roughly 31,000 of them reach sensitive data. Gartner expects half of SaaS breaches by 2027 to stem from overprivileged OAuth tokens.
What this means for you
1. Enumerate your AI agents and AI services. Bedrock AgentCore, LiteLLM, Ollama, Gotenberg, Gitea. If it listens on a port and holds credentials, it belongs in your attack surface register and in your patch cycle, whether or not a security team built it.
2. Check the blast radius of agent permissions. The AgentCore default allowed an agent to invoke other agents and read secrets. Find the equivalent in your environment and cut it back.
3. Treat OAuth grants as durable credentials with no owner. They outlive the user who created them, they are invisible to your identity provider, and they are the access path attackers prefer because nobody is watching them.
4. Test your agent forensics before you need them. Reconstruction tooling exists and is free. Running the exercise after an incident is too late.
The thread running through all of it is that the platforms we adopted for speed shipped with defaults that assume trust. That was a reasonable engineering decision in a lab and a poor one in a bank. The defaults have not changed on your estate just because the vendor changed theirs.
,-
Sources: 21 publications checked, 10 AI-relevant stories analysed (24-hour window).