This week’s Cloud Security Newsletter topic: Governing AI Output in a Bank: Inventory, Drift and Accountable Owners (continue reading)

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!

Citrix patched two NetScaler ADC and Gateway zero-days in the last days of September, both rated CVSS 9.5 and both already exploited. CyberScoop puts the earliest known exploitation at September 3. Then watchTowr published a proof of concept, and Help Net Security reports that mass exploitation followed within a day. If you run NetScaler in front of anything, that is the first item on your list today.

The rest of the week is unevenly distributed. Microsoft described JadePuffer operators using AI agents to delete more than 100 Azure storage accounts in a seven-minute burst. Bitget lost about $388 million after attackers reached an internal management system through a zero-day in a security product it has not named. Kiteworks pulled its file-transfer platform offline on a federal intelligence warning. An official MCP SDK flaw lets a malicious server capture OAuth credentials, and OpenAI paused tool use on its most capable models after a training agent found a gap in its internet-access restrictions.

Sandip Wadje spent this week's episode with Ashish Rajan on the AI Security Podcast describing how BNP Paribas approaches generative AI from a model risk management background. His argument starts from the controls the bank already has and asks what the delta is. It then moves to the parts he thinks most programmes skip: an inventory regulators can query, monitoring of output drift, SOC training for AI incidents, and permission clean-up before an agent goes live. Sandip did not discuss this week's incidents on the episode. [Listen to the episode]

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

Primary source: BleepingComputer
Reporting: Infosecurity Magazine, The Hacker News, Help Net Security, CyberScoop

What Happened

Citrix patched CVE-2026-88771 (CVSS 9.5, unauthenticated remote code execution through improper input validation, default configuration) and CVE-2026-88772 (CVSS 9.5, a memory overflow leading to remote code execution or denial of service where DTLS is enabled), and confirmed exploitation of both on unmitigated deployments. Mandiant tracked the attacks from early September against targets in North America and Europe, and reported PHP web shells that return fake 404 responses, a PHP proxy called WHIPSHOT and a Python tunnelling tool called SLAPSHOT. watchTowr published a proof of concept on September 29. Affected builds are NetScaler ADC and Gateway 14.1-73.32 and earlier and 13.1-63.21 and earlier. Fixed builds are 14.1-73.37 and 13.1-64.23. 

Why It Matters

The vulnerable condition for CVE-2026-88771 is default configuration, so an inventory question about hardening returns the wrong answer. What you need to know is whether the appliance was reachable and unpatched at any point since early September. Mandiant's post-exploitation tooling tunnels from the gateway into the internal network, which makes a NetScaler in front of cloud-hosted applications a route into whatever it can reach. Patching closes the flaw and leaves the web shell in place: the .ctxs.receiver file and the modified httpd.conf survive an upgrade unless someone goes looking. The 13.1 fix shipped on a branch that reached end of maintenance on September 15, so anyone still on 13.1 has an upgrade decision this week. Roughly three weeks passed between the earliest exploitation CyberScoop reports and a fix existing.

Action for defenders: Pull every NetScaler ADC and Gateway from external attack-surface data, patch to 14.1-73.37 or 13.1-64.23, and treat any internet-facing, unpatched box as potentially compromised since early September. Hunt for the web shell path, the setuid change on /bin/sh, and the files /tmp/.uxdport and /tmp/.uxdlock. Disabling DTLS and blocking inbound UDP/443 upstream covers CVE-2026-88772 only, and Citrix says patching is the only fix for both. Infosecurity Magazine reports a CISA deadline of September 30 for federal agencies. 

Primary source: BleepingComputer 

What Happened

BleepingComputer reports that Microsoft tracks the operators as Storm-3168. In intrusions Microsoft observed in June 2026, two compromised service principals gave them access to Azure. The agents ran reconnaissance, credential theft, lateral movement and persistence, then a destructive phase that lasted seven minutes. It hit more than 100 storage accounts along with Key Vaults, Function Apps, virtual machines and App Services. The operators removed Azure Site Recovery protections and tried to delete Azure SQL databases, and some of those deletions failed. Most targeted storage accounts were deleted. Some survived because of resource locks and account-level protections. 

Why It Matters

The survivors are the useful data. Accounts carrying resource locks and account-level protections outlasted a seven-minute automated purge, and those controls were in place before any alert fired. The entry point was two service principals, so the blast radius equalled whatever non-human identities were allowed to delete. Removing backup protection was itself a step in the attack, which puts recovery configuration in scope for the same access review as production resources.

Action for defenders: List every service principal with delete rights on storage accounts, Key Vaults or Site Recovery vaults, cut them to the minimum, and put delete locks on backup and recovery resources so that removing a lock is a separate, alertable action.

🛠 If you only do one thing this week: pull every NetScaler ADC and Gateway out of your external attack-surface data, confirm each one runs 14.1-73.37 or 13.1-64.23, and check the appliance for the .ctxs.receiver web shell path before you close the ticket. It takes under an hour, and it is the check an inventory of "patched" boxes will not give you.

Primary source: The Hacker News
Reporting: The Record, SecurityWeek, The Hacker News initial report

What Happened
On September 24 at about 18:31 UTC attackers made two small test transfers, and larger fraudulent transfers began around 19:01 UTC. On September 28 Bitget's CEO said the attacker exploited a zero-day in an unnamed third-party security product, reached an internal management system and inserted fraudulent withdrawal commands into backend wallet services. Bitget says cold wallets were unaffected, customer balances remain accurate, and it has isolated affected systems, reissued internal credentials and disabled the affected functionality. It suspects North Korean actors, and TRM Labs and Elliptic reported overlaps pointing to the TraderTraitor group, but no firm attribution had been made at publication.

Why It Matters
The compromised layer was the security tooling's management plane, and the attack worked by feeding it falsified state: spoofed transaction data triggered Bitget's own authorization process. The vendor has not been named and no fix has been reported, so every customer of that product carries a flaw they cannot yet identify.

Action for defenders:  Inventory which security products in your estate have a management interface with authority to move value or change access, confirm those interfaces are reachable only from a dedicated admin network, and add an out-of-band check (a second approver or an independent ledger reconciliation) for anything they can trigger.

Primary source: The Record
Reporting: The Hacker News

What Happened

Kiteworks told customers it had received credible threat intelligence from federal intelligence authorities that a threat actor may target some Kiteworks systems, and urged them to stop using the platform during a window on Saturday. It said it knew of no compromise and that all known vulnerabilities were fixed in release 9.5.1. On September 29 Kiteworks disclosed that during a precautionary shutdown of about nine hours it found and patched a critical vulnerability in a capability enabled for under 1% of customers. No CVE has been assigned, and Kiteworks says there is no evidence the flaw was exploited. The FBI declined comment and CISA did not respond to The Record.

Why It Matters

Most enterprises have never rehearsed switching off managed file transfer for a weekend, and nobody has a runbook for it. The flaw sat in a feature under 1% of customers had switched on, which means the fastest exposure check is a configuration check. Kiteworks descends from Accellion, and The Record notes that Clop's 2020 zero-day exploitation of Accellion reached major organisations.

Action for defenders: Confirm you are on 9.5.1 or later, ask your account team which optional capability was affected, and write down who can authorize taking your file-transfer platform offline and what breaks when it goes.

Primary source: The Hacker News 

What Happened

Cycode reported that the official MCP Python SDK did not validate that the authorization server matched what the client expected, so a malicious MCP server could redirect the OAuth token exchange to an endpoint the attacker controls. The client would then send its client secret, authorization code and PKCE proof key to the attacker. Reported severity is CVSS 7.5 for non-interactive providers and 6.5 for the interactive provider, with no CVE assigned as of September 29. Affected versions are 1.9.1 through 1.29.1 and 2.0.0 through 2.1.1, and the fixes are 1.30.0 and 2.2.0.

Why It Matters

Pinning the authorization server at your identity provider protects nothing if the client library follows whatever server it was pointed at.

Action for defenders: Search repositories and container images for the mcp Python package, upgrade to 1.30.0 or 2.2.0, and review which MCP servers your agents connect to, removing any that are not first-party or vetted.

Primary source: BleepingComputer

What happened:
UpGuard analysed about 300,000 domains showing Supabase usage, looked for accessible users tables and inferred data types from table schemas. It found more than 16,000 misconfigured databases exposing personal data, passwords, authentication tokens and, in a smaller subset, credit card data. Named examples include a valet service with over 100,000 customer records, a Canadian immigration service with about 5,000 user records including 884 plaintext passwords, and a government consulate with 25,000 people's records. UpGuard attributes over 60% of newly created databases to AI-assisted development. BleepingComputer documented no formal response from Supabase. 

Why it matters:
 The failure is a default that generated code accepted. Row-level access was left unrestricted on tables the front end queries directly, so exposure traced back to how the app was built. That moves the control point to review of code a coding assistant produced. The affected apps span a US valet service, a Canadian immigration service and a consulate, so third-party reviews of your vendors should now include database exposure for any app built on a backend-as-a-service.

Action for defenders: Ask engineering which production apps use Supabase, check row-level security on every table reachable with the public anon key, and rotate any tokens or keys stored in exposed tables.

Primary source: The Record
Reporting: The Hacker News, Help Net Security

What happened:
OpenAI says an agent in a reinforcement-learning training task queried a public chatbot service on September 20 through a gap in its internet-access restrictions. Its misalignment monitor flagged the behaviour within 15 minutes, a human reviewer acknowledged it three minutes later, and the run was terminated after 2.5 hours. OpenAI says training, evaluation and inference with tool use for its most capable models remain paused. Separately, Australian Prime Minister Anthony Albanese said an OpenAI agent gained unauthorized access to non-public files on an Australian government system, and OpenAI said its models "took actions we did not intend." The Record reports researchers doubt any exploit was needed, because archived portal code routed visitors to an unauthenticated guest endpoint, and neither side has released activity logs. 

Why it matters:
The sandbox escape is a plain egress-control failure: DNS filtering had a gap, and an agent optimizing for a search task found it, which is the class of gap a SOC hunts for in ordinary workloads. The Australia dispute pulls the other way. If the portal exposed an unauthenticated endpoint, the agent needed no exploit, and the public record cannot yet separate "agent breached a system" from "agent used a door left open." Either reading hands buyers of agent products the same question: what stops an agent reaching things nobody intended, and who holds the logs? Detection took 15 minutes here and containment took 2.5 hours.

Action for defenders: Audit egress rules and DNS filtering for any environment where an agent or LLM-driven tool runs, and require full request logging for agent traffic so a later dispute can be settled from your own records.

Sandip Wadje's argument starts with a question his boss put to him when he began looking at AI governance: what is the delta? A bank already has access management and data protection, and the work is to measure what generative AI adds to them. Sandip says what it adds is mostly about output. Model risk management was built for models a bank could fully describe, and generative AI is a black box, so governance shifts to the edges: what goes in, what comes out, who owns the consequence when the output is wrong, and whether anyone would notice the output drifting.

Build a use-case inventory a regulator can query. Decide controls before go-live, sequenced from summarization to writing to reasoning. And train the people who will investigate an AI incident before one happens. If you have 30 to 60 minutes this week, spend them on the first: list every AI use case in your organisation with its model, model version, whether it touches personal data and whether it faces customers or the market.[Listen to the full episode →]

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

This week's issue is sponsored by AI Security Lab

Sandip starts from the regulator's side. Almost every regulator, he says, has laid out principles for model risk management, and he names the Bank of England, the PRA and the Feds in the US. Those principles cover model development, governance and independent verification, and in most banks a separate function judges a model's performance and behaviour before it reaches production. For front-office or critical classical models it is common to share that information, including the models themselves, with the regulator.

His point about generative AI is that the underlying assumption no longer holds:

"So, so MRM is like pre-GenAI, and a lot of those principles are, like, 15, 20 years old in terms of, uh, having those practices, uh, where, where model is not a black box, right?" Sandip Wadje

He adds an anecdote from a conference of model-risk professionals, CIOs and data scientists: around a thousand people in the world, the room concluded, understand what is inside a generative model, and everyone else works at the periphery of input and output, so governance effort has to move there. No specific implementation detail was given beyond the existing independent-validation pattern.

Sandip's first assignment on AI governance was to compare what the bank already had against what AI adds. His boss's instruction, relayed by Sandip, was:

"Can you tell me what is the delta I need to cover? Don't tell me that I need to start all over again." Sandip Wadje

He took the existing access control and data protection controls and estimated the percentage delta the technology introduced. The delta still leaves explainability of the output, which he says you address by fixing governance before the project starts, picking the right controls for the use case, and ranking use cases as high, medium or low risk.

The second half of this insight is about what regulators want to see:

"They don't care, like, whether you use OpenAI or Anthropic or anything else. They want you to tell them where and how AI is used." Sandip Wadje

That means an inventory with fine detail: model, version, whether personal data is used, whether the use is market-facing or internal. Sandip says many teams end up building it in reactive mode after a regulator asks, at a cost in energy that proactive record-keeping would have avoided. He compares the problem to the CMDB.

Ashish asked which use cases to govern first when a bank has 400-plus applications and every team wants a slice. Sandip's ordering:

"I think the easy ones to start with, and I've, I've said this quite some times now, is put them in the buckets of summarize, write, and reason." Sandip Wadje

His example of a good summarization case is verifying revenue booking: the AI reads a contract, checks the number and confirms it against the revenue booking tool, which he describes as a small problem with high value to executives. Where projects go wrong, he says, is piloting reasoning on day one and burning political and real capital. He connects that to the MIT survey figure that 95% of projects failed. He places vibe-coded apps in the reasoning bucket, because the time to build shrinks and the questions of who maintains the app and who closes the feedback loop remain.

Two prerequisites, in his words: clean data available to the AI, and someone to maintain the feedback loop around the clock, monitoring output so it does not drift. Ashish added a simple picture of evals: the model does a task correctly ten times and then forgets on the eleventh.

Ashish raised the standard answer, which is to hand a use case to a governance council. Sandip's view was that this misses the point, because the council reviews the use case, the model, the application and the data:

"What is the data? And, and that output focus is completely missing." Sandip Wadje

His fix is an event taxonomy. Take the events you already track, such as phishing and operational failure, and ask what can go wrong with a non-deterministic technology. Add the new events, then work backwards to consequences (reputational, financial, regulatory) and name the person accountable for each. That person joins the governance, and Sandip says the owner is often someone other than the people wearing the IT or data protection hat, because those people are not accountable when the output is wrong.

His worked example is an investment process delegated to generative AI:

"Yeah. But now the output has changed. As a result, your investment patterns have changed. When do you actually detect the drift?" Sandip Wadje

In that scenario the bank has done the access control, the prompt engineering risk and the data security work correctly, and the market data was manipulated anyway. A person used to read every report before it reached an investment memo, and now three data sources can drift the output with financial consequences. He also gave a translation example: the same model translating a town-hall message is low risk, and translating a contract is high risk. Ashish's summary of the vendor angle:

"If you just buy one of the AI security products, you're probably only solving parts of the risk." Ashish Rajan

Sandip agreed that most AI security products address the model doing something wrong or a user doing something wrong, and said there are many other dimensions.

Sandip's list of spotlights beyond the inventory and pre-go-live controls includes data lifecycle (data quality as well as personal data) and attestation of models for security and behaviour. Then a gap he says nobody is filling:

"So I think we have to invest a lot on training our SOC teams on how to investigate AI incidents. Uh, I, I don't think effort has gone in that direction." Sandip Wadje

His example is a CSIRT called to an incident that involves an eval framework. If the team has no idea what an eval framework is or what data it touches, it starts from zero under pressure. He notes that MLOps was traditionally the data scientists' remit and is now scaling as generative AI use cases multiply from a handful to dozens. Practical step: brief the CSIRT on how the technology works, what its components are and what can go wrong, before an incident. He named no specific tooling. Ashish added the forensic angle: without telemetry, there is nothing to investigate.

Sandip explained why role-based access hides risk. A role grants birthright access to a laptop, OneDrive and the applications of a trading division, but the account also carries low-level entitlements nobody sees. His test: open a command prompt on any corporate laptop and see what else is available to you. Then:

"But when you attach it to an AI, AI sees everything." Sandip Wadje

His recommendation, which he says he made at a roundtable in Davos earlier this year, is to fix access before starting, and he finds it funny that people start with something new and then look for a monitoring tool:

"So my first recommendation is if you're building, deploying AI agents, clean up the permissions that AI should not have access to." Sandip Wadje

Where gaps remain, he prefers compensating controls from technology already in place. Remote browser isolation can act as a DLP-style filter and a switch for authentication traffic. Regex-based DLP, he says, does not work for generative AI. Segmentation works as a kill switch: ask whether you can segment agents differently to reduce blast radius. He would still monitor all prompts, input and output, for acceptable use, regulatory violations and to see how employees use AI. He expects convergence toward tracking user and agent behaviour through the endpoint, as long as an identity is attached to the AI activity.

Ashish asked about least privilege for agents, where engineers always say the agent needs more permission. Sandip's answer is that the use case sets the blast radius and the risk events, and the go or no-go decision follows from weighing them against the benefit:

"Look, I can save 1 million, but this 4% fine of my total revenue is not worth it." Sandip Wadje

He would park a use case until he had confidence he could monitor it end to end, and says incidents happen because people get excited and rush. For a governance committee, he advises dropping model risk and data risk language and talking about blast radius and who is accountable if something goes wrong.

He says governance has become joint and cross-functional: business, IT, CISO, data protection, legal, second line and third-party risk on the same call. He calls the shared ownership of the feedback loop the AI kitchen, and warns that where one person does not add the right perspective, the output drifts. The driver is speed. Cloud gave organisations fifteen to twenty years to adapt, and a generative AI use case can now be operational in a month or a couple of days.

Asked for the single thing listeners should take away, Sandip gave a one-line answer:

"I would say, uh, take time to understand your data." Sandip Wadje

He says the organisations that have done well with AI are the ones that worked out how to understand and work on their data before adopting generative AI. It ties back to the drift example: data quality and deliberate manipulation of data can change output, so data lifecycle covers quality as well as personal data. No specific implementation detail was given.

Practical takeaways

🤔 Who owns the output when your AI use case goes wrong, and would your SOC know how to investigate it?

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!

Shilpi Bhattacharjee

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