Audits de sécurité IA SaaS / Rubrex
Évaluations LLM de la sécurité et de la gestion des données pour les applications d'IA, les produits SaaS et les agents. Identifiez les problèmes d'accès, d'actions et de données clients, puis donnez à votre équipe la preuve qu'elle peut agir.
L’évaluation et l’ingénierie de l’IA constituent notre fondement. L'évaluation de la sécurité apporte la même discipline aux limites autour de votre produit.
01L'évaluation
Un audit de sécurité IA SaaS examine l'application, ses flux de travail IA et les données qu'ils touchent. Nous convenons des contrôles applicables à votre produit et signalons explicitement les zones non testées.
Testez si des invites non fiables, des documents récupérés ou des sorties d'outils peuvent modifier la tâche autorisée d'un assistant.
Vérifiez si les utilisateurs et les agents peuvent accéder uniquement aux enregistrements, documents et actions autorisés par leurs rôles.
Suivez les données client via l'application, les fournisseurs de modèles, la journalisation, l'analyse et le stockage.
Passez en revue l'application autour du modèle, y compris les interfaces qui acceptent les données et exécutent les actions.
Évaluez si le système récupère des preuves autorisées et pertinentes et préserve la signification lorsqu'il traite les données.
Mesurez le comportement du flux de travail de l'IA en cas d'échec des preuves, des outils ou des fournisseurs, et après une proposition de correctif.
02Revendications de données, rendues spécifiques
Traiter une demande, conserver un journal, partager des données avec un fournisseur et utiliser des données pour la formation sont des activités différentes. Une évaluation utile identifie la réclamation, les preuves et les limites.
| Question | Preuve à examiner | Ce que le rapport distingue |
|---|---|---|
| Le contenu client est-il utilisé pour la formation ? | Chemins de données, paramètres du fournisseur, conditions applicables et enregistrements disponibles. | Configuration observée, déclarations contractuelles et comportement que nous ne pouvons pas inspecter. |
| Un client peut-il accéder aux données d’un autre ? | Tests d'autorisation sur les API, la récupération, le stockage et les caches. | Les rôles et chemins testés, y compris les éventuelles lacunes d'accès ou de couverture. |
| Que reste-t-il après la suppression ? | Workflows de suppression, journaux, conservation du fournisseur, sauvegardes et exceptions documentées. | Comportement de suppression vérifié par rapport à la conservation qui dépend de la politique ou d'un tiers. |
| Les données extraites ou générées sont-elles correctes ? | Cas de référence représentatifs, vérifications sur le terrain et assistance à la source. | Qualité mesurée sur l’ensemble d’évaluation, distincte des résultats de sécurité et de confidentialité. |
03Ce que votre équipe garde
La version du produit évalué, les environnements, les systèmes autorisés, les chemins de données et les exclusions.
Problèmes prioritaires avec les composants concernés, preuves de reproduction, impact commercial et correctifs recommandés.
Cas convenus, comportement observé, configurations, questions non résolues et résultats des correctifs retestés dans le cadre de la portée.
Un résumé, un rapport technique et les prochaines actions. Un résumé public distinct peut être préparé lorsqu’il est convenu et étayé par des preuves.
04Comment se déroulent les travaux
Les tests commencent par une autorisation écrite, les systèmes cibles, les actions autorisées et les conditions d'arrêt. Nous utilisons des données synthétiques ou approuvées et enregistrons les limites de l'accès disponible.
Le champ d'application mappe les contrôles pertinents à l'OWASP ASVS et prend en compte les directives de l'OWASP pour les risques LLM et agents. Le rapport nomme les versions et les exigences réellement utilisées.
Lire la méthode d'évaluationCartographiez le flux de travail de l'IA, les flux de données, les autorisations et les questions auxquelles l'évaluation doit répondre.
Effectuez des vérifications convenues, examinez les preuves à l’appui et séparez les problèmes observés des problèmes non vérifiés.
Expliquez l'impact, proposez des correctifs et enregistrez le résultat des nouveaux tests convenus sur le système mis à jour.
Fournir les résultats, les limites restantes et un prochain plan d'action pratique.
05Insignes d'évaluation
Un badge d'évaluation Rubrex doit identifier un produit spécifique examiné et être lié à un dossier public avec la portée, les dates, le résumé des preuves et l'état actuel. Cela ne peut pas signifier « risque zéro » ou « aucune utilisation de données ».
L’éligibilité au badge dépend de critères documentés et de preuves de nouveau test. Tout changement important apporté au système évalué nécessite un examen des réclamations concernées.
Lisez les exigences du badge06Avant de commencer
Il s’agit d’une évaluation étendue de la sécurité des applications d’un produit d’IA, des limites du modèle et de l’agent, ainsi que de la gestion des données client. Rubrex peut également évaluer la récupération, les données structurées et la qualité de sortie par rapport aux exigences convenues. Le rapport sépare les résultats de sécurité des résultats de qualité.
Nous pouvons examiner les flux de données de l’application, les paramètres des fournisseurs pertinents, les contrats et les preuves techniques disponibles pour une demande d’utilisation de formation définie avec précision. Une instruction de fournisseur est étiquetée comme telle. Nous ne pouvons pas prouver le comportement interne non divulgué d’un fournisseur à partir d’un test d’application ou étendre une conclusion au-delà de la configuration évaluée.
Les audits de sécurité sont couverts séparément. Le Sprint reste une évaluation de 10 jours ouvrables d'un cas d'utilisation. Si les deux sont nécessaires, nous convenons de la manière dont les cas d’évaluation, les contrôles de sécurité et les livrables s’articulent avant le début des travaux.
L’automatisation et l’analyse assistée par l’IA peuvent soutenir le travail convenu. Les résultats nécessitent des preuves et un examen reproductibles ; les jugements générés par le modèle ou les résultats du scanner ne suffisent pas à eux seuls à étayer une affirmation d’évaluation. Tous les outils qui traitent les données des clients doivent être acceptés avant utilisation.
Nous convenons par écrit des systèmes cibles, des tests autorisés, des comptes de test, du calendrier, des conditions d'arrêt et des données. Selon la portée, les entrées utiles incluent l'architecture, le code, la configuration du fournisseur et un environnement de test avec des données synthétiques ou approuvées. Les limitations d'accès sont enregistrées dans le rapport.
Non. Un badge doit faire référence à une évaluation spécifique et datée et à un acte public de vérification expliquant sa portée et son statut. Il ne peut pas promettre l’absence de vulnérabilité, établir une conformité légale ou remplacer la certification SOC 2 ou ISO. Le paiement achète l’évaluation, pas un résultat réussi.
Recherche connexe
L’injection rapide, les actions d’outils non autorisées et l’abus de coûts automatisé affectent différentes limites. Une évaluation convenue peut examiner les décisions d’accès, les limites des ressources et les résultats des outils ainsi que le comportement du modèle. Notre guide pratique montre comment définir un test, collecter des preuves et vérifier un correctif proposé.
07Démarrez la conversation
Dites-nous ce que vous construisez et la décision que vous devez prendre. Si cela vous convient, nous vous enverrons un e-mail pour organiser un appel de cadrage de 20 minutes. Aucun accès au système n'est nécessaire pour cette première conversation.