A $1.8 million App Store scam lawsuit tests how much software vetting Australian firms can safely outsource.

The post Why Apple’s Recent Crypto Lawsuit Should Worry Australian IT Leaders appeared first on TechRepublic.

A June 2026 research review found that AI chatbot warning labels may be a weak safeguard for organization-backed AI advisors, raising new audit questions for IT, security, and compliance teams.

The post AI Chatbot Warnings May Not Stop Hallucinations, Researchers Say appeared first on TechRepublic.

Sunil Varkey has been appointed as Executive Vice President (EVP) and Chief Information Security Officer (CISO) at Hexaware Technologies, where he will lead the company's information security strategy, governance, risk management, and enterprise resilience initiatives. The appointment marks the latest leadership role for the cybersecurity veteran, who brings more than three decades of experience across global enterprises and multiple industry sectors. Based in Chennai, India, and operating in a hybrid work model, Varkey will be responsible for strengthening enterprise cybersecurity governance, risk management frameworks, and overall security strategy at Hexaware Technologies. His appointment was announced in June 2026.

Sunil Varkey to Lead Cybersecurity Strategy at Hexaware Technologies

In his new role, Sunil Varkey will oversee key areas including information security governance, enterprise risk management, and resilience initiatives. His responsibilities align with Hexaware Technologies' broader technology and growth objectives as the company continues to support large-scale digital transformation programs for clients worldwide. Hexaware Technologies delivers technology-led services across application development, cloud services, automation, data analytics, and enterprise IT operations. The company serves organizations across multiple industries and supports digital modernization initiatives at scale. Varkey's appointment comes as organizations continue to focus on strengthening cybersecurity programs and managing digital risks across increasingly complex technology environments.

More Than 30 Years of Cybersecurity Leadership Experience

Varkey brings over 30 years of experience in cybersecurity leadership spanning banking, telecommunications, IT services, manufacturing, and enterprise technology sectors. His professional experience extends across India, the Middle East, and the United States. His areas of expertise include cybersecurity governance, risk and compliance (GRC), security architecture, incident response, DevSecOps, cloud security, privacy management, cyber defense, business continuity management, security operations, and AI security. Prior to joining Hexaware Technologies, Varkey served as Cyber Security Consultant and Advisor at TAHAKOM in Riyadh, Saudi Arabia, from June 2023 to March 2025. In that role, he worked alongside the organization's CISO to enhance cybersecurity resilience and strengthen security posture. Before TAHAKOM, he held the position of Vice President and Chief Technology Officer for EMEA and APJ at Forescout Technologies Inc. between April 2021 and November 2022. Based in Dubai, he focused on IT/OT security strategy, enterprise cybersecurity advisory services, and product positioning across global markets.

Leadership Roles Across Global Organizations

Between March 2020 and January 2021, Varkey served as Managing Director and Global Head of Cyber Security Assessments and Testing at HSBC in Hyderabad. He led a team of approximately 300 professionals responsible for penetration testing, threat modeling, vulnerability management, and third-party security risk assessments. Earlier, from December 2018 to February 2020, he worked as CTO and Security Strategist for the Middle East, Africa, and Eastern Europe region at Symantec. His responsibilities included developing cybersecurity strategies for enterprise, government, industrial, and financial sector organizations. His career also includes senior leadership positions such as Global CISO at Wipro, CISO for Security and Privacy at Idea Cellular, and Vice President of Security Engineering at Barclays. Additionally, he held global security leadership roles at GE Capital, Genpact, Paramount Computer Systems, and other multinational organizations.

Focus on Governance, Risk Management, and Enterprise Resilience

Throughout his career, Varkey has overseen cybersecurity functions covering governance, compliance, strategy, security engineering, incident response, privacy, cloud security, cyber defense, and enterprise resilience. His experience includes leading security programs for organizations with large-scale user bases and complex operational environments. At Wipro, he served as Global CISO for a technology company supporting more than 200,000 end users. At Idea Cellular, he led security and privacy initiatives for a telecom operator with approximately 120 million subscribers. With his appointment, Hexaware Technologies adds a cybersecurity leader with extensive experience in building and scaling security programs across global enterprises. The move underscores the company's continued focus on strengthening cybersecurity operations, governance frameworks, and digital risk management capabilities as part of its ongoing technology initiatives.

A few weeks ago, we wrote about Project Glasswing and what we observed when we pointed cyber frontier models at our own code. Since then, we’ve seen that the part of the post that has resonated most deeply is the argument that the architecture around the vulnerability matters more than the speed of the patch.

In the conversations we've had with CISOs and security teams since, the questions have been consistent: what does our architecture actually look like, what should we monitor for, where do we start, and how can Cloudflare help?

Before getting into the details: the architecture below is built almost entirely from Cloudflare's own products, because Cloudflare security is customer zero for the security products we build. The Cloudflare stack already exists in front of our code, employees, and customer-facing applications. If you're a Cloudflare customer, every layer below is available to you today. If you're not, the principles still apply to whatever stack you've built.

What a cyber frontier model actually changes

In the previous post, we showed how a cyber frontier model like Mythos changes the attacker’s timeline. It can find vulnerabilities, reason through exploit chains, and generate working proofs faster than earlier models. While models like Mythos do not change the shape of an intrusion — reconnaissance, initial access, lateral movement, persistence, and exfiltration still have to happen — the difference is in the speed and scale. When pointed at the open web, a model can find and hit low-hanging fruit quickly. Against a hardened target, it still has to probe, and adapt, and it often produces more noise than a careful human operator would.

Discovery, exploit chain construction, and proof-of-concept generation used to be the gating constraints on producing a working attack. A frontier model handles all three in a fraction of the time. Work that used to be slow and methodical is now fast and indiscriminate.

While AI is accelerating how fast developer teams at Cloudflare and many other companies can ship code, the security team’s work has not compressed the same way. An attacker only needs one opening to get in, while security teams need to find and close them all. Writing a fix, regressing it, and shipping it without breaking the code around it has constraints that AI doesn't remove. We learned this the hard way when we let an AI coding assistant write its own patches against our own bugs, as we described at the end of the previous post. Some of those patches fixed the original bug while quietly breaking something else the code depended on.

As these models become more competent and capable, our main focus from a threat standpoint comes down to three things. Each one shapes the architecture we walk through in the rest of this post.

• The first is the speed of discovery. Frontier models make it easier to search large bodies of public code, including the open-source libraries that many companies depend on. That does not mean every bug in a library is exploitable, or that library bugs are where most vulnerabilities live. Exploitability still depends on how the code is used, whether attacker-controlled input can reach the vulnerable path, and the protections that sit around it. But widely used open-source libraries and frameworks give attackers a shared surface to study at scale. When a real, reachable vulnerability exists there, a model can help find it, reason about possible exploit paths, and generate proof-of-concept variants faster than maintainers and defenders can review every downstream use. The gap between when an attacker discovers a vulnerability and when defenders learn it exists is what worries us most. If you are not running these models against your own code, it is safe to assume someone else is.
• The second is exploit volume and adaptation. A model can produce thousands of variations of a single exploit and run reconnaissance at the same scale. All that volume gives an attacker an advantage, but it won’t necessarily get them past signature-based detections. Many of those iterations will have the same underlying signature, so a rule that catches the first one will catch the rest. Adaptation is how they will get past signature-based detections. Ask a model to show you a SQL injection, and it will return a textbook example. Tell it there is a WAF in the way, and it will start probing, learning what gets blocked, and rewriting the payload until it can slip past the rule blocking it.
• The third is the impact when a vulnerability is inevitably exploited. No architecture catches everything. After the vulnerability is exploited, the question we ask ourselves is: where can the attacker get to with one identity, one path, or one credential, before something else stops them? If the answer is "anywhere they want," the vulnerability was never the problem. The architecture around the vulnerability was.

Cloudflare’s superpower: visibility

We see roughly a fifth of the web and that tells us, in real time, which payloads are mutating, which patterns are picking up, and where attacker tooling is moving next. Two teams turn that visibility into defense.

First is Cloudforce One, our threat intelligence, research, and operations team, which sits within the Cloudflare security organization. They turn what we see across the network into insights the rest of the stack can act on: tracked adversaries, emerging campaigns, and indicators of compromise (IOCs). The hard part of this work was never knowing what is malicious — it was the delay in mitigation. Knowledge of a new threat normally has to travel from a threat report, into a feed, and then into a company’s defense before it can be used to block anything. Attackers have learned to move faster than that. Our network closes that gap: Cloudflare customers can now use Cloudforce One threat intelligence directly within the WAF to block high-risk traffic.

Second is the team that owns the WAF engine that does the actual detecting: the managed rulesets that run in front of our own properties and are available to every Cloudflare customer, the machine learning behind WAF Attack Score, and the relationships that sometimes let us ship a rule before a CVE is publicly disclosed. The team is globally distributed and moves fast, releasing rules within hours of a proof-of-concept of an attack becoming known. Once a detection is deployed, it reaches our entire network, along with every Cloudflare customer, in under 30 seconds. React2Shell is a recent example: a managed WAF rule was protecting our own properties, and everyone else's on Cloudflare, hours before the official advisory was published.

The scoring layer, the defenses we put in front of the application, and the containment around the vulnerability all build on what these two teams see. 

Scores over signatures

Signature-based defenses were built for a world where novel exploits were scarce and variations took weeks. Cloudflare's traditional SLA from a fresh proof-of-concept to a live, deployed rule has been 12 hours. With the advent of frontier models, this is not good enough anymore. Detections need to be in place before a CVE is discovered. This is why we layer ML-based detection in front of the traditional signature-based WAF.

The model is trained on a large body of past attack traffic, and it catches new variants of vulnerabilities before they're publicly known. A novel SQL injection or remote code execution chain is almost always a rearrangement of attack shapes the model has seen before, even when the specific exploit is brand new. We run the model on every request and assign a WAF Attack Score between 1 and 99, based on how closely the request resembles those underlying shapes, not against a list of known-bad signatures. The lower the score, the more aggressively we treat the request. That score determines whether we let the request through. We apply a similar scoring methodology to AI prompts with AI Security for Apps: rather than check each prompt against a list of known malicious prompts, we score how closely a prompt resembles an actual attack. 

The architecture around the vulnerability

Those capabilities only matter once they're stacked in front of an application, and the first layer in our defense-in-depth approach is the WAF. Anything that matches a known-bad pattern gets dropped before it reaches the application, which clears the bulk of the obvious traffic and lets the more specialized layers below focus on what's left.

On the API surface, we run a positive security model through API Shield. Instead of trying to anticipate every bad request, we describe what a valid request to each API looks like, either from the API's own definition or learned from our real traffic, and anything that doesn't fit doesn't get through. This neutralizes the advantage of frontier AI models: because we only permit validated traffic, generating thousands of new attack variations fails to bypass the system.

^{Cloudflare’s layered architecture}

Bot Management catches probing traffic on our network before frontier models can build a map. It scores every request on how likely it is to be automated, using the same signals across our whole network: how the client behaves, whether it looks like a real browser, and whether the connection matches a known-bad pattern. An attack only lands if it can find a soft spot. 

Zero Trust Network Access is used for every internal application. The implicit trust of being inside the network is replaced with explicit per-request identity and policy for every employee accessing every tool. The value of this was clear when one of our engineers shipped a misconfigured tool. A flat network would have exposed everything on the same segment, but in our deployment, the exposure stopped at the tool itself. We built Require Access Protection afterwards so newly deployed or misconfigured applications can't be reachable before an access policy is in place.

IdP Federation makes that secure by default posture easier to keep consistent across every Cloudflare account — which becomes even more necessary when more people are shipping internal tools quickly. Instead of asking each team to wire up SSO separately, we configure our identity provider (IdP) once and share it across the organization. New accounts get SSO automatically, recipient-side IdP connections are read-only, and Access policies in each account still evaluate the resulting identity as part of the normal request flow. 

MCP Server Portal gives teams a controlled way to connect AI agents to enterprise systems. Agents access MCP servers that are centrally managed through a single portal, with every action logged. That way when an agent acts on someone's behalf, we know what it did, what it touched, and whether it should have been allowed to. The full picture of how we built it is in our post on enterprise MCP.

AI Gateway runs in front of our internal AI tools the same way AI Security for Apps runs in front of customer-facing AI features, with the same scoring and the same visibility. Inside the company, the visibility piece is more useful than the blocking, because we needed to see what engineers were actually building before we could write meaningful policy on it.

Where your teams can start 

Frontier models can help attackers find vulnerabilities, adapt payloads, and move faster, but they still have to pass through the layered defense you deploy in front of your application. That is where teams should start:

• Put inspection in front of public applications.
• Define what valid API traffic looks like.
• Use bot detection to limit automated probing.
• Require identity and access policy before any internal tool is reachable.

For AI and agentic systems:

• Route model traffic through a gateway.
• Keep agents connected through approved MCP servers.
• Log what they do. 

The goal is to make sure that when one layer misses, the next layer limits what the attacker can see, reach, or change.

That is the point of the architecture around the vulnerability: to limit the scope of an attack. The vulnerability may be what starts the attack, but the architecture determines how far it can go.

How do we know this approach works?

Plenty of security stacks look impenetrable on a whiteboard but fall over in practice. That is why we test ours continuously, both at the perimeter and inside our environment, with our red team involved across both.

At the perimeter, frontier models are one tool we use to test our application security stack as an adaptive attacker. These models sit alongside the rest of our red team and detection workflows including: manual testing, threat intelligence, observed traffic patterns, proof-of-concept analysis, and signals from our own network. Together, those inputs help us decide where to aim testing: newly launched products, recently changed surfaces, and the paths an attacker is most likely to probe first. The most important part is the process that follows. When something gets through, we identify the gap, use the right mix of tools to understand it, write the rule or mitigation, ship the update, and test again to make sure the gap is closed.

Inside the environment, our red team starts from the assumption that the perimeter has already failed. They look at what has changed, where sensitive systems carry risk, and whether one compromised identity, path, or credential can reach farther than it should. When we change the architecture based on what they find, they run the scenario again against the new version to confirm the gap is actually closed.

We confirm that this architecture is working by continuously testing its behavior during failures, rather than relying on the perfection of individual layers.

If your team is working on the same problems and would like to compare notes, reach out to us at security-ai-research@cloudflare.com.

For the last few months, we've been testing a range of security-focused LLMs on our own infrastructure. These LLMs  help identify potential vulnerabilities in our own systems, so we can fix them – and they also show us what attackers are going to be able to do with the latest models.

None of these LLMs has captured more attention than Mythos Preview, from Anthropic. A few weeks ago, we were invited to use Mythos Preview as part of Project Glasswing. We soon pointed it at more than fifty of our own repositories – to see what it would find, and to see how it works.

This post shares what we observed, what the models did well and what they didn't, and how the architecture and process around them needs to change, so they can be used at scale.

What changed with Mythos Preview

Mythos Preview is a real step forward, and it's worth saying that plainly before getting into anything else. We've been running models against our code for a while now, and the jump from what was possible with previous general-purpose frontier models to what Mythos Preview does today is not just a refinement of what came before.

It's a different kind of tool doing a different kind of work, and that makes a clean apples-to-apples comparison to earlier models difficult. So rather than trying to benchmark Mythos Preview against general-purpose frontier models, it's more useful to describe what it can actually do, and two features that stood out across the work we did with Mythos Preview:

• Exploit chain construction - A real attack rarely uses one bug. It chains several small attack primitives together into a working exploit. For instance, it might turn a use-after-free bug into an arbitrary read and write primitive, hijack the control flow, and use return-oriented programming (ROP) chains to take full control over a system. Mythos Preview can take several of these primitives and reason about how to combine them into a working proof. The reasoning it shows along the way looks like the work of a senior researcher rather than the output of an automated scanner.
• Proof generation - Finding a bug and proving it's exploitable are two different things, and Mythos Preview can do both. It writes code that would trigger the suspected bug, compiles that code in a scratch environment, and runs it. If the program does what the model expected, that's the proof. If it doesn't, the model reads the failure, adjusts its hypothesis, and tries again. The loop matters as much as the bugs it finds, because a suspected flaw without a working proof is speculation, and Mythos Preview closes that gap on its own.

Some of what we describe above is not entirely unique to Mythos Preview. When we ran other frontier models through the same harness, they found a fair number of the same underlying bugs, and in some cases they got further than we expected on the reasoning side too. Where they fell short was at the point of stitching the pieces together. A model would identify an interesting bug, write a thoughtful description of why it mattered, and then stop, leaving the actual chain unfinished and the question of exploitability open. What changed with Mythos Preview is that a model can now take those low-severity bugs (which would traditionally sit invisible in a backlog) and chain them into a single, more severe exploit. 

Model refusals in legitimate vulnerability research

The Mythos Preview model provided by Anthropic, as part of Project Glasswing, did not have the additional safeguards that are present in generally available models (like Opus 4.7 or GPT-5.5).

Despite this, the model organically pushes back on certain requests - much like the cyber capabilities that made it useful for vulnerability hunting, the model has its own emergent guardrails that sometimes cause it to push back on legitimate security research requests. But as we found, these organic refusals aren’t consistent - the same task, framed differently or presented in a different context, could produce completely different outcomes as illustrated in the examples below.

^{Example of Mythos Preview pushing back on building a working proof of concept} 

For example, the model initially refused to do vulnerability research on a project, then agreed to perform the same research on the same code after an unrelated change to the project’s environment. Nothing about the code being analyzed had changed.

In another case, the model found and confirmed several serious memory bugs in a codebase, and then refused to write a demonstration exploit. The same request, framed differently, got a different answer, and even the same request can produce different outcomes across runs due to the probabilistic nature of the model. Semantically equivalent tasks can produce opposite outcomes depending on how and when they’re presented to the model.

This matters because while the model’s organic refusals/guardrails are real, they aren’t consistent enough to serve as a complete safety boundary on their own. That’s precisely why any capable cyber frontier model made generally available in the future must include additional safeguards on top of this baseline behavior - making it appropriate for broader use outside of a controlled research context like Project Glasswing.

The signal-to-noise problem

One of the hardest parts of triaging security vulnerabilities is deciding which bugs are real, which are exploitable, and which need fixing now. This was a hard problem even in the pre-AI world. AI vulnerability scanners and AI-generated code have made it worse, and at Cloudflare we've built multiple post-validation stages to deal with it.

Two factors dominate the noise rate:

• Programming language - C and C++ give you direct memory control and, with it, bug classes - buffer overflows, out-of-bounds reads and writes - that memory-safe languages like Rust eliminate at compile time. We saw consistently more false positives from projects written in memory-unsafe languages.
• Model bias - A good human researcher tells you what they found and how confident they are. Models don't. Ask a model to find bugs, and it will find them, whether the code has any or not. Findings come back hedged with "possibly," "potentially," "could in theory," and the hedged findings vastly outnumber the solid ones. That's a reasonable bias for an exploratory tool. It's a ruinous one for a triage queue, where every speculative finding spends human attention and tokens to dismiss, and that cost compounds across thousands of findings.

Mythos Preview represents a clear improvement here, particularly in its ability to chain primitives - combining multiple vulnerabilities into a working proof of concept rather than reporting them in isolation. A finding that arrives with a PoC is a finding you can act on, and it means far less time spent asking "is this even real?"

Our harnesses are deliberately tuned to over-report, so we see more (and miss less), which comes with a lot more noise. But at triage time, Mythos Preview's output has noticeably higher quality: fewer hedged findings, clearer reproduction steps, and less work to reach a fix-or-dismiss decision.

Why pointing a generic coding agent at a repo doesn't work

When we first started AI-assisted vulnerability research last year, our instinct was the obvious one: point a generic coding agent at an arbitrary repository and ask it to discover vulnerabilities. This approach works, in the sense that the model will produce findings, but it doesn't work in producing meaningful coverage of a real codebase and identifying findings of value. There are two main reasons for this:

• Context - Coding agents are tuned for one focused stream of work: building a feature, fixing a bug, writing a refactor. They ingest a lot of source code, hold a single hypothesis at a time, and iterate against it. That's exactly the wrong shape for vulnerability research, which is narrow and parallel by nature. A human researcher picks one specific thing to look at and investigates it thoroughly. That one thing might be a single complex feature, transitions across security boundaries, or a specific vulnerability class like command injections, where attacker input ends up being run as a shell command. Then they do it again, for a different feature, security boundary, or vulnerability class, several thousand times across the codebase. A single agent session (even with subagents) against a hundred-thousand-line repository can cover maybe a tenth of a percent of the surface in a useful way before the model's context window fills up and compaction kicks in - potentially discarding earlier findings that would have mattered.
• Throughput - A single-stream agent does one thing at a time, but real codebases need many hypotheses against many components at once, with the ability to fan out further when something interesting turns up. You can drive a single agent harder, but at some point you stop being limited by the model and start being limited by the shape of the interaction itself. Using the model directly in a coding agent turns out to be fine for manual investigation when a researcher already has a lead and wants a second pair of eyes. However, it's the wrong tool for achieving high coverage. Once we accepted that, we stopped trying to make Mythos Preview do the wrong job and started building the harness around it instead.

What a harness actually fixes

Four lessons came out of running the work at scale, and each one pointed to the need for a harness that manages the overall execution:

• Narrow scope produces better findings - Telling the model "Find vulnerabilities in this repository" makes it wander. Telling it "Look for command injection in this specific function, with this trust boundary above it, here's the architecture document and here's prior coverage of this area" makes it do something much closer to what a researcher would actually do.
• Adversarial review reduces noise - Adding a second agent between the initial finding and the queue - one with a different prompt, a different model, and no ability to generate its own findings - catches a lot of the noise that the first agent would miss if it just checked its own work. It turns out that putting two agents in deliberate disagreement is way more effective than just telling one agent to be careful.
• Splitting the chain across agents produces better reasoning - Asking "Is this code buggy?" and "Can an attacker actually reach this bug from outside the system?" are two different questions, and the model is better at each one when you ask them separately, because each question is narrower than the combined version.
• Parallel narrow tasks beat one exhaustive agent - Coverage improves when many agents work on tightly scoped questions and we deduplicate the results afterward, rather than asking one agent to be exhaustive.

Each of those observations is about model behavior, and put together they describe something that isn't a chat interface anymore. It's a harness that helps you achieve the final outcomes. The first steps to building a harness are simple, as you can ask the model to help, which is what we did. We used Mythos Preview to build on, tailor, and improve our original harnesses to suit its strengths.

An example of what a harness looks like in practice is described below.

Our vulnerability discovery harness

Here's what our vulnerability discovery harness looks like, stage by stage. It was used to scan live code across our runtime, edge data path, protocol stack, control plane, and the open-source projects we depend on.

What this means for security teams

The loudest reaction to Mythos Preview from other security leaders has been about speed - scan faster, patch faster, compress the response cycle. More than one team we have spoken with is now operating under a two-hour SLA from CVE release to patch in production. The instinct is understandable: when the attacker timeline shortens, the defender timeline has to shorten with it. Faster is not going to be enough, and we think a lot of teams are about to spend a lot of time, effort, and money learning that the hard way.

Patching faster does not change the shape of the pipeline that produces the patch. If regression testing takes a day, you cannot get to a two-hour SLA without skipping it, and the bugs you ship when you skip regression testing tend to be worse than the bugs you were trying to patch. We learned a version of this when we tried letting the model write its own patches and watched a few go out that fixed the original bug while quietly breaking something else the code depended on.

The harder question is what the architecture around the vulnerability should look like. The principle is to make exploitation harder for an attacker even when a bug exists, so that the gap between when a vulnerability is disclosed and when it is patched matters less. That means defenses that sit in front of the application and block the bug from being reached. It means designing the application so that a flaw in one part of the code cannot give an attacker access to other parts. It means being able to roll out a fix to every place the code is running at the same moment, rather than waiting on individual teams to deploy it. 

We also recognize this topic cuts both ways. The same capabilities that helped us find bugs in our own code will, in the wrong hands, accelerate the attack side against every application on the Internet. Cloudflare sits in front of millions of those applications, and the architectural principles described above are exactly the ones our products are built to apply on behalf of customers. We will share more on what that means for customers in the weeks ahead.

If your team is doing similar work and would like to compare notes, reach out to us at security-ai-research@cloudflare.com.

Our research with Mythos Preview was conducted in a controlled environment against our own code; every vulnerability surfaced through this work was triaged, validated, and remediated where action was needed under Cloudflare's formal vulnerability management process.

This work was a team effort. Thanks to Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl, and Rohit Chenna Reddy for their contributions to the research, engineering, and analysis behind this blog post.

In 2025, the enterprise risk landscape experienced a paradigm shift: the adoption of AI and LLMs officially becoming the primary driver of cloud risk. Today, almost 88% of organizations now leverage AI in at least one business function. With this level of integration, the risk of AI is now outpacing traditional security guardrails, culminating in a highly complex and interconnected attack surface.

SentinelOne’s® new AI and Cloud Verified Exploit Paths and Secrets Scanning Report examines this evolving threatscape and draws on telemetry from over 11,000 anonymized customer environments to offer deeper visibility into how threat actors are actively exploiting modern cloud and AI infrastructures.

An Explosion of AI-Specific Secrets and Shadow AI

A primary finding of the 2026 report is the rising proliferation of AI-specific credentials. The data indicates that AI-related secrets — such as OpenAI API Keys, Azure OpenAI API Keys, and others — increased by approximately 140% in a span of one year. This growth correlates directly with the rapid embedding of AI technologies into customer support systems, internal tooling, financial platforms, and product experiences.

Ubiquitous deployment has generated a widespread organizational pattern known as “shadow AI” – the unsanctioned use of AI tools in an environment without formal IT approval or security oversight. In practice, this occurs when developers or internal teams utilize unmanaged or personal LLM keys to process corporate data outside of sanctioned IT or security channels. Since these AI integrations span numerous internal applications, the same API keys are frequently duplicated and stored within code repositories, SaaS configurations, and development scripts. Compounding this, these credentials are often implemented without proper access controls or routine rotation schedules.

The sprawl of these credentials renders them difficult to track via standard secrets management protocols, establishing a requirement for more centralized governance over how AI keys are issued and utilized.

Distinct Risk Vectors of Unmanaged AI Credentials

Unlike traditional cloud credentials that primarily facilitate resource manipulation, the compromise of AI keys introduces unique risk vectors. AI services frequently operate at the intersection of various enterprise systems, including CRM platforms, ticketing systems, and analytics tools, which means a single compromised LLM API key can provide an attacker with broad visibility into diverse datasets. The risks associated are categorized with exposed AI keys into two primary areas:

• Data exposure and leakage: Unauthorized access via AI keys can expose sensitive or proprietary datasets processed by the models, embedded business logic, and internal user prompts and outputs. This enables attackers to harvest sensitive corporate conversations at scale.
• Prompt injection and data poisoning: Unmanaged AI keys allow threat actors to actively manipulate AI models. Through prompt injection, an attacker can influence model behavior to exfiltrate data or bypass established security controls. Additionally, attackers can execute data poisoning by injecting misleading or malicious data into contextual corpora or fine-tuning datasets, which degrades the model’s integrity and reliability over time.

The Broadening Scope of Traditional Cloud Secrets

While AI credentials represent a novel attack surface, the traditional cloud secrets landscape has concurrently grown more complex. In 2025, organizations exposed approximately twice as many types of critical secrets as they did in 2024. This diversification spans AI platforms, cloud providers, SaaS services, and payment processors, pointing to how a single compromise can result in a broader blast radius across revenue-generating systems and infrastructure.

High-privilege cloud provider keys associated with AWS, Azure, and GCP remain the primary anchor of critical risk. The exposure of these keys can facilitate complete account takeover, infrastructure manipulation, and large-scale data exfiltration. As well, the exposure of payment gateway keys, such as those for Stripe and Razorpay, expands the potential damage by putting Personally Identifiable Information (PII) and financial data at risk, enabling the direct abuse of payment workflows.

Repository and CI/CD tokens also introduce supply chain risks, where high-severity credentials like a GITHUB_TOKEN can grant attackers direct access to deployment pipelines and source code, allowing a localized leak to escalate into a systemic infrastructure incident. From a collective standpoint, secrets exposure is exponentially spanning payments, coding, and software development workflows, making risk an interconnected and complex challenge.

Verified Exploit Paths: The Persistence of Legacy Vulnerabilities

To evaluate how these exposed secrets translate into practical risks, the SentinelOne researchers leveraged the Offensive Security Engine (OSE) to generate Verified Exploit Paths. This technology analyzes misconfigurations, vulnerabilities, and exposed secrets in context to determine realistic exploitability.

The telemetry demonstrates that attackers generally do not rely on highly complex, theoretical attack chains. Instead, threat actors consistently exploit recurring entry points, specifically targeting misconfigured external services and widely abused Common Vulnerabilities and Exposures (CVEs). Notably, legacy vulnerabilities remain highly prevalent across customer environments and serve as reliable initial access points. The top verified exploit paths continue to involve older, critical CVEs, including:

• Shellshock (CVE-2014-6271)
• FortiGate SSL VPN credential disclosure (CVE-2018-13379)
• Pulse Secure VPN arbitrary file read (CVE-2019-11510)
• Webmin RCE (CVE-2019-15107)
• Barracuda ESG zero-day backdoor (CVE-2023-1698)

Since these vulnerabilities are public and well-documented, threat actors possess proven techniques and automated tooling to exploit them whenever they persist in production environments. Once initial access is achieved through these legacy vulnerabilities, attackers routinely follow reachable secrets to pivot into additional services, such as utilizing an exposed key found in a cloud bucket to access an AI assistant, and subsequently, the customer data it processes.

Strategic Recommendations for Security Leaders

Addressing the interconnected risks of AI integration and cloud secrets requires a structured, objective approach to security architecture. The report outlines several concrete capabilities and practices including:

• Continuous Surface Monitoring: Organizations must regularly inventory internet-facing assets, databases, and key cloud services, ensuring any configuration changes are immediately reflected in security posture assessments.
• DevSecOps Automation: Security controls must be embedded directly into CI/CD pipelines and developer workflows. Organizations should automate the scanning of exposed secrets and trigger safe remediation actions, such as access revocation or key rotation.
• Governance of AI Credentials: AI keys must be classified and treated as high-value credentials. Organizations should mandate the use of centrally managed AI keys rather than personal credentials, enforce least-privilege access, implement regular rotation schedules, and continuously monitor for shadow AI usage or abnormal access patterns.

Conclusion

As AI systems are increasingly built atop existing cloud, payment, and CI/CD platforms, weaknesses in traditional credentials inevitably become weaknesses in the AI infrastructures that rely upon them. The full report provides complete datasets and comprehensive exploit path models allowing today’s security teams to align their internal security policies with the realities of current threat actor behaviors. Learn more about the objective metrics behind the latest wave of credential exposure and vulnerability exploitation to establish more resilient and fully-controlled infrastructure architectures.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

An exploration of the shift from reactive "assume breach" mentalities to AI-driven prevention, highlighting how Domain-Specific Language Models (DSLMs) empower security architects to eliminate configuration drift and tool sprawl.

The post AI for Security Infrastructure: Rebalancing Cybersecurity for the Decade Ahead  appeared first on Security Boulevard.

NIST Cybersecurity Framework for UK SMEs: A Practical Guide to Identify, Protect, Detect, Respond, and Recover The NIST Cybersecurity Framework is a useful way to organise cybersecurity work around business risk. For UK SMEs, that matters because most teams do not have the time or budget to do everything at once. A framework gives you […]

The post NIST Cybersecurity Framework for UK SMEs: A Practical Guide to Identify, Protect, Detect, Respond, and Recover appeared first on Clear Path Security Ltd.

The post NIST Cybersecurity Framework for UK SMEs: A Practical Guide to Identify, Protect, Detect, Respond, and Recover appeared first on Security Boulevard.

Threat modelling using STRIDE for system architects Threat modelling is one of the most useful habits a system architect can build. Done well, it helps you spot design weaknesses before they become expensive problems to fix. Done badly, it turns into a long list of theoretical threats that nobody uses. STRIDE is a simple way […]

The post Threat modelling using STRIDE for system architects appeared first on Clear Path Security Ltd.

The post Threat modelling using STRIDE for system architects appeared first on Security Boulevard.

Protective security is one of those topics that can sound broader and more complex than it needs to be. For UK SMEs, the practical question is simple: what do you need to protect, how much protection is enough, and how do you make it work without creating unnecessary overhead? Within the NCSC Cyber Assessment Framework, […]

The post Protective Security in the NCSC CAF: A Practical Guide for UK SMEs appeared first on Clear Path Security Ltd.

The post Protective Security in the NCSC CAF: A Practical Guide for UK SMEs appeared first on Security Boulevard.

Cyber risk used to be the kind of problem you could delegate. Something for the CISO, the IT team, and maybe an external auditor to worry about once a year. That comfort zone is gone. In the last decade, a new reality has set in: a single cyber incident can erase hundreds of millions of […]

The post The $700 million question: How cyber risk became a market cap problem first appeared on TrustCloud.

The post The $700 million question: How cyber risk became a market cap problem appeared first on Security Boulevard.

Safe vulnerability disclosure for UK SMEs: a practical guide For many UK SMEs, the idea of someone reporting a security weakness can feel unsettling at first. It may sound technical, formal, or even a little confrontational. In practice, safe vulnerability disclosure is simply a controlled way for people to tell you about a security issue […]

The post Safe vulnerability disclosure for UK SMEs: a practical guide appeared first on Clear Path Security Ltd.

The post Safe vulnerability disclosure for UK SMEs: a practical guide appeared first on Security Boulevard.

Supplier assurance for UK SMEs: a practical guide to checking third parties without overcomplicating it Most UK SMEs rely on suppliers in some way. That might be payroll software, a managed IT provider, a marketing agency, a logistics partner, or a cloud service that holds customer data. The more your business depends on third parties, […]

The post Supplier assurance for UK SMEs: a practical guide to checking third parties without overcomplicating it appeared first on Clear Path Security Ltd.

The post Supplier assurance for UK SMEs: a practical guide to checking third parties without overcomplicating it appeared first on Security Boulevard.

For many UK SMEs, supply chain resilience is not a specialist security project. It is a business continuity issue. If a key supplier cannot deliver, a software provider has an outage, or a partner mishandles data, the impact can show up quickly in customer service, cash flow, and reputation. The good news is that you […]

The post Supply Chain Resilience for UK SMEs: Practical Steps to Reduce Third-Party Risk appeared first on Clear Path Security Ltd.

The post Supply Chain Resilience for UK SMEs: Practical Steps to Reduce Third-Party Risk appeared first on Security Boulevard.

From cybersecurity breaches to natural disasters, disruptive events can occur suddenly and without warning. As a result, it is crucial for organizations to develop resilient plans that not only respond to incidents in real time but also ensure long-term operational survivability. This article examines the concepts of incident response and business continuity, exploring their differences […]

The post Proven incident response and business continuity strategy first appeared on TrustCloud.

The post Proven incident response and business continuity strategy appeared first on Security Boulevard.

 

Cybersecurity Can Learn from the Artemis Launch

The Artemis II mission, bringing humans back to the Moon, had a successful launch today! An amazing cumulation of efforts to manage the mindboggling combination of risks to push a massive rocket into space, in preparation for a trip to orbit the Moon.

Such endeavors come with tremendous risks, which a world-class team works to minimize, but some residual aspects remain and are accepted.

Congratulations to the entire NASA team!

Cybersecurity Can Learn

The cybersecurity industry can learn many lessons from today’s Artemis II achievement.

Having strategic capabilities with clear objectives, resources, and accountability is key:

1. Prediction: Understanding the broad scope of risks, which are likely, and how best to manage them.

2. Prevention: Essential to mitigate the greatest risks that could lead to catastrophe.

3. Detection: Constant monitoring to identify problems as they arise and give the best opportunities to react in a timely manner.

4. Response: Well-rehearsed actions that intercept problems to minimize overall impact.

Lessons from each area create a feedback loop into the process, to make it stronger and more adaptive over time.

Establish and maintain an enduring cybersecurity strategy. Don’t rely on disconnected tactical efforts, as they will underperform over time.

If you need advisement, assistance is out there, reach out to industry leaders.

The post Cybersecurity Can Learn from the Artemis Launch appeared first on Security Boulevard.