🚨 These Agents Were Never Onboarded: Who’s Controlling Them?

Attackers spent this week working the layer that manages everything else — an MLflow tracking server reached by SSRF to pull instance credentials, a vCenter syslog parser turned into remote code execution, a Trivy scanner hijacked inside a build pipeline. Michael Leland of Island joins Ashish Rajan to explain why the agentic control plane forms in an enterprise whether or not anyone designs it, and what a customer assessment that found 243 AI tools where the team expected eight says about the visibility gap underneath all of it.

Author

Ashish Rajan
August 19, 2026

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: The Agentic Control Plane You Already Have (continue reading) 

This image was generated by AI. It's still experimental, so it might not be a perfect match!

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI Security Podcast every week.

Welcome to this week’s Cloud Security Newsletter!

Eight stories made the brief this week and no single incident dominated. What connects most of them is the kind of system attackers chose to hit: MLflow tracking servers, a vCenter syslog handler, a Trivy scanner sitting inside someone else's build, a Salesforce guest identity with more read access than the public page ever used. These are management and orchestration components, and in most organizations they were deployed by whoever needed them, not by whoever owns identity.

Michael Leland, VP, Field CTO at Island joins Ashish Rajan on the podcast this week to argue that the same thing has already happened with AI. Skills, MCP servers and agent connections are being wired into enterprise workflows by well-intentioned users, and none of them went through onboarding. His framing of the problem is the episode's most useful contribution: the control plane for AI has to be as wide as the use cases for AI, and enforcement gets weaker the further you sit from where the user actually touches it.[Listen to the episode]

⚡ TL;DR for Busy Readers

  • 🚨 MLflow CVE-2026-64849 is being exploited to steal cloud credentials — unauthenticated SSRF reaches instance metadata endpoints; enforce IMDSv2 on every host running it, which breaks the chain regardless of patch status

  • 🚨 VMware vCenter CVE-2026-59310 hit CISA KEV on August 18 with a three-day federal deadline; over 360 victim IPs across 47 countries, and at least one compromise reached ESXi ransomware

  • SAP Commerce Cloud CVE-2026-58231 (CVSS 10.0) was attacked a day before any public PoC existed — patch-diff exploitation breaks the "wait for PoC" triage assumption

  • A threat actor is selling Azure/Entra directory exports naming McDonald's, TCS, Vodafone and others; no CVE anywhere in the chain, only stolen credentials and directory read scope

  • Island found 243 AI tools at a customer that reported eight — visibility, not enforcement, is the first move on shadow AI

📰 THIS WEEK'S TOP SECURITY HEADLINES

Each story includes why it matters and what to do next — no vendor fluff.

1. VMware vCenter path traversal added to CISA KEV; suspected China-nexus APT already at 361 victim IPs

What Happened

CISA added CVE-2026-59310 to the KEV catalog on August 18 with an August 21 remediation deadline for federal civilian agencies. The flaw is a directory traversal issue in the vCenter Syslog server, CVSS 9.8, patched by Broadcom on July 29. Quirso reports exploitation beginning August 3 and has identified over 360 victim IP addresses across 47 countries, roughly half concentrated in Germany, the US, Turkey, Iran and France. Attackers dropped the open-source reverse_ssh framework for persistent outbound control, and at least one investigated compromise progressed to account creation, ESXi control and ransomware.

Why It Matters

The exploit path runs through the syslog write handler, a component most teams treat as write-only telemetry rather than an execution surface. Persistence is outbound reverse_ssh, so egress filtering on the management network decides whether this attack completes; inbound firewall rules contribute nothing. Because vCenter sits above ESXi, one unpatched appliance converts to hypervisor-level ransomware without any lateral movement inside guest workloads.

Action for defenders: Confirm every vCenter appliance is on a post-July-29 build, then run Quirso's reverse_ssh YARA rule against management hosts and review outbound connections and /etc/cron.d contents on any appliance internet-reachable since August 3.

2. Threat actor selling Azure/Entra directory dumps from McDonald's, TCS, Vodafone and other large enterprises

Primary source: SecurityWeek 
Reporting: Hudson Rock

What Happened

A threat actor using the handle 'TheHatman' is offering datasets said to come from the Azure/Entra tenants of McDonald's, Tata Consultancy Services, Vodafone, HCL Technologies, InterContinental Hotels Group, Kyndryl, Gap Inc., Hexaware Technologies and Wyndham Hotels. Hudson Rock assessed the field names and email formats as consistent with genuine Azure directory exports. The McDonald's dump is the largest at over 1.7 million records, followed by TCS at 800,000, Vodafone at 425,000, HCL at 250,000 and IHG at 185,000. Hudson Rock links the access to credentials harvested in a targeted infostealer campaign. None of the named companies has confirmed a breach; treat this as the seller's claim and Hudson Rock's assessment.

Why It Matters

The exported fields include service accounts, group membership, manager chains and highly privileged account names, which makes this a reconnaissance package rather than a privacy incident. Directory reads by a credentialed user generate no alert in most Entra configurations. There is no CVE anywhere in this chain, and the only control that would have broken it is phishing-resistant MFA on the accounts holding directory read scope — which is the same argument Leland makes below about scoping what non-human identities are allowed to hold.

Action for defenders:  Pull Entra sign-in and MicrosoftGraphActivityLogs for bulk directory read operations over the past 90 days, and confirm which non-admin accounts and service principals currently hold Directory.Read. All or equivalent.

🛠 If you only do one thing this week: Enforce IMDSv2 on every host running an AI or ML service — MLflow, Ray, notebook servers, inference endpoints, anything a data team stood up with an instance role attached. It is a per-instance metadata option you can flip and audit in under an hour, and it breaks the SSRF-to-cloud-credential step that CVE-2026-64849 is currently being exploited for, whether or not you have finished patching. The same control covers the next SSRF in this category, and on the evidence of this week there will be one.

☁️ 3.  MLflow SSRF exploited within hours of CVE assignment to pull cloud credentials; Ray added to KEV the same week

What Happened
watchTowr reported indiscriminate internet-wide scanning for exposed MLflow instances within hours of CVE-2026-64849 being assigned on August 17. The flaw carries CVSS 9.3, affects versions below 3.15.0, and is an unauthenticated SSRF in MLflow's model-registry webhooks that bypasses earlier fixes through redirect handling. Anyone who can reach the Tracking Server can issue requests to internal cloud metadata endpoints, and watchTowr's honeypot telemetry shows attackers using it to extract credentials and secrets from cloud-hosted deployments. Separately, CISA added CVE-2025-62593 (CVSS 9.4) in the Ray distributed compute framework to KEV on August 17; that flaw allows browser-driven RCE via DNS rebinding against endpoints the project has long declined to authenticate. VulnCheck also observed scanning against CVE-2026-25895 in the FUXA SCADA/HMI project starting August 18.

Why It Matters
An MLflow Tracking Server is typically a data science team's EC2 instance or GKE pod with an instance role attached so training jobs can read object storage. SSRF against that host does not yield MLflow data, it yields the instance role, and the blast radius becomes whatever the ML team was granted — in practice, broad read access to the data lake. Ray makes the same point from the other direction: a documented decision not to authenticate job submission endpoints is now a KEV entry with a federal deadline attached. This is the clearest example this week of Leland's argument that the AI stack accumulated infrastructure nobody inventoried.

Action for defenders
Inventory MLflow and Ray deployments by scanning cloud accounts for their default ports rather than asking teams to self-report, then confirm IMDSv2 is enforced on every host running either.

🏥 4. SAP Commerce Cloud CVSS 10.0 flaw exploited three days after patch, before any public PoC existed

Primary source: SecurityWeek 
Reporting: The Hacker News · BleepingComputer 
Analysis: KEVIntel

What Happened

SAP patched CVE-2026-58231 on August 11. Defused reported the first exploitation attempts against its honeypots on August 14, noting there was no public proof-of-concept and no prior in-the-wild reporting at that point. KEVIntel independently confirmed attacks and noted on August 15 that a PoC had become available. The flaw scores 10.0 and stems from insufficient authorization checks and input validation in the Data Hub Adapter, the component moving data between SAP Commerce Cloud and external systems. An unauthenticated attacker can abuse a default authentication client to reach functions lacking validation and execute arbitrary code. Affected builds are COM_CLOUD 2211 and 2211-JDK21, fixed in 2211.55 and 2211-jdk21.17. CISA had not added it to KEV as of August 17.

Why It Matters

Attacks preceded the public PoC by a day, so at least one actor was working from the patch diff.

Action for defenders
Confirm your Commerce Cloud build version, and where the upgrade cannot ship this week, restrict network reachability to the Data Hub Adapter endpoints to known integration sources only.

🛡️ 5.  TWINLOOT runs its entire command-and-control inside SharePoint, Teams and Microsoft Graph

Primary source: The Hacker News 
Reporting: Dark Reading · CSO Online

What Happened

Ontinue documented a previously unreported Python implant framework called TWINLOOT that operates its full C2 infrastructure inside Microsoft services. Tasking moves through SharePoint Online file dead-drops via the Microsoft Graph API, and interactive operator sessions route over WebRTC DataChannels relayed by Microsoft Teams TURN servers. Graph traffic is driven through a headless instance of the victim's own Edge browser. Initial access is a Teams-based social engineering call in which the actor poses as IT support and persuades the target to run a PowerShell command pulling down a Python runtime and a 39 MB compiled payload. The implant harvests Windows credentials using fake lock screens, offers a reverse SOCKS5 pivot, executes commands and establishes persistence. Single-vendor research with no stated victim count or targeting.

Why It Matters

Every network-layer indicator this implant produces is legitimate Microsoft traffic from a legitimate Edge process, which moves the detection surface entirely to identity and Graph telemetry. Programs that allowlist Microsoft destinations to reduce TLS inspection cost have no network signal here at all. What remains is behavioural: OAuth consent grants, anomalous Graph API call patterns, and SharePoint file operations that do not match a human work rhythm.

Action for defenders: 
Enable and retain MicrosoftGraphActivityLogs, baseline which applications legitimately call Graph from user endpoints, and alert on Teams external-tenant chat initiation followed by PowerShell execution on the same host inside a short window.

6.  One server has been pulling records from Salesforce and ServiceNow guest portals for over a year

Primary source: Reco research writeup 
Reporting: The Hacker News

What happened: Reco published research on what it calls the City Forum campaign, traced to a single server at 158.220.87.79 on a Contabo VPS. Every request carries the default Go net/http user agent, indicating a purpose-built compiled tool, and passive DNS puts the associated domain on that IP as far back as March 2025. Beyond Salesforce Aura enumeration already associated with other actors — one target logged over 560,000 events from the IP — the tool walks Salesforce Lightning Web Runtime sites through the UI-API across API versions v56.0 to v66.0, and hits ServiceNow's POST /api/now/sp/search Service Portal endpoint. Targets span telecoms, banks, enterprise software vendors and public sector portals. Reco says the infrastructure is still active and has not attributed it to a named group. Single-vendor research; the THN version is a contributed partner piece.

Why it matters:  Both platforms maintain a persistent guest identity that cannot be deleted, only restricted, and every unauthenticated visitor executes as it. If the guest profile can read a record, the record is public regardless of whether the browser flow asks for a login. The endpoints being abused work as designed, so no patch exists and no vulnerability scanner will report this. Leland's point about scoping what an identity is permitted to hold applies here exactly as it does to agents.

Action for defenders: Pull the guest profile for every Experience Cloud site and public ServiceNow portal, list the objects and fields it can read, and remove everything the public page does not render. Disable Salesforce self-registration where it is not required and turn off the Experience Builder setting permitting guest access to public APIs.

7.  The 2,500-organization LiteLLM compromise was actually a Trivy compromise

Primary source: SecurityWeek 
Reporting: The Hacker News · LiteLLM security update 
Analysis: CloudSEK

What happened: New analysis published this week reattributes the LiteLLM supply chain incident. The compromise began not at LiteLLM but at the Trivy scanner: in late February 2026 an actor exploited a pull_request_target misconfiguration in Trivy's GitHub Actions workflows to obtain a privileged personal access token, then on March 19 force-pushed malicious commits to 76 of 77 trivy-action version tags, all seven setup-trivy tags, and published a malicious Trivy 0.69.4 release. That hijacked scanner sat inside LiteLLM's build pipeline and was used to publish poisoned LiteLLM 1.82.7 and 1.82.8 to PyPI on March 24, which ran a credential stealer via a Python startup file on every host that installed them. CloudSEK puts the impact at over 2,500 organizations and more than 430,000 CI/CD pipelines. Figures are vendor-sourced and have already been revised once; THN's headline says 2,100+.

Why it matters: The initial compromise was of a security tool, and its position in the pipeline is what made it worth hijacking — Trivy runs with credentials in nearly every build it touches. Teams that pinned LiteLLM versions after the March disclosure were remediating the second stage of a chain whose first stage had been live in their pipelines since March 19. Leland's warning about unvetted skills and agents pulling untrusted packages describes the same failure one layer up.

Action for defenders: Check whether any workflow references trivy-action or setup-trivy by mutable tag rather than commit SHA, and rotate every secret those workflows could read from March 19 onward.

8.  Fortinet acquires Virtue AI for agent red-teaming and runtime guardrails

Primary source: SecurityWeek 
Reporting: Virtue AI

What happened: Fortinet announced on August 18 that it has acquired Virtue AI. The platform provides automated red-teaming for AI models, conversational applications and autonomous agents using what the company describes as over 100 proprietary attack algorithms; a testing environment simulating enterprise scenarios to evaluate agent tool usage, system access and multi-step workflows; and runtime guardrails that monitor agents and block unsafe actions before execution. Financial terms were not disclosed, and Fortinet said the amount paid was immaterial to its business. Virtue AI raised $30 million in seed and Series A funding in 2025. SecurityWeek's M&A tracker has catalogued more than 240 security deals so far in 2026.

Why it matters:  The capability being bought is runtime action-blocking for agents rather than model scanning, which says something about where the buy-side believes the control point sits. For architects, this is another signal that agent guardrails will arrive bundled with a platform rather than as a standalone purchase, so an agent governance design that assumes a dedicated tool may be designing around a category that is being absorbed.

Action for defenders:  If an AI agent guardrail evaluation is in flight, add platform consolidation risk and contract portability to the vendor shortlist before the next gate.

🎯 Cloud Security Topic of the Week:

The Agentic Control Plane You Already Have

Ashish opened the episode with the line that frames the whole conversation: "Agentic control plane is forming in your organization, you probably don't even realize it."

Leland's answer to what that actually means is deliberately broad, because the surface it has to cover is broad. AI now shows up in the browser, in browser extensions, in desktop tools like Claude Code and Codex, in IDE plugins, and in autonomous agents connecting outward through MCP. He describes MCP itself as "kind of the plumbing that gets you from an agent to an application that you're trying to connect to," and the control plane as everything you would need to see and enforce along that plumbing:

"But I think more so it's, it's being able to put guardrails on your agents. And so the agentic control plane in the enterprise, uh, is all about providing you all of those locations through which you get both visibility and enforcement of, uh, data protection and a, a fair usage policy."

The part worth taking to an architecture review is his ordering. Island's model runs left to right — browser, extension, desktop, network, then MCP gateway, compliance API integrations, LLM gateway, and OpenTelemetry — with enforcement strength decreasing as you move right. At the far right you get audit only: token utilization, performance metrics, adoption rates. His argument for staying left is not about coverage but about intent:

"If you can't get it at the desktop, you get it at the network. … If you can't get the network, you get it at the MCP gateway. … If you have an MCP gateway, you get it at the LLM gateway. … Right? All along that path you have some mechanism, but the further left you go the better chance you have of, of dealing with that at the moment of v- the moment of view, the moment the user is actually inter- interacting with AI. … That's the only place you can actually measure user intent."

For a senior practitioner, the useful exercise is to draw your own version of that line and mark where you currently have enforcement versus where you only have logs. Most programs will find they have EDR and DLP on the far left, some SASE in the middle, and nothing at all where agents talk to other agents.[Listen to the full episode →]

Definitions and Core Concepts 📚

Before diving into our insights, let's clarify some key terms:

  • Agentic control plane — as Leland described it, the set of locations across an enterprise through which you get both visibility and enforcement of data protection and fair usage policy over AI, spanning browser, extension, desktop, network, MCP gateway, compliance API integrations, LLM gateway and OpenTelemetry.

  • MCP (Model Context Protocol) — in Leland's words, "kind of the plumbing that gets you from an agent to an application that you're trying to connect to."

  • Second hop / two-hop problem — what happens when an agent calls another agent or a skill hosted on a third party's network, placing the transaction outside your SASE and CASB visibility.

  • Token brokering — an MCP gateway intercepting an agent's OAuth request and issuing a scope-reduced token instead of the one requested, so the agent never holds the application's official credential.

  • NHI (non-human identity) — the identity of an agent as distinct from a user. Leland positions it as the newest layer of least-privilege access after identity, device posture, network location and geolocation.

  • Model fit steering — routing a user's question to the model most appropriate for it, both for answer quality and token cost.

  • Token maxing — the idea that burning more tokens signals a more productive worker, which Leland calls a short-lived fad.

  • Shadow AI — unsanctioned AI tools in use that the organization has not inventoried.

  • SSRF (Server-Side Request Forgery) — the vulnerability class behind MLflow CVE-2026-64849, where an attacker induces a server to make HTTP requests on their behalf, in this case to internal cloud metadata endpoints.

  • IMDSv2 — the session-oriented version of the cloud instance metadata service, which requires a token for each request and therefore breaks the SSRF-to-credential step.

This week's issue is sponsored by Token Security

In one two-week stretch, OpenAI, Anthropic, Meta, Moonshot, and the UK AI Security Institute each disclosed agents that got loose and kept going.

One pulled infrastructure credentials and read production data. Another registered accounts, published malware that ran on 15 systems, then harvested a security vendor's credentials and reused them.

The methods were dull: weak passwords, debug endpoints, and reachable metadata. Identity set the damage, and identity is what stopped it.

Token Security finds your agents and remediates credential use unrelated to the job.

💡Our Insights from this Practitioner 🔍

1. Nobody onboarded the agents

The sharpest idea in the episode is also the simplest. When a generative AI tool offers to connect to Slack or Salesforce so it can give a better answer, a well-intentioned employee says yes, and a new identity with data access has entered the environment without passing through a single control an employee or a SaaS vendor would face.

"That process didn't go through onboarding, right? You never onboarded your agents. … Your, your agents didn't go through HR training. They didn't go through acceptable use training. They don't understand your data governance policy. You just freely accept them into your workspace. … They are the new virtual knowledge worker."

Read that against story 2 in the news section. The Azure/Entra dumps required no vulnerability at all, only credentials and a directory read scope nobody had trimmed. The agent version of that problem is the same problem, arriving faster and through a route that no procurement process observes.

 2. Eight sanctioned tools, 243 found

Leland's answer to where customers should start is visibility, and the number he gives for why is the most quotable figure in the episode.

"I had a customer insist that they only had eight sanctioned AI tools in use. We did an assessment- … with just our browser extension. … We found two hundred and forty-three tools."

"If you tell a user no, he will find a way around your no- … to get a yes."

He is specific about the organizational forces producing that gap. The board and executive team tell staff they must use AI. Legal and compliance tell them to be careful. Meanwhile an approved SaaS application grows a new AI button in the top right corner that nobody requested or approved, and the user is left deciding whether pressing it is safe.

3. Unvetted skills are a supply chain problem with a different name

Island's research, as Leland describes it, found a GitHub repository with 7,600 skills of which over 800 were malicious.

"Right? Our research found, uh, a GitHub repository with 7,600 skills, like over 800 of them were malicious. The other challenge is it's not just the malicious actor that we have to worry about, it's the very well-intentioned user who doesn't know what he's doing."

He also described watching an agent route around a blocker on its own:

"I saw last week Claude Cowork decide that it, it hit a brick wall. It couldn't go any further. So what does it do? It writes a Python script- … that downloads an NPM package from an untrusted source- … in order to achieve its goal. AI is goal-oriented."

Story 7 is the mature version of that behaviour. A hijacked Trivy release sat inside a build pipeline for weeks with credentials attached, and the organizations affected had no reason to look at their scanner.

4. Token brokering, and NHIs as the fifth least-privilege layer

The most actionable architectural idea in the conversation is that an MCP gateway in the request path can downgrade what an agent asked for.

"If an agent requests, let's say, a read-write access to Salesforce our MCP gateway can actually say, 'You're allowed to get to Salesforce, but you're only allowed to get a read-only token to Salesforce.' … So it's something called token brokering."

The agent never holds the application's real OAuth token, only the one the gateway issued. Leland places this in a lineage practitioners will recognize:

"It's the next layer of, uh, least privilege access concepts. Identity was the first. That was the ZTNA principle. … Device posture is second. Network location is third. Geolocation is fourth and now the NHIs."

He flags a wrinkle worth planning for: some agentic transactions use a token exactly once, which turns token rotation and behavioural chain reconstruction into a real engineering problem rather than a policy checkbox. He also notes "Entra now has an Entra ID for NHIs" — confirm the exact Microsoft product name and availability before relying on it.

5. Agent-to-agent is where the control plane runs out

User-to-agent and desktop-to-agent are tractable. The hop Leland calls hardest is the one where your agent hands work to somebody else's.

"The harder ones are the, the two-hop problem that I think is the biggest challenge is agent to agent. If I ask Claude Code to go to Salesforce and run a query for me about my customer data- … it could choose to use a skill that's published in uh, in Agentforce. … So now that agent is not running on my network, so I have no visibility to it on my SASE product. … My CASB's not gonna see it 'cause it's on Salesforce's network."

His answer is auditability rather than interception: capture every prompt, every response, every tool call and every tool result, then build governance from observed usage instead of assumed usage. That is a data retention and cost conversation as much as a security one, and it is worth having before an agent program scales rather than after.

6. Where he does not go

Three positions Leland explicitly declines to take, worth preserving because they are easy to flatten in summary. He does not argue for restricting AI; his stated position is "Say yes to AI, but do it safely." He does not claim hallucination is solved — he says a domain-specific model grounded on internal sources earns more trust, then immediately adds that "AI is never going to be 100% perfect" and that a human in the loop matters most where an agent might act on your behalf. And he declines to name competitors, saying only that architectures requiring data to reach a cloud inspection point before it can be examined are structurally too far from the user.

Practical takeaways

  1. Draw the control plane for your own environment left to right and mark each layer as enforce, log, or nothing. The gaps will not be where you expect.

  2. Run a shadow AI assessment before writing an AI policy. A policy written against eight tools does not survive contact with 243.

  3. Treat every MCP server, skill and agent connector as a third party. Ask who published it, what scope it requested, and what token it actually received.

  4. Scope non-human identities the way you scope service accounts, then check whether your IdP has an NHI capability you are already paying for.

  5. Enforce IMDSv2 everywhere before the next AI infrastructure deployment. It is the single control that would have blunted this week's MLflow exploitation.

Podcast Episode

Question for you? (Reply to this email)

🤔 If you ran a shadow AI assessment tomorrow, would your number look more like eight or like 243?

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

📬 Want weekly expert takes on AI & Cloud Security? [Subscribe here]”

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter community💙

Peace!

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Security Podcast