Healthcare technology giant CareCloud has confirmed that a data breach earlier this year impacted more than 3.75 million people, making it one of the largest healthcare data incidents disclosed this year.
The New Jersey-based company, which provides electronic health record (EHR) and practice management services, first flagged the intrusion in an SEC filing back in March, but the true scope only became clear this month when the Department of Health and Human Services (HHS) breach tracker updated the affected total from roughly 345,000 to 3,756,469 individuals.
CareCloud says an unauthorized third party accessed one of its Amazon Web Services (AWS) environments between March 10 and March 16, 2026. The intrusion caused an eight-hour disruption to one of the company’s six EHR environments before systems were restored that same evening. During a forensic investigation, CareCloud determined that the attacker claimed to have exfiltrated data from databases within that environment.
The stolen data reportedly includes both identity and medical information:
Full names, postal addresses, and dates of birth
Social Security numbers (SSNs) and driver’s license or passport numbers
Medical records and health insurance information
Bank account and financial details, plus full credit card data (including CVV) for a limited subset of victims
What affected customers should do
Anyone receiving a breach notification letter should take it seriously, given the combination of medical, identity, and financial data involved.
If you think you’ve been affected by a data breach, here are steps you can take to protect yourself:
Check the company’s advice. Every breach is different, so check with the company to find out what’s happened and follow any specific advice it offers.
Change your password. You can make a stolen password useless to thieves by changing it. Choose a strong password that you don’t use for anything else. Better yet, let a password manager choose one for you.
Enable two-factor authentication (2FA). If you can, use a FIDO2-compliant hardware key, laptop, or phone as your second factor. Some forms of 2FA can be phished just as easily as a password, but 2FA that relies on a FIDO2 device can’t be phished.
Watch out for impersonators. Cybercriminals may contact you posing as the breached company. Check its official website to see if it’s contacting victims, and verify the identity of anyone who contacts you using a different communication channel.
Take your time. Phishing attacks often impersonate people or brands you know and use themes that require urgent attention, such as missed deliveries, account suspensions, and security alerts.
Consider not storing your card details. It’s definitely more convenient to let sites remember your card details, but it increases the risk if a company suffers a breach.
The UK Home Office has once again demanded Apple allows it access to encrypted iCloud data.
The Guardian reports that the Home Office issued a Technical Capability Notice to Apple, this time targeting only British users. A Technical Capability Notice is a formal government order that compels tech and telecommunications companies to build or maintain specific technical functions—such as intercepting data or removing encryption protections—so law enforcement can access communications.
In the last round of this ongoing battle, the UK secretly ordered Apple to provide blanket access to protected iCloud backups around the world. Advanced Data Protection (ADP) is Apple’s opt‑in end‑to‑end encryption for iCloud backups, which even Apple itself cannot read. Apple argued that weakening or removing ADP would expose users to data breaches and other threats, and instead chose in January 2025 to withdraw ADP for UK customers rather than build a backdoor, while leaving it available elsewhere.
So, instead of working to keep citizens safe and secure, the Home Office just ended up removing an option for them.
Apple has responded by lodging a complaint with the Investigatory Powers Tribunal (IPT), seeking to challenge the scope and lawfulness of the government’s powers to issue such notices under the Investigatory Powers Act. The Tribunal is an independent court that has the power to investigate claims that the UK intelligence services have acted unlawfully.
Privacy International and Liberty have parallel complaints at the IPT challenging Technical Capability Notices more broadly, including their secrecy and necessity, and have asked for Apple’s claim to be heard in public given its wide public-interest implications.
I feel the fear of leaving an intentional backdoor is justified. If it exists, there is a chance that (AI-assisted) criminals will find and exploit it.
Weighing the importance of the right to privacy and the ability to investigate cases including terrorism and child sexual abuse is not easy. Apple’s ADP is used by many and as soon as criminals would know it’s no longer safe for them to use, they’d move to other platforms. Platforms where no legislative power will be able to gain access.
But, given the danger of a backdoor becoming available for criminals, we think in this case privacy should prevail. Let us know how you feel in the comments.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
Explore how passkey implementation gaps undermine security when relying parties fail to validate the User Verified flag, reducing MFA to a single factor.
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:
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.
Expose the AI & Cloud Secrets That Put Your Data & Systems at Risk
This report draws on 11K+ customer environments. It shows how AI and cloud adoption are increasing secrets exposure and putting data at risk.
Notes the April 2026 Dark Web Breach Incident Trend Report is compiled from data breach cases posted on the deep web and dark web forums. some information is included in cases where it is difficult to fully verify the factuality of the information due to the nature of the source. Major Issues data breaches and […]
In 2026, the question for security leaders is not whether a supply chain attack is coming. Every serious organization should assume it is. The question is whether their defense architecture can stop a payload it has never seen before. It’s a question that takes on even more critical implications at a time where trusted agentic automation increasingly becomes the norm.
In three weeks this spring, three threat actors each ran a tier-1 supply chain attack against widely deployed software: LiteLLM, a core AI infrastructure package, Axios, the most downloaded HTTP client in the JavaScript ecosystem, and CPU-Z, a trusted system diagnostic tool. Different vectors, different actors, different techniques. SentinelOne® stopped all three on the same day each attack launched, with no prior knowledge of any payload.
The more important story is the how. Each attack arrived as a zero-day at the moment of execution. Each exploited a trusted delivery channel: an AI coding agent running with unrestricted permissions, a phantom dependency staged eighteen hours before detonation, a properly signed binary from an official vendor domain. No signature existed for any of them. No IOA matched.
SentinelOne stopped all three. That outcome is a direct answer to the question every security leader is now running against: What does your defense do when the attack arrives through a channel you explicitly trust, carrying a payload you have never seen before?
The AI Arms Race in Security is Underway
Adversaries are no longer running manual campaigns at human speed. In September 2025, Anthropic disclosed a Chinese state-sponsored group that jailbroke an AI coding assistant and ran a full espionage campaign against approximately 30 organizations. The AI handled 80–90% of tactical operations autonomously (i.e., reconnaissance, vulnerability discovery, exploit development, credential harvesting, lateral movement, exfiltration) with minimal human direction. Anthropic noted only 4–6 human decision points per campaign. The attack achieved limited success across those targets, but the trajectory is clear: AI is compressing the human bottleneck in offensive operations. Security programs designed around manual-speed adversaries are calibrating to a threat that is moving faster.
The LiteLLM attack is the clearest recent example of what this looks like inside an AI development workflow. On March 24, 2026, threat actor TeamPCP compromised the LiteLLM Python package by obtaining PyPI credentials through a prior supply chain compromise of Trivy, a widely-used open-source security scanner. Two malicious versions (1.82.7 and 1.82.8) were published. Any system with those versions during the exposure window executed the embedded credential theft payload automatically. In one confirmed detection, an AI coding agent running with unrestricted permissions (claude --dangerously-skip-permissions) auto-updated to the infected version without human review — no approval, no alert, no visible action before the payload ran. SentinelOne detected and blocked the malicious Python execution on the same day across multiple environments. Most organizations running AI development workflows didn’t know they were exposed until after the fact. The gap where human review processes don’t reach is wide, and it grows with every AI agent added to a pipeline.
Security programs were built for a different adversary. Vulnerability management, triage queues, patch cadences: all of it assumes an attacker who moves at a pace where human response can still close the window. This year’s SentinelOne Annual Threat Report documented what happens when that assumption breaks: adversaries are shifting left, embedding malicious logic in the build process before software ever reaches production. Likewise, the Verizon 2025 Data Breach Investigations Report found that edge device vulnerabilities are now being mass-exploited at or before the day of CVE publication, while organizations take a median of 32 days to patch them. The old model worked when it was designed. Attackers just weren’t running AI yet.
Three Attacks, One Common Failure Mode
Each attack ran through the same gap. Authorization was treated as a sufficient security boundary, and when authorization is automated, that assumption has no floor.
An AI agent with install permissions doesn’t stop to ask whether a package looks right. It installs. Trusted source, valid credentials, done. Supply chain attacks have always exploited trusted delivery channels, but a human at the keyboard introduces at least one friction point: Someone might notice something off, slow down, ask a question. Agents don’t do that. They execute at the speed of the next API call. When you give an agent install permissions, you’ve extended your trust model to cover everything it will ever run. Authorized agents execute exactly what their permissions allow. That’s the design. Treating permission as a proxy for safety is what turns a compromised supply chain hypersonic.
LiteLLM was compromised via credentials stolen through Trivy, a security scanner. The Axios attacker bypassed every npm security control the project had in place by exploiting a legacy access token the maintainers had forgotten to revoke. The CPUID attackers went after the vendor’s distribution infrastructure directly, so anyone who downloaded from the official website got a properly signed binary with a payload inside. In all three cases, the identity was legitimate. The intent wasn’t.
SentinelOne’s Annual Threat Report named the failure precisely: “The identity is verified, but the intent has been subverted, rendering traditional access controls ineffective against the resulting supply chain contamination.” Signature libraries, IOA rule sets, reputation lookups: All of them check authorization. None check intent. These attacks were designed to exploit exactly that. When the authorization model runs automatically, so does the exposure.
What Actually Stopped Them
In each incident, SentinelOne’s on-device behavioral AI flagged the execution pattern, not a known signature or hash for that specific attack.
The LiteLLM detection flagged a Python interpreter executing Base64-decoded code in a spawned subprocess. SentinelOne killed the process preemptively, terminating 424 related events in under 44 seconds, before any human was in a position to observe it. The Axios detection, via the Lunar behavioral engine, caught PowerShell executing under a renamed binary from a non-standard path. The engine flagged the technique regardless of what the payload contained. The first infection occurred 89 seconds after the malicious package went live; the behavioral detection fired on the same day of publication. The CPU-Z detection flagged cpuz_x64.exe building an anomalous process chain: spawning PowerShell, which spawned csc.exe, which spawned cvtres.exe. CPU-Z does not do that. The platform terminated the execution chain mid-attack during a 19-hour active distribution window.
This is the operational output of Autonomous Security Intelligence (ASI), the intelligence fabric built into the Singularity Platform. ASI runs on-device at the edge as part of the core architecture. It is already running when the attack starts, killing the process before the threat can escalate.
Where customers had SentinelOne fully deployed with the right policies enabled, they were covered. Where they did not, they were exposed, and with average ransomware recovery costs exceeding $4M per incident, that exposure has a real price. If you are not certain your deployment matches the configuration that stopped these three attacks, that certainty is worth getting.
AI to Fight AI
This is the product reality behind the thesis SentinelOne brought to RSAC: AI to fight AI. A machine-speed adversary requires a machine-speed defense. That is an architectural requirement, not a positioning statement. ASI monitors behavioral patterns at the point of execution and kills the process when something deviates, at machine speed, without waiting for a human to write a query or approve a kill.
According to an IDC study, organizations using SentinelOne’s AI platform identify threats 63% faster and remediate 55% faster than legacy solutions, neutralizing 99% of threats without a single manual step. For organizations in regulated industries (healthcare, financial services, manufacturing, critical infrastructure), the stakes compound beyond breach cost. An exposure window that stays open through manual investigation is a potential regulatory notification event, an audit finding, and a conversation the CISO has with the board under circumstances no one wants. The difference between a stopped attack and an active breach is whether the architecture acts before the attacker establishes persistence. By the time a human analyst approves the kill, redundant persistence mechanisms may already be installed. The CPU-Z attack deployed three of them specifically because partial cleanup leaves the payload operational.
Human-driven workflows, manual validation, and legacy tooling cannot keep pace with that attack cadence. When defense relies on investigation before action, the advantage shifts to the adversary. The gap is in the architecture. You cannot tune your way out of it.
Conclusion | The Only Question That Matters
SentinelOne’s latest Annual Threat Report documented the pattern these three attacks confirm: Adversaries are “shifting left” by integrating malicious logic into the build process itself, compromising software before it reaches production. It is the current operating model of advanced threat actors, and it is accelerating.
Three attacks. Three detections. Three outcomes, all in a matter of weeks. The architecture that survived them is real-time, AI-native, and built into the edge.
The question every security leader should be able to answer: Could your current solution have stopped LiteLLM, Axios, and CPU-Z autonomously, on the day of each attack, with no prior knowledge of any payload?
If the answer depends on a signature update, a cloud verdict, a manual investigation step, or a policy that wasn’t enabled, that is your answer.
Read the full technical breakdown of each incident:
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.
Unit 42 reveals how multi-agent AI systems can autonomously attack cloud environments. Learn critical insights and vital lessons for proactive security.
As organizations rush to adopt AI, they are discovering that traditional, siloed security tools cannot keep pace. The data is too vast, the infrastructure is too interconnected, and runtime environments are too dynamic. Security leaders are confronting a hard reality: AI cannot be secured with point solutions — it is just too broad.
To scale AI with confidence, enterprises must move beyond check-the-box controls and adopt a holistic, machine-speed defense that secures the entire AI lifecycle. This means protecting the data that fuels and is accessed by models, the cloud infrastructure that runs them, and the workloads and AI systems operating at runtime as a single, unified, and immutable system.
As AI capabilities accelerate, a critical question is emerging in the market: Does AI reduce the need for cybersecurity, or fundamentally increase it?
The answer is clear. With current infrastructure architectures, AI is not a replacement for security. It is a multiplier for risk. Models ingest massive volumes of data and agents can sprawl uncontrollably. It depends on complex cloud infrastructure and operates continuously at machine speed. Each stage of the AI lifecycle introduces new attack paths and new failure modes.
Today, SentinelOne is announcing the expansion of its AI Security platform with new Data Security Posture Management (DSPM) capabilities, model red teaming, validation and guardrails (by Prompt Security), MCP Security (by Prompt Security), AI-SPM, AI Workload Protection, and AI end user protection. This milestone advances our broader vision, delivering a unified platform that secures AI end to end, from data accessed, all through runtime execution and model input and output. This is complete security, visibility, and governance over Al usage throughout its entire lifecycle.
The Foundation: Securing AI at the Data Layer
AI security starts with data, not because data is abundant, but because mistakes made at this stage are irreversible. AI models also don’t just process the data they ingest, they memorize it. If sensitive PII, credentials, or proprietary information enter a training pipeline, that data can become baked into a model’s weights, creating a permanent security liability that is nearly impossible to remediate later.
This risk is amplified by scale. Industry projections estimate that the global datasphere, the unstructured data stored in cloud object stores and increasingly fed into AI pipelines, will reach 10.5 zettabytes by 2028. This data is not just storage. It is the fuel that trains, fine-tunes, and powers AI systems. This is why data security is the first mile of AI security.
With the introduction of these new DSPM capabilities, SentinelOne enables organizations to establish a “safe-to-train” gate before data ever reaches an AI pipeline. These capabilities provide deep visibility into cloud-native databases and object stores, allowing teams to discover unmanaged or forgotten data sources, classify sensitive information with policy-driven precision, and prevent high-risk data from being used in training or inference workflows.
Singularity Cloud Security’s integrated DSPM discovers cloud object stores and databases and classifies sensitive data that could find its way into AI training pipelines.
However, visibility alone is not enough. AI pipelines ingest data at massive scale, making them an attractive vehicle for malware delivery and pipeline poisoning. In addition to identifying and redacting sensitive data, SentinelOne actively scans cloud storage at machine speed to prevent malicious content from ever reaching AI models or applications. By securing data at ingestion all before training begins, organizations eliminate entire classes of AI risk that cannot be fixed downstream. This is the foundation for trusted AI adoption.
The Infrastructure Layer: Securing the Systems That Run AI
Securing AI data is necessary, but it is not sufficient. Data does not exist in isolation. Rather, it lives on cloud infrastructure and in AI environments where infrastructure becomes a critical failure point.
AI workloads introduce a uniquely high-risk combination of high-value data, high-privilege access, and high-performance compute. AI factories, training clusters, managed AI services, and inference endpoints often require broad permissions and continuous access to cloud object stores. Without strong infrastructure controls, attackers can pivot from exposed data into model logic, model weights, or downstream applications. This is where cloud infrastructure security becomes inseparable from AI security.
Traditional Cloud Security Posture Management (CSPM) provides essential hygiene across the cloud estate by identifying misconfigurations, excessive permissions, and policy drift. In AI environments, however, security teams also need visibility and control that is specific to how models are built, deployed, and accessed.
AI-Security Posture Management (AI-SPM) extends infrastructure security directly into the AI layer. By treating AI systems as first-class assets, AI-SPM provides a unified inventory of training jobs, development notebooks, managed AI services, and inference endpoints across the environment.
Together, CSPM and AI-SPM allow security teams to understand how data, infrastructure, and AI systems are connected. They can trace attack paths from misconfigured storage to over-privileged training containers, detect unmanaged AI assets, and prevent adversaries from moving laterally from the cloud foundation into model logic. This infrastructure layer is what connects secure data to secure runtime and it is essential for protecting AI at scale.
Singularity Cloud Security measures compliance posture over time against multiple global AI regulations including the EU AI Act.
The Runtime Layer: Protecting AI In Production
AI security cannot stop when a model finishes training. The moment AI systems move into production, they begin interacting with real users, real data, and real business processes, making runtime protection a critical part of the AI security lifecycle.
At runtime, AI workloads operate continuously and at machine speed. Models and agents execute inside cloud workloads that must be protected against exploitation, unauthorized access, and lateral movement. Any compromise at this stage can immediately impact business operations, data integrity, and customer trust.
This is where runtime workload protection becomes essential. Cloud Workload Protection Platforms (CWPP) provide real-time visibility and enforcement across the compute environments running AI models, ensuring that workloads are monitored, hardened, and protected without degrading the performance required for high-velocity inference.
By extending protection into runtime, security teams ensure that AI systems remain secure not only during development and deployment, but throughout their operational life. This completes the AI security lifecycle from data ingestion, through infrastructure, to production execution.
Prompt Security and AI Red-Teaming: Continuously Validating Trust
Securing AI at runtime goes beyond protecting the workloads that execute models. It also requires validating how models behave when they are used (and misused) in the real world.
Prompts are the primary interface to AI systems and they represent a powerful new attack surface. Malicious or malformed prompts can be used to bypass controls, extract sensitive information, manipulate model behavior, or trigger unintended actions in downstream systems. These risks cannot be addressed solely through static controls or one-time reviews. This is where prompt security and AI red-teaming become essential.
By continuously testing AI systems with adversarial prompts and simulated attacks, organizations can identify behavioral weaknesses before they are exploited in production. AI red-teaming helps validate that models behave as intended under real-world conditions, exposing prompt-level vulnerabilities, unsafe outputs, and policy bypasses that would otherwise go undetected.
When combined with runtime protection, this approach ensures that AI systems are not only secure in how they are built and deployed, but also resilient in how they respond — even as models evolve, prompts change, and new attack techniques emerge.
This continuous validation loop is critical for maintaining trust in production AI systems and closing the final gap in the AI security lifecycle.
A Unified Fabric for AI Security
The transition to AI is ultimately a trust shift. Organizations will only move AI from experimentation to production if they can trust the data that trains models, the infrastructure that runs them, and the systems that govern how AI operates at runtime. Securing AI therefore cannot be fragmented. It requires a unified platform that treats data, infrastructure, and runtime as a single, connected system with shared context and continuous visibility across the entire AI lifecycle.
By integrating data security, cloud infrastructure posture management, AI-specific posture management, and runtime workload protection, SentinelOne delivers end-to-end AI security from data ingestion through runtime execution. This approach does more than reduce risk. It enables velocity. When security is built into the foundation, organizations can deploy AI faster, meet evolving regulatory requirements more easily, and innovate with confidence.
Secure the data.
Secure the infrastructure.
Secure the runtime.
This is how AI moves from risk to real-world impact. Contact us or book a demo to see how SentinelOne secures AI end to end — from data ingestion to runtime execution.
The rising influence of artificial intelligence (AI) has many organizations scrambling to address the new cybersecurity and data privacy concerns created by the technology, especially as AI is used in cloud systems. Apple addresses AI’s security and privacy issues head-on with its Private Cloud Compute (PCC) system.
Apple seems to have solved the problem of offering cloud services without undermining user privacy or adding additional layers of insecurity. It had to do so, as Apple needed to create a cloud infrastructure on which to run generative AI (genAI) models that need more processing power than its devices could supply while also protecting user privacy, stated a ComputerWorld article.
Apple is opening the PCC system to security researchers to “learn more about PCC and perform their own independent verification of our claims,” the company announced. In addition, Apple is also expanding its Apple Security Bounty.
What does this mean for AI security going forward? Security Intelligence spoke with Ruben Boonen, CNE Capability Development Lead at IBM, to learn what researchers think about PCC and Apple’s approach.
SI: ComputerWorld reported this story, saying that Apple hopes that “the energy of the entire infosec community will combine to help build a moat to protect the future of AI.” What do you think of this move?
Boonen: I read the ComputerWorld article and reviewed Apple’s own statements about their private cloud. I think what Apple has done here is good. I think it goes beyond what other cloud providers do because Apple is providing an insight into some of the internal components they use and are basically telling the security community, you can have a look at this and see if it is secure or not.
Also good from the perspective that AI is constantly getting bigger as an industry. Bringing generative AI components into regular consumer devices and getting people to trust their data with AI services is a really good step.
SI: What do you see as the pros of Apple’s approach to securing AI in the cloud?
Boonen: Other cloud providers do provide high-security guarantees for data that’s stored on their cloud. Many businesses, including IBM, trust their corporate data to these cloud providers. But a lot of times, the processes to secure data aren’t visible to their customers; they don’t explain exactly what they do. The biggest difference here is that Apple is providing this transparent environment for users to test that plane.
Boonen: Currently, the most capable AI models are very big, and that makes them very useful. But when we want AI on consumer devices, there’s a tendency for vendors to ship small models that can’t answer all questions, so it relies on the larger models in the cloud. That comes with additional risk. But I think it is inevitable that the whole industry will be moving to that cloud model for AI. Apple is implementing this now because they want to give consumers trust to the AI process.
SI: Apple’s system doesn’t play well with other systems and products. How will Apple’s efforts to secure AI in the cloud benefit other systems?
Boonen: They are providing a design template that other providers like Microsoft, Google and Amazon can then replicate. I think it is mostly effective as an example for other providers to say maybe we should implement something similar and provide similar testing capabilities for our customers. So I don’t think this directly impacts other providers except to push them to be more transparent in their processes.
It’s also important to mention Apple’s Bug Bounty as they invite researchers in to look at their system. Apple has a history of not doing very well with security, and there have been cases in the past where they’ve refused to pay out bounties for issues found by the security community. So I’m not sure they’re doing this entirely out of the interest of attracting researchers, but also in part of convincing their customers that they are doing things securely.
That being said, having read their design documentation, which is extensive, I think they’re doing a pretty good job in addressing security around AI in the cloud.
Entrar
to generate Verified Exploit Paths
