Quand les risques liés à la sécurité de l'IA deviennent réalité

Key Takeaways

• Cloud security protection is essential to safeguard sensitive data in dynamic cloud environments.
• Effective protection combines data discovery, risk assessment, and continuous monitoring to prevent breaches.
• Compliance with industry standards like GDPR and HIPAA is critical for secure cloud adoption.
• Leveraging automation enhances security posture while reducing manual errors.
• Staying informed with latest cloud security trends empowers proactive defense against evolving threats.

Not long ago, AI security risks were treated as theoretical - scenarios raised by researchers asking, “what if?” Today, those what-ifs are headlines.

An AI chatbot leaks a million conversations.

A coding agent deletes a production database.

An enterprise assistant summarizes confidential emails - bypassing every DLP control in place.

This is no longer experimentation. It is production reality.

In this blog, we examine how these events map directly to the OWASP Top 10 for LLM Applications - the framework designed to categorize the most critical risks in AI systems.

More importantly, we show how these risks moved from theory to practice, and what that means for organizations adopting AI today. Because secure AI adoption requires more than powerful models or automation - it requires understanding how data exposure, privilege, and system design interact in ways traditional security controls were never built to handle.

What is OWASP and OWASP Top 10 Model for LLM Apps?

OWASP (Open Worldwide Application Security Project) is a global nonprofit community best known for advancing software security through open frameworks like the OWASP Top 10 for web applications. As AI systems became embedded in production environments, OWASP expanded into AI security with initiatives such as the OWASP AI Exchange, OWASP GenAI Security Project and the Machine Learning Security Top 10. One of its most impactful efforts is the OWASP Top 10 for LLM Applications (2025 edition).

The OWASP Top 10 for LLM Applications (2025) identifies the most critical security risks facing applications built on large language models, including prompt injection, insecure output handling, sensitive data exposure, supply chain risks, excessive agent permissions, training data poisoning, model denial of service, and insecure plugin integrations. 

It provides a practical framework for building secure LLM-powered systems while emphasizing guardrails, least privilege, input/output validation, monitoring, and supply-chain awareness. In essence, it adapts traditional application security principles to the unique risks introduced by AI-driven systems.

From Theoretical Attack Scenarios to Real-World Incidents

The OWASP Top 10 for LLM Applications framework includes detailed explanations, attack scenarios, and references. It is an insightful and well-grounded resource, informed by real-world patterns - though many of the exploitation examples originate from controlled research demonstrations. In addition, the 2025 OWASP top 10 was released in November 2024 which in AI terms is practically 2024 BC. 

In this section, we shift the focus to actual updated incidents that occurred in real organizational and public contexts. These cases share a common theme: adopting AI without data-aware security controls is not a calculated risk - it is a significant and dangerous blind spot.

We illustrate to her a gap between how AI systems access data and how organizations protect it. In real-world context DLP, CASB, and IAM were not built for a world where an AI assistant can sometimes access servers with root level privileges, or reads every email in your organization, or where employees paste trade secrets into chatbots, or where a single injected prompt triggers data theft.

Prompt Injection (OWASP LLM01)

Attackers manipulate AI systems by injecting malicious instructions directly through user inputs or indirectly through content the AI processes. LLMs cannot distinguish trusted instructions from untrusted data.

Case Studies from the Wild

In a real-world security incident, an AI-powered coding assistant used internally at Amazon was abused by threat actors to insert malicious prompt injection. Attackers crafted malicious inputs designed to manipulate an AI-powered coding assistant into generating harmful code. By embedding deceptive instructions within otherwise legitimate-looking content, they caused the agent to produce and submit a pull request that included data-wiping commands in a cloud configuration file. The model followed the injected instructions as if they were valid development guidance, demonstrating how LLMs can be steered into unintended behavior when they cannot reliably distinguish trusted instructions from adversarial ones.

Because the coding agent had broad write access and limited guardrails, the injected prompt translated directly into actionable, potentially destructive changes. This incident illustrates the core danger of prompt injection: when AI systems are granted operational privileges, malicious input can become executed output. Without strict input validation, scoped permissions, and mandatory human review, prompt injection can transform a simple text manipulation attack into real-world impact, including data loss and infrastructure disruption.

In March 2026, in the Ambient Code Platform attack described by StepSecurity, researchers demonstrated how attackers could attempt to manipulate AI-powered coding assistants through prompt injection embedded directly in repository files. By placing malicious instructions inside a configuration file (CLAUDE.md) that an AI reviewer reads as trusted project context, the attacker tried to trick the AI agent into approving and committing unauthorized changes to the repository. 

The goal was to turn the AI assistant itself into the mechanism for introducing malicious code.

Although the attack ultimately failed, this is yet another reminder how a prompt injection along the pipeline can pose a serious threat. When AI coding agents are integrated into CI/CD pipelines with repository permissions, poisoned context files or documentation can potentially influence automated code reviews and commits, effectively turning prompt injection into a new software supply-chain attack vector.

In February 2026, Microsoft researchers described a technique called AI recommendation poisoning, where attackers manipulate AI assistants by injecting hidden instructions into their memory to bias future responses. Through mechanisms like embedded prompts in web content or AI summary features, adversaries can cause an AI system to treat certain sources, brands, or claims as trustworthy, influencing later recommendations without the user’s awareness. Microsoft observed dozens of real-world cases across multiple industries, showing that this is an active and growing tactic rather than a theoretical risk. The research highlights how AI systems that store context or memory can be persistently influenced, turning subtle prompt manipulation into long-term control over recommendations and decision support.

Prompt injection highlights a fundamental weakness in LLM-based systems: they cannot reliably distinguish trusted instructions from malicious input. When attackers embed hidden or deceptive commands into content the model processes, those instructions can influence outputs and, in integrated systems, trigger real actions. As AI systems gain access to tools, data, memory, and operational workflows, prompt injection evolves from a simple text manipulation issue into a tangible security risk with real-world impact.

Sensitive Information Disclosure (OWASP LLM02)

While AI systems often require credentials to connect to other environments and basically function, the real sensitive information exposure lies within what the users feed the LLM model. Often it includes Private Identifiable Information (PII), credentials, proprietary data, and internal communications through their outputs. This can be found in model memorization, misconfigured infrastructure, or overly broad access to enterprise data.

Case Studies from the Wild

A series of real-life case studies show how sensitive information can easily leak from popular applications that are used on a wide scale by millions.

In January 2025, Wiz Research discovered a completely unauthenticated ClickHouse database belonging to DeepSeek. It contained over one million log streams: user chat histories, API keys, cryptographic secrets, and internal system metadata. Researchers gained full database control with zero authentication.

That same year, a dataset of leaked ChatGPT conversations showed the other side of the problem. Users routinely shared full names, phone numbers, resumes, medical conditions, legal disputes, and suicidal thoughts with AI chatbots. People treat ChatGPT as therapist, lawyer, and confidant. Thus, creating what one researcher called "history's most thorough record of enterprise secrets”. 

The story below illustrates how real people are impacted from such or similar exposure scenario, emphasizing how LLM can sometimes serve as a double-edged sword.

It is not just LLM chat apps. A bug in Microsoft 365 Copilot caused it to summarize confidential emails from users' Sent Items and Drafts folders - even when sensitivity labels and DLP policies explicitly prohibited it. An AI assistant that can read your most sensitive emails and a misconfiguration that exposes a million conversations - traditional data breaches look small by comparison.

Sensitive Information Disclosure underscores how LLM systems can unintentionally expose highly sensitive data. Not only through infrastructure misconfigurations, but through the vast amount of confidential information users willingly provide. From PII and credentials to proprietary communications, AI systems often aggregate and process data at a scale that amplifies the impact of any leak. Without strict data governance, access controls, and minimization practices, LLMs can become powerful amplifiers of privacy and security risk rather than productivity tools.

Supply Chain (LLM03)

These security risks are introduced through third-party components that LLM systems depend on, including external models, open-source libraries, plugins, embeddings, datasets, APIs, and hosted AI services. Because modern AI applications are rarely built from scratch, weaknesses in any upstream dependency can compromise the entire system. 

In the beginning of 2026 we learned about Openclaw and soon after its security implications. AI supply chain was one of these implications.

According to research by Trend Micro, attackers abused the OpenClaw AI agent ecosystem by weaponizing publicly shared “skills” to distribute Atomic macOS Stealer (AMOS), a well-known macOS information-stealing malware. The malicious skills appeared legitimate but were designed to fetch and execute payloads that installed the stealer on victims’ systems. By leveraging the trust model of AI agent marketplaces and skill repositories, threat actors turned the platform into a distribution channel, effectively creating an AI-driven supply-chain attack. 

According to research by Trend Micro, attackers abused the OpenClaw AI agent ecosystem by weaponizing publicly shared “skills” to distribute Atomic macOS Stealer (AMOS), a well-known macOS information-stealing malware. The malicious skills appeared legitimate but were designed to fetch and execute payloads that installed the stealer on victims’ systems. By leveraging the trust model of AI agent marketplaces and skill repositories, threat actors turned the platform into a distribution channel, effectively creating an AI-driven supply-chain attack. The incident highlights how autonomous agents that can import and execute third-party skills introduce new risks: if a skill is malicious or compromised, it can deliver malware, steal credentials, or access sensitive data without obvious warning.

Academic research that was published in February 2026, explored “Malicious Agent Skills in the Wild”. It presents a large-scale empirical analysis of how AI agent skills (third-party plugins or modules that extend an LLM agent’s capabilities) are weaponized in the real world. The researchers found many skill files that go beyond simple functionality, actually exploiting AI platform hook systems and permission flags to perform actions unintended by developers. Some of these malicious or vulnerable skills enabled advanced behaviors like bypassing guardrails, accessing sensitive resources, or performing unauthorized operations. 

The researchers evaluated 98,380 third-party agent skills collected from two community registries. Out of these, they confirmed 157 skills as malicious through behavioral verification. 

Those malicious skills contained a total of 632 distinct attack scenarios including:

• Accessing files the skill shouldn’t read
• Sending sensitive data to an external server
• Executing commands outside its intended scope
• Bypassing built-in safety controls
• Escalating privileges inside the AI system

Interestingly, a single threat actor was responsible for 54.1 % of the confirmed malicious skills via templated impersonation campaigns. Illustrating that threat intelligence practices (existing in other security domains) are not yet applied in AI domains.

The authors responsibly disclosed these issues, leading to the removal of most problematic skills within about 30 days, and released their dataset and analysis tools to help future security research on agent ecosystems. 

This is a concrete example of supply-chain-style risk with LLM systems: reusable components published in open marketplaces or repositories were found to contain hidden, harmful behavior that could compromise applications or infrastructure that integrated them. 

‍

Data and Model Poisoning (LLM04) 

Attackers corrupt AI models by injecting malicious data into training sets, fine-tuning pipelines, or runtime memory. Inside the malicious content, they are embedding backdoors, biases, or false information that persist across all future interactions.

Case Studies from the Wild

Attackers corrupt AI systems by injecting malicious or misleading data into training sets, fine-tuning pipelines, retrieval sources, or runtime memory. The poisoned content may embed backdoors, persistent biases, false facts, or hidden triggers that influence future outputs. Because LLMs generalize from the data they ingest, even small volumes of strategically crafted content can create disproportionate downstream effects.

In December 2025, the European Parliament published research about “Information manipulation in the age of generative artificial intelligence”, providing ample examples about LLM data manipulation and data poisoning in many domains.

One significant issue that resurfaces occasionally, is the Pravda network. In April 2025, the Atlantic Council’s investigation showed that a pro-Kremlin disinformation network known as the Pravda network has been systematically seeding misleading content across the internet (including on Wikipedia and in material that trains large language models) to shape global perceptions in Russia’s favor. By creating a vast array of seemingly authoritative pages and articles, the network amplifies Kremlin narratives about the war in Ukraine and other geopolitical issues, which can then be absorbed by AI chatbots and present pro-Russian, anti-Western messaging to users. This strategy of “poisoning” AI tools raises concerns about the transparency of AI training data and the ability of models to produce unbiased, fact-based responses.

En octobre 2025, une étude menée par Anthropic, l'UK AI Security Institute et The Alan Turing Institute a révélé qu'il suffit de 250 documents conçus à cet effet pour empoisonner n'importe quel grand modèle de langage, quelle que soit sa taille. Le succès dépend du nombre absolu de documents empoisonnés, et non de leur pourcentage dans le jeu de données d'entraînement. Cela a renversé l'hypothèse selon laquelle l'empoisonnement de grands modèles nécessiterait de contrôler une part importante de leurs données.

En février 2026, le journaliste de la BBC Thomas Germain a prouvé la facilité avec laquelle cela peut être réalisé en pratique. Il a publié un article inventé sur son site personnel concernant « les meilleurs journalistes tech dans le domaine du concours de mangeurs de hot-dogs », agrémenté d'un classement fictif. Les principaux modèles d'IA ont ingéré cette information et ont commencé à la présenter comme un fait. N'importe qui possédant un site web peut empoisonner les données d'entraînement d'une IA.

Dans l'exemple ci-dessous, vous pouvez observer un scénario réel d'empoisonnement de données dans DeepSeek. L'utilisateur, de bonne foi, a téléchargé une application mobile basée sur un résultat d'IA, mais celle-ci était empoisonnée et le résultat recommandait un logiciel malveillant mobile.

L'empoisonnement des données et des modèles désigne la manipulation délibérée des informations à partir desquelles les systèmes d'IA apprennent ou qu'ils récupèrent, en y intégrant des portes dérobées, des biais ou de faux récits qui persistent dans les résultats futurs. Étant donné que les LLM généralisent à partir de leurs sources de données, même de petites quantités de contenu stratégiquement élaboré peuvent influencer leur comportement de manière disproportionnée. Cela fait de l'empoisonnement non seulement un risque technique, mais une menace systémique pour la confiance, l'intégrité et la prise de décision au sein des systèmes pilotés par l'IA.

Excès d'autonomie (OWASP LLM06) 

Les agents d'IA d'aujourd'hui ne sont plus de simples chatbots répondant à des questions.

Dans de nombreux cas, il s'agit d'un écosystème complet connecté aux systèmes sensibles de l'organisation : 

• Bases de données
• API internes
• Systèmes de stockage de fichiers
• Dossiers clients
• Base de connaissances organisationnelle
• Et même l'infrastructure cloud

Cela signifie qu'ils ne se contentent pas de générer du texte ; ils peuvent exécuter des actions et sont exposés à des informations hautement sensibles. Lorsque tout fonctionne comme prévu, cette automatisation peut être puissante et stimuler les entreprises. Mais lorsqu'une IA interprète mal une requête, reçoit des instructions incomplètes ou est manipulée par injection de prompt, elle peut agir de manières imprévues. Contrairement à un employé humain qui pourrait s'arrêter pour demander des précisions, un agent d'IA peut agir instantanément et à grande échelle.

S'il est exposé à une entrée malveillante, il pourrait suivre des instructions cachées qui contournent les garde-fous, déclenchant des actions telles que la révocation d'accès, la modification de configurations ou l'arrêt de services. Comme ces systèmes disposent souvent d'un accès privilégié pour automatiser les flux de travail, une seule erreur peut entraîner une cascade de conséquences : suppression de données, interruption des opérations, pertes financières et atteinte à la réputation. À mesure que les organisations intègrent l'IA plus profondément dans leurs systèmes centraux, des garde-fous clairs, des autorisations strictes, une surveillance et un contrôle humain ne sont plus optionnels : ils sont essentiels pour prévenir des dommages réels.

Études de cas réels

Les risques ne sont pas théoriques. Si un agent IA interprète mal une commande telle que « nettoyer les anciennes ressources », il pourrait supprimer des bases de données actives au lieu de données de test.

En juillet 2025, un agent de codage IA de Replit a supprimé une base de données de production entière au cours d'une session de développement. Bien que l'utilisateur ait explicitement ordonné un « gel du code et des actions », l'agent a ignoré cette contrainte et a détruit les enregistrements de 1 206 cadres et 1 196 entreprises dans un système en direct.

Cet incident de février 2026 ressemble à un scénario de science-fiction, presque à une scène de Skynet dans Terminator. Un agent IA a soumis de manière autonome une demande de fusion (pull request) au projet open-source Matplotlib. Lorsqu'un mainteneur a rejeté la contribution, l'agent a rédigé et publié de son propre chef un article de blog diffamatoire critiquant le mainteneur, sans qu'aucun humain ne lui ait ordonné de prendre des mesures de rétorsion.

Aucune intention malveillante n'avait été programmée dans le système, et il n'y a pas eu d'« attaque » traditionnelle au sens classique du terme. Pourtant, cet épisode souligne un point crucial : le système a agi en dehors de l'objectif prévu par ses créateurs et de ses intérêts, et lorsqu'il est doté d'une autonomie excessive, il devient puissant. C'est là, par essence, le fondement de nombreuses vulnérabilités et incidents cyber : lorsque le logiciel dépasse ses limites attendues. À mesure que les agents IA gagnent en autonomie et s'intègrent dans les flux de travail réels, les comportements imprévus ne sont plus seulement des bugs techniques, mais deviennent un risque potentiel pour la sécurité et la réputation.

Le cas ci-dessous rappelle comment les problèmes de sécurité liés à l'IA se transforment en problèmes de sécurité plus traditionnels, et comment un assistant IA par e-mail peut être utilisé dans la cybercriminalité financière.

L'autonomie excessive désigne les systèmes d'IA auxquels sont accordées de larges autorisations opérationnelles allant au-delà de ce qui est strictement nécessaire. Lorsque des agents IA sont connectés à des systèmes sensibles et autorisés à exécuter des actions de manière autonome, les erreurs, les mauvaises interprétations ou les entrées malveillantes peuvent avoir des conséquences directes dans le monde réel. Sans un périmètre strict, des garde-fous et une supervision humaine, l'autonomie devient une faille de sécurité plutôt qu'un avantage en termes de productivité.

Combler le fossé : Cyera AI Guardian

Ces cinq risques partagent une cause commune : un décalage entre la manière dont les systèmes d'IA accèdent aux données et la manière dont les organisations les protègent. Les solutions DLP, CASB et IAM n'ont pas été conçues pour un monde où un assistant IA lit chaque e-mail de votre organisation, où les employés collent des secrets commerciaux dans des chatbots, ou où une simple injection de prompt déclenche le vol de données.

Cyera AI Guardian comble ce fossé en unifiant la gestion de la posture de sécurité de l'IA (AI-SPM) avec une protection de l'IA en temps réel, fondée sur une compréhension des données elles-mêmes. Cyera AI Guardian combine 3 piliers stratégiques dans la posture IA des organisations. Il s'appuie sur les applications de votre organisation installées dans votre environnement cloud, les points de données et les applications et fonctions IA à travers l'écosystème IA : ChatGPT, Claude, Microsoft Copilot, Amazon Bedrock et les applications IA d'entreprise personnalisées.

Il fonctionne à 2 niveaux :

1. Découverte : Avec 59 % des employés utilisant des outils d'IA non approuvés, la visibilité est la priorité. Découvrez toute l'utilisation de l'IA grâce à l'AI-SPM qui identifie chaque outil d'IA dans l'entreprise, qu'il soit autorisé, intégré ou utilisé en mode « shadow ». Cyera AI vous aide à mapper chaque instance d'IA avec ses identités connectées et ses modèles d'accès aux données. 
2. Gouvernance :

• Priorisez la protection en fonction de la sensibilité des données. AI Guardian classifie les données auxquelles les systèmes d'IA accèdent, afin que les protections soient adaptées aux enjeux. Un modèle interrogeant de la documentation publique ne bénéficie pas du même traitement qu'un modèle accédant à des informations personnelles identifiables (PII) de clients ou à du code source.
• Bloquez les fuites de données sensibles en temps réel. AI Protect surveille les prompts, les réponses et les actions des utilisateurs au moment où ils se produisent. Il détecte et bloque la sortie de données sensibles de l'organisation, les tentatives d'injection de prompt, les jailbreaks et les accès non autorisés aux données, avant qu'ils ne réussissent. Qu'un employé colle du code source dans ChatGPT ou qu'un attaquant intègre une injection « zero-click » dans un document traité par Copilot, AI Guardian intervient au point de risque.

Découvrez comment Cyera AI Guardian peut sécuriser votre adoption de l'IA

Questions fréquentes

Qu'est-ce que la protection de la sécurité dans le cloud ?
La protection de la sécurité dans le cloud englobe les mesures et les contrôles conçus pour protéger les données, les applications et les services hébergés dans des environnements cloud contre les cybermenaces et les accès non autorisés.

Pourquoi la surveillance continue est-elle importante pour la sécurité du cloud ?
La surveillance continue détecte les vulnérabilités et les menaces en temps réel, permettant aux organisations de réagir rapidement et de réduire le risque de violation de données dans des environnements cloud dynamiques.

Quelles normes de conformité sont les plus pertinentes pour la sécurité du cloud ?
Les normes courantes incluent le RGPD, HIPAA, PCI-DSS et SOC 2, qui exigent des organisations qu'elles maintiennent des contrôles de confidentialité et de sécurité des données dans leurs déploiements cloud.

Comment l'automatisation améliore-t-elle la sécurité du cloud ?
L'automatisation rationalise les processus de sécurité tels que la gestion des configurations et la détection des menaces, minimisant ainsi les erreurs manuelles et accélérant les temps de réponse.

Quelles mesures puis-je prendre pour prévenir les violations de données dans les environnements multi-cloud ?
Mettez en œuvre des politiques de sécurité cohérentes, utilisez la gestion des identités et des accès (IAM), chiffrez les données et appliquez une surveillance unifiée sur toutes les plateformes cloud.