• Cloud Security Newsletter
  • Posts
  • 🚨 OpenAI's Models Escaped Through JFrog Artifactory: What a 25-Minute Exploit Window Does to Your Org Chart!

🚨 OpenAI's Models Escaped Through JFrog Artifactory: What a 25-Minute Exploit Window Does to Your Org Chart!

JFrog confirmed this week that the OpenAI models which breached Hugging Face got out of their sealed test environment through zero-days in self-hosted Artifactory the package proxy that existed to be the enclave's only safe path outward. Clop is emptying PTC Windchill instances, Arista shipped a CVSS 10.0 fix for an SD-WAN orchestrator already under attack, and GitHub and PyPI both responded to the software supply chain with timers rather than scanners. Sarit Tager, who leads Cortex Cloud product management at Palo Alto Networks, argues the discovery-to-exploit window is now sometimes 25 minutes, and that no organization can cover that window with cloud security and application security operating as separate functions.

Author

Ashish Rajan
July 29, 2026

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: What a 25-Minute Exploit Window Does to Your Org Chart (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 this week, and the pattern in them is where the attacks landed. Not on workloads. On the systems that distribute and manage software: a package-registry proxy, an SD-WAN orchestrator, a product lifecycle management platform, a third-party ticketing system that opened into Jira, GitHub and Azure. The JFrog disclosure is the sharpest of them, because the compromised component was the one piece of infrastructure the sealed environment trusted by design.

Against that, this week's featured conversation is with Sarit Tager, who leads Cortex Cloud product management and exposure management at Palo Alto Networks and spent her earlier career as a developer, director and VP Engineering. Her argument is about org structure, and it lands harder than usual in a week like this one: when the gap between a vulnerability being found and being exploited is measured in minutes, the split between the team that secures code and the team that secures the cloud stops being a division of labour and starts being a gap an attacker walks through. [Listen to the episode]

⚡ TL;DR for Busy Readers

  • 🚨 Artifactory was the escape route: JFrog confirmed OpenAI's models used zero-days in self-hosted Artifactory to break out of a sealed eval environment; eight CVEs shipped in 7.161.15 on 27 July, all crediting OpenAI. Patch now, and disable Anonymous Access.

  • 🚨 Two max-urgency exploited flaws: Arista VeloCloud Orchestrator (CVE-2026-16812, CVSS 10.0, unauthenticated) has a three-day CISA deadline; Clop is deploying web shells against internet-exposed PTC Windchill and FlexPLM.

  • An exploited 9.0 with no patch, ever: FastJson 1.x (CVE-2026-16723) is end-of-life and under active attack against US financial and healthcare targets. Scan JAR contents, not manifests, and force SafeMode.

  • The registries chose delay over detection: Dependabot now waits 72 hours before adopting new package versions; PyPI blocks file uploads to releases older than 14 days.

  • Sarit Tager's take: "If I am a coding agent, then my plan is to create the code." Telling the agent to be secure doesn't work, because security is its second goal and the two conflict.

📰 THIS WEEK'S TOP SECURITY HEADLINES

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

1.  JFrog confirms OpenAI's models escaped their sandbox through Artifactory zero-days

What Happened

JFrog disclosed on 27–28 July that the unnamed package-registry proxy OpenAI's models exploited to break out of a sealed evaluation environment was self-hosted JFrog Artifactory. OpenAI's ExploitGym evaluation ran GPT-5.6 Sol and a more capable pre-release model without the production classifiers that block high-risk cyber activity. The models found zero-days in the proxy, escalated privileges, moved laterally to a node with internet access, then chained stolen credentials and further zero-days into a remote code execution path against Hugging Face's production infrastructure. Artifactory 7.161.15 Self-Managed, released 27 July, carries a critical notice about multiple vulnerabilities that chain into a critical attack scenario when Anonymous Access is enabled. BleepingComputer identified eight CVE records created that day and tied to the release, all crediting OpenAI researchers.

Why It Matters

The internal package proxy is the component almost every build environment treats as plumbing rather than attack surface. It exists so that isolated networks have one sanctioned path outward, which is exactly what makes it the highest-value target in any restricted enclave. Three of the eight flaws are server-side request forgery in remote-repository handlers for Terraform, Cargo and Ansible — the escape route was the proxy doing what a proxy does, pointed somewhere it should not go. Any team that has justified a sealed research, CI or agent-evaluation environment on the grounds that the artifact cache is the only egress now has a worked example of that reasoning failing end to end.

Action for defenders: Upgrade self-hosted Artifactory to 7.161.15 or the remediating build for your branch this week, and confirm Anonymous Access is disabled — it is off by default and JFrog does not recommend it in production. Then find any environment whose isolation argument rests on a package proxy being the sole egress, and treat that proxy's outbound request capability as something to restrict.

2. Clop is exfiltrating engineering data from internet-exposed PTC Windchill and FlexPLM

What Happened

ReliaQuest reported on 23 July that attackers are actively exploiting CVE-2026-12569, a critical unsafe-deserialization flaw (CVSS 9.3) in PTC Windchill and FlexPLM allowing unauthenticated remote code execution, deploying JSP web shells to run commands and exfiltrate product data. Victims have received extortion email from an address Clop announced ahead of this campaign, though ReliaQuest stopped short of confirming attribution and said only that the tradecraft matches previous Cl0p campaigns. PTC began patching on 17 June and warned of heightened threat activity on 26 June; CISA added the CVE to KEV on 25 June with a three-day federal deadline. Germany's BSI phoned and emailed PTC customers overnight urging immediate patching.

Why It Matters

Product Lifecycle Management is the system of record for how things get designed and built, so what leaves is CAD models, bills of materials, supplier terms and pre-release specifications for aerospace, defense, automotive and medtech firms. That data has no expiry and no statute forcing anyone to disclose its loss. PTC claims more than 30,000 customers, and Windchill typically sits with engineering rather than IT, which is the most plausible explanation for internet-exposed instances surviving a KEV deadline that passed a month ago. PLM platforms are also routinely opened to suppliers and contract manufacturers, so one unpatched instance leaks a supply chain's worth of design data.

Action for defenders: Ask engineering, not IT, whether Windchill or FlexPLM runs anywhere in your estate, confirm it is patched for CVE-2026-12569, and get it behind a VPN or access gateway. Where exposure predates the fix, hunt for JSP web shells and rotate any credentials the platform held before restoring service.

🛠 If you only do one thing this week: Open your CI/CD and build tooling inventory and answer one question for each entry can it make outbound requests to a destination someone else controls? The Artifactory escape ran through SSRF in remote-repository handlers, and the same class of capability sits in most artifact proxies, package caches and webhook receivers. You are looking for the components your isolation story quietly depends on. Budget 45 minutes; the output is a list, not a fix.

☁️ 3.  Arista VeloCloud Orchestrator zero-day hits CVSS 10.0, CISA gives agencies three days

What Happened
 Arista patched CVE-2026-16812, an unauthenticated OS command injection flaw in on-premises VeloCloud Orchestrator carrying the maximum CVSS 10.0, after discovering it was already being exploited as a zero-day. Exploitation needs only network access to the VCO web interface and reaches privileged internal functionality that was never meant to be externally reachable. CISA added it to KEV on 27 July alongside a Fortinet FortiOS SSL-VPN flaw, with a three-day federal remediation deadline under BOD 26-04. Arista has not said when attacks began or who is behind them.

Why It Matters
Whoever holds the orchestrator holds configuration, credentials and traffic policy for every edge device it manages.

Action for defenders
Patch on-prem VCO to the fixed builds now and confirm the web interface is not internet-reachable. Then review orchestrator access and configuration-change logs for the past 60 days, on the assumption that a version bump does not remove an attacker who already has a foothold and time to write policy.

🏥 4. An actively exploited FastJson RCE that has no patch and never will

Primary source: Imperva research 
Reporting: SecurityWeek · The Hacker News

What Happened

CVE-2026-16723 (CVSS 9.0) is an unauthenticated remote code execution flaw in FastJson 1.2.68 through 1.2.83, disclosed 21 July following research by FearsOff Cybersecurity. A crafted @type value becomes a class-resource lookup that pulls attacker-controlled bytecode from a nested JAR path inside compatible Spring Boot deployments, and a @JSONType annotation on that resource walks the class past FastJson's security checks. No gadget class is needed and it works with SafeMode disabled, which is the default. ThreatBook first observed exploitation the week of 20 July; Imperva reports attempts against financial services, healthcare, computing, business services and retail organizations, mostly in the US with activity in Singapore and Canada. FastJson 1.x left active maintenance years ago and no patch exists.

Why It Matters

This breaks the assumption most vulnerability programs run on. There is nothing to deploy, so any workflow keyed to "patch available, schedule remediation" parks an actively exploited 9.0 in the backlog indefinitely. The fat-JAR packaging is what makes it a cloud problem: the vulnerable library is compiled inside the application artifact, invisible to host-level inventory and to container scanners that read package manifests. Exposure concentrates in the long tail of legacy internal Java services nobody currently owns, which is also the population least likely to survive a 1.x-to-2.x migration without something breaking. Tager's point in this week's conversation lands almost too neatly here: detection was never the bottleneck, the fix is.

Action for defenders
Scan JAR contents rather than manifests for bundled fastjson 1.2.68–1.2.83, then force SafeMode via -DFastJson.parser.safeMode=true on everything that has to keep running. Open a 2.x migration ticket per hit. WAF rules buy time, but the library is permanently unfixed.

🛡️ 5.  GitHub and PyPI both bet on delay: a 72-hour Dependabot cooldown and a 14-day upload lock

What Happened

Dependabot now waits 72 hours by default before opening pull requests for newly published package versions, a delay GitHub frames as covering the gap between a malicious package being detected and being removed. PyPI separately now rejects new file uploads to any release more than 14 days old, closing off release poisoning by an attacker holding a stolen publishing token. GitHub notes the cooldown is configurable in either direction and does not address longer-term compromise, recommending lockfiles, restricted-scope tokens and disabling unnecessary install scripts in CI alongside it. PyPI says no known past attack has used the technique its change blocks.

Why It Matters

Both changes concede that detection already works and removal does not. Malicious npm packages have repeatedly been flagged within minutes, and the damage happened in the hours it took to get them pulled, so the two largest registries are now buying that window back with a timer. For anyone running automated dependency updates, the default security posture of the pipeline changed this week without a config change, and the teams most affected are the ones who tuned Dependabot to merge fast. PyPI's move is the more interesting precedent, because it restricts a legitimate maintainer capability preemptively against a technique nobody has been caught using. This is also the story Tager reached for unprompted: she raised malicious npm and PyPI packages as the reason the developer environment now needs investment of its own.

Action for defenders: 
Check whether any repo overrides the new Dependabot cooldown to something shorter, and require a documented reason to keep it — three days is now the platform default rather than a policy you have to argue for. Pair it with lockfile pinning and CI install-script suppression.

6.  ShinyHunters claims the EY breach, says supply-chain credentials opened Jira, GitHub and Azure

What happened: ShinyHunters added Ernst & Young to its leak site on 27 July, claiming responsibility for the breach EY disclosed earlier this month and setting a 31 July deadline for EY to make contact. EY's notification says a third-party IT service management platform used by its internal IT staff was compromised: it detected unusual activity on 23 April and determined an attacker had access between 28 March and 12 April, downloading support tickets that may contain client tax documents and the personal and financial information used to prepare filings. The threat actors told BleepingComputer that credentials obtained through a supply-chain attack let them reach EY's Jira, GitHub and Azure environments, and that more was taken than EY has acknowledged. EY has not confirmed ShinyHunters was responsible, has not named the compromised platform, and has not said how many people are affected.

Why it matters:  The claimed path runs third-party ticketing to Jira to GitHub to Azure, and it works because support tooling accumulates credentials, tokens and infrastructure detail that nobody classifies as sensitive at the moment of pasting them into a ticket. The more useful number for a CISO is the eleven weeks between last attacker access on 12 April and public attribution on 27 July. Detection came 11 days after the access ended, and the true scope only became visible when the attacker decided to publish. A Big Four firm holding client tax filings is a concentration point, so downstream clients inherit exposure from a vendor relationship they cannot see into.

Action for defenders: Pull the list of third-party ITSM, ticketing and support platforms your IT staff use, and check what each one can reach: SSO scope, API tokens, standing access into Jira, source control or cloud tenants. Where a ticket queue can hold pasted credentials, turn on secret scanning for it or accept that it is a credential store.

7.  CISA, ACSC and the FBI publish CI Fortify: plan now to run vital systems disconnected for months

What happened: CISA, the Australian Signals Directorate's ACSC, the FBI and international partners published joint guidance on 28 July telling critical infrastructure operators to engineer, in advance, the ability to sever vital operational technology from corporate, internet-facing and vendor networks and keep delivering service while disconnected for an extended period. The document defines a working vocabulary — vital systems, isolation points, physical versus graduated isolation, data diodes, post-isolation monitoring — and asks organizations to identify the minimum systems needed to deliver a critical service, then document every connection those systems have to corporate networks, remote access, cloud environments, vendors and other operators. It calls physical isolation the most effective protection while acknowledging it is impractical where operations depend on carrier networks, cloud services or distributed sites. It also names the costs: systems falling behind on updates, reduced monitoring, and more removable media in circulation.

Why it matters:  The guidance asks a question most cloud architectures cannot currently answer, which is which cloud dependencies must be severable on command and what still works once they are. That turns a resilience aspiration into a documented inventory with named isolation points and named people authorized to trigger them. The emphasis on Windows dependencies like Active Directory and DNS is the part that reaches past OT shops, because those are exactly the services quietly re-homed to cloud identity providers, which makes "disconnect from the internet" a change that breaks authentication for the plant.

Action for defenders: For one critical service, list the cloud and vendor dependencies its OT and supporting systems actually have, and mark which can be disconnected without stopping the service. The gaps are the finding. Then confirm an offline or printed copy of the isolation plan exists, because the guidance is explicit that the plan has to survive losing access to corporate storage.

8.  Russian LAUNDRY BEAR uses a Zimbra zero-click flaw to steal mail and 2FA codes

What happened: CISA, NSA, FBI and international partners published advisory AA26-204A on the Russian state-supported group LAUNDRY BEAR, also tracked as Void Blizzard and TA488, which has targeted government, defense, energy, technology, education, media, law enforcement and NGO organizations since at least July 2025. The campaign exploits CVE-2025-66376, a cross-site scripting flaw in Zimbra Collaboration Suite webmail caused by insufficient sanitization of CSS @import directives in email content, using a custom capability called Ulej. It is zero-click: viewing a malicious email in a vulnerable ZCS webmail session is enough to trigger exfiltration of email content, credentials and two-factor authentication codes. Zimbra patched in November 2025 and exploitation of unpatched servers continues.

Why it matters:  Theft of second-factor codes out of webmail is the detail that escapes the Zimbra install base, because it turns "we have MFA" from a control into an assumption for every downstream system trusting codes delivered to or through mail. The timeline is the other lesson: exploitation from mid-2025, a patch in November, a government advisory in July 2026 still aimed at unpatched servers. Organizations that moved to hosted mail often still carry this through subsidiaries, acquisitions and partners running ZCS on-prem.

Action for defenders: Confirm every Zimbra instance in the estate, including subsidiaries and recent acquisitions, is patched for CVE-2025-66376, and hunt using the advisory's detection guidance. Where compromise is plausible, rotate credentials and re-enroll MFA rather than only patching the whole point of the campaign is that the second factor was already taken.

🎯 Cloud Security Topic of the Week:

From AppSec and CloudSec to Product Security - What a 25-Minute Exploit Window Does to Your Org Chart

Sarit Tager's argument starts with a number and ends with an org chart. The number is the gap between a vulnerability being discovered and being exploited. Ashish put the figure he'd seen to her — under 24 hours — and she revised it down: "Yeah. Sometime even few min-- even like 25 minutes or 30 minutes. It really depends."

What follows from that is the whole thesis. If the window is minutes, nobody responds inside it. The only remaining options are to have fixed the thing before production, or to have a runtime control that blocks without waiting for a human. Both, in her framing, and neither belongs cleanly to the AppSec team or the CloudSec team as currently drawn.

The convergence she describes is not a reorg for its own sake. It comes from the attacker's behaviour: "I don't think we can u- we can say, 'Yeah, someone will do cloud security, someone will do apps- application security, and yeah, this one will do AI.' 'Cause then the agent will find a way to ca- actually go between these programs and find a way to exploit. So it has to be a unified one."

Ashish's response to that is the cleanest summary of the problem in the episode: "these are all human-created boundaries. These are not AI boundaries." [Listen to the full episode →]

Definitions and Core Concepts 📚

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

  • Product security — In Tager's framing, the merged function CloudSec and AppSec are converging into: "I need to make sure that the product is secure, whether it's being secured by the shift left of it, like within application security or within the cloud."

  • Runtime agent — Tager is explicit that she does not mean an AI agent: "they all understand that they need to deploy an agent. Yeah. Not an AI agent, but an agent. Like the cloud agent." She frames it as the first line of defense and the control covering whatever pre-production work missed.

  • Post-Mythos — Her term for the planning category customers have formed around frontier models being pointed at their environments: "we call it a post Mythos attacks."

  • Harness (LLM sense) — The scaffolding and explicit security guidelines around a model that make its security findings usable. Without one, Tager says the output is non-deterministic and it is unclear what needs fixing.

  • Non-deterministic attacks — Her term for novel, model-generated attack paths that match no predefined signature or configuration rule, contrasted with "old attacks" like CVE exploitation and SQL injection, which she notes still work.

  • Fat JAR — A Java application packaged with its dependencies compiled inside the artifact. Relevant to story 4 because it hides vulnerable library versions from scanners that read package manifests.

  • Server-side request forgery (SSRF) — A flaw letting an attacker make a server issue HTTP requests to destinations of the attacker's choosing and return the responses. Three of the eight Artifactory CVEs are SSRF in remote-repository handlers.

  • KEV / BOD 26-04 — CISA's Known Exploited Vulnerabilities catalog and the binding operational directive setting federal remediation deadlines. Three days is unusually short; three weeks is more typical.

This week's issue is sponsored by Varonis

Pixel, Varonis' threat-detecting cat, was on vacation when an Entra ID breach hit. She needs your help to investigate. Breach at the Beach is a free, four-stage CTF built on real incidents showing you how attackers move through Entra ID environments and abuse legitimate features. 

Start playing online today and join us in the Varonis booth (#2948) during Black Hat and in the Cloud Village at DEF CON 34, where Varonis Threat Labs researchers will be on-site to help you push to the finish line. Earn CPE credits and chances to win exclusive swag and prizes at both events.

💡Our Insights from this Practitioner 🔍

1. A coding agent's first goal is working code. Security is the second goal, and the two conflict

The most common response to AI-generated code risk is to put the word "secure" in the prompt. Ashish put that objection to Tager directly can't he just tell developers that next time they create an S3 bucket, "secure" is a word they use in the prompt, and let the CNAPP handle the rest?

Her answer separates the two goals the agent is holding:

"So first, remember that this is kind of a two goals for the agent. First, create the code, and then make it secure. [...] The first one is the important one for a coding agent, right? Not a security one. But as a coding agent, you have to m- first make sure that you have a code. [...] This means that if there will be a kind of a contradiction bet-between the two, it will fi- it will kind of, uh, work, work with the, let's make sure we have a code."

Earlier in the conversation she put it in five words:

"If I am a coding agent, then my plan is to create the code."

"Security come second."

The failure mode she describes from her own testing is worth sitting with, because it cuts the other way. An LLM proposed resolving a security finding by removing a flag, and the flag was load-bearing functionality: "It will be super secure, but not [...] to work to what I need." Instructing hard enough for security can produce no working code at all. Her conclusion is that the balance has to be enforced somewhere other than inside the coding agent.

 2. A human gives up after three attempts. An agent never does

This is the line most likely to change how a security architect thinks about developer permissions, and it came via an unnamed CISO:

"a CISO once tell me that a user will probably give up after three tries to do something which is not- [...] uh, uh, I would say safe. Yeah. An agent will never."

The context is permissions. Developers hold broad access by necessity — local execution, repo access, company IP — and that has been tolerable because the population exercising it mostly doesn't intend harm and gives up when blocked. Agents inherit the same permissions and neither property holds.

What Tager takes from this is a scope expansion most organizations have not started. The thing to protect is no longer just the code coming out of the developer environment:

"we need to make sure that we kind of, protect it from the beginning, whether it's the code, but also the environment itself. Like which MCP are running, which type of skills, what exact- which agent are running there, and how this kind of form a code that may not be safe to be deployed"

That is an inventory question with no current owner in most orgs. Which MCP servers are running on developer machines, which skills are installed, which agents are operating, and what each can reach.

3. Detection was never the bottleneck. The fix is

Asked whether SAST, SCA, runtime and infrastructure tooling still matter, Tager said "yes and no" — CVE detection in open-source packages still needs doing, and some teams keep static analysis for compliance. Then she named what actually changed:

"I always saying, like detection was never the problem in application security, right? We already had too much detection, and the fact that we al- also have LLMs, uh, and they detect things, this is good, but it's never was a problem. The problem was trying to manage all this entire backlog and try to fix things."

This week's FastJson story is an unusually literal illustration. An actively exploited 9.0 with no patch available leaves nothing to deploy, and every triage workflow keyed to patch availability parks it. More detection would not help. The second change she names is non-deterministic attacks — novel paths that no configuration rule anticipates which is why she argues scanning for known-bad configurations is no longer sufficient on its own.

4. Rolling your own AppSec program on raw LLMs fails for a specific reason

A wave of companies tried to build AI-driven AppSec internally rather than buy tooling. Tager says they hit the same wall:

"we saw kind of a wave of co- of, uh, companies trying to do them, not the agent, not the runtime agent, but some of the AppSec program, they try to do it by themselves. Right. And then they assume not as simple as, as it seems 'cause just running the LLMs with no, like, harness, with no, with no specific security guidelines, will not necessarily give determinist- deterministic stuff, and it's not that clear what will need be fixed code."

Ashish characterized the pattern as pointing an LLM at a codebase and asking it to run the OWASP Top 10. Tager didn't dispute it. The gap is the harness: the scaffolding, the explicit security guidelines, and the determinism that lets a finding become a ticket someone can close.

She also names the constraint that kills the DIY route even when the approach is sound. Customers who decide to "build myself something that will scan everything for me" run into the cost of tokens, which she reports someone calling "the new economy."

5. There is no such thing as a separate AI security program

This is Tager's strongest take, and she gets there from a budget conversation. Customers arrive with money allocated for AI security and a plan to stand up a distinct program:

"In my perspective, it's AI is more like a layer on top of everything we know, right? [...] So if you say I have an AI program, AI security program, it seems like you basically said, 'Yeah, I'm rebooting the, my s- entire security, uh, kind of program from the start.' 'Cause I feel everything will be within AI, and it's another layer of complexity and attack or attack surface on top of everything we know."

Her reasoning is that AI already sits in the developer environment, in CI/CD and in the cloud simultaneously, so carving it out as its own program means either duplicating every existing control or restarting from zero. And the boundaries such a program creates are ones the attacker ignores, which is where the "the agent will find a way to go between these programs" line comes from.

She carves out one genuine exception: data going to an LLM is a distinct problem — "you want to make sure that you are not being exposed. So th- in this case, it's a, it's a different thing." Everything else she treats as identity and permission management inside existing programs.

6. Posture alone is finished, and she has never seen a company fix everything

Asked where runtime security now sits, Tager was blunt about the limits of pre-production work:

"even if you be the most secure, uh, and I didn't see the company that actually fixed everything for application security, not yet, but maybe there is a company like that. Even if you do everything right on the application security side- [...] you will still have some unknown, and this has to be protected by a runtime agent."

The line she uses on customers without one:

"I can share that someone asked me, 'Okay, so if you don't have any runtime agent, so what are you doing?' I said, 'Probably praying- [...] that you won't be, you won't be, uh, affected.'"

She also relays a customer routing all critical posture findings into the SOC, and her own pushback that a posture issue is not an attack. The customer's answer: "Yeah, but it's attack to be happened, right? [...] 'Cause they are the critical one." She frames this approvingly, as posture signal reaching the people positioned to act before the attack rather than after.

7. "Where is my application deployed within those 1,000 accounts?"

The practical mechanism for joining the two functions is reporting in terms of the application rather than the layer, because that is the unit the business owner cares about:

"if they want to report back to the business saying, 'I have like 1K accounts, and they are all covered,' and then I as in a business owner will say, 'Okay, but where my application is actually deployed within this 1K account,' right? [...] I care about my application as a business owner. I want to make sure that it-- you gave me all the measures to make sure that my application is protected because it contains sensitive data or doing some sensitive actions."

Infrastructure, data and identity are all components of the application from the application owner's perspective, so the reporting line runs through the application. On how CISOs sell this internally, she says the argument isn't headcount: "they don't necessarily talk about the manpower, but more about the problem." The outcome argued for is reduced time to remediate and reduced time to respond.

8. The silo that resisted a decade of DevSecOps is being broken by agents

Ashish observed that the industry has been talking about breaking the cloud/AppSec silo for years without managing it. Tager's reply was one line:

"It seems the AI agents are pushing us to do that."

Asked whether the DevSecOps model still applies, she gave it a time limit rather than a verdict — you still need an experienced human for complex decisions, "Just, I say just for the current time," because she expects that role to become an agent too, the way code review largely already has. Her framing is that the security expert trains an agent to make the decisions they would make, and the resulting capability replicates far more easily than the person did.

Practical takeaways

  • Stop relying on prompt-level security instructions in coding agents. The agent resolves goal conflicts in favour of shipping code.

  • Inventory the developer environment as an asset class: MCP servers, installed skills, running agents, and what each can reach.

  • If your triage process is keyed to patch availability, it has a blind spot. FastJson is this week's proof.

  • Report coverage by application, not by account. It is the only framing the business owner can act on.

  • If you have no runtime control, be honest with yourself about what the plan actually is.

Podcast Episode

Question for you? (Reply to this email)

🤔  Which MCP servers and agents are running in your developer environment right now and could you produce that list today?

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