Du signal de risque à la décision
Un risque détecté alimente une décision. La politique de l’application détermine si la requête peut continuer, doit être bloquée, nécessite un examen ou le retrait de valeurs sensibles.
Sécurité du runtime IA
Pyrodit Guard
Couche de sécurité du runtime IA · Discuter de votre déploiement
Définissez les requêtes d’IA et les actions d’outils autorisées, celles qui nécessitent un examen et le traitement des données sensibles.
Est-ce le bon produit ?
- Conçu pour
- Équipes exploitant passerelles IA, assistants et agents ayant accès à des données ou outils sensibles.
- Ce qu’il vous permet de faire
- Évaluez requêtes et actions selon les politiques, protégez les valeurs sensibles et conservez la trace des décisions.
- Son rôle dans votre architecture
- La couche de protection à l’exécution. Scan Lab teste le système ; Guard applique décisions de politique et contrôles dans son fonctionnement.
Périmètre et disponibilité
Les intégrations de passerelle, de SDK et d’outils sont en développement. L’évaluation définit le périmètre des politiques et vérifie l’effet du blocage, du masquage et des interruptions de service sur votre application avant l’activation de la protection.
- Point de départ
- Requêtes IA, sorties ou actions d’outils avec contexte d’identité et de politique.
- Résultat
- Décisions de politique, transformations requises et trace d’application.
- Déploiement
- Intégration à une passerelle, un SDK ou une interface d’outil, avec comportements explicites en cas de délai dépassé ou d’échec.
Suivez le travail
Concevez la frontière avant d’appliquer une décision.
Scénario d’intégration prévu : un assistant peut transmettre un texte sensible à un outil. Détection et masquage partagés soutiennent la conception ; l’application Guard de bout en bout nécessite l’acceptation de l’intégration.
Workflow prévu · en développement
Identifier la frontière d’action
Choisissez requête, réponse ou action d’outil à examiner. Incluez identité, capacité autorisée et destination pour fournir le contexte de décision à la politique consommatrice.
Exemple de résultat
- Contexte de la frontière
- Acteur, action, destination et périmètre de politique pour l’intégration visée.
Une couche de sécurité à l’exécution qui relie les signaux de risque aux règles de votre organisation. Définissez quand autoriser, bloquer, masquer ou demander un examen, et conservez la trace de la décision et de son application.
01
Intégrations du runtime
Connectez passerelles, points d’application des politiques, SDK et adaptateurs aux frontières des requêtes, réponses et actions d’agents.
02
Profils et politiques
Publiez profils et ensembles de politiques signés et versionnés, liez détecteurs, règles de masquage, charges de travail et ressources, puis promouvez-les de manière contrôlée.
03
Moteur de décision
Déterminez autorisation, refus, validation requise ou résultat indéterminé à partir des politiques, signaux de détection et obligations de transformation, avec blocage en cas d’incertitude.
04
Protection des données
Appliquez les politiques de masquage et produisez des traces d’audit pour l’occultation, le hachage, le masquage partiel et le remplacement ; gardez la tokenisation avec coffre comme extension contrôlée.
05
Opérations protégées
Enregistrez les opérations, exposez les outils, découvrez et liez les capacités MCP, puis gérez autorisations, délégations et liaisons d’exécuteurs avant tout effet de bord.
06
Preuves et trafic sortant
Consignez interactions, signaux, décisions, attestations de couverture et justificatifs de contrôle, avec état de santé, alertes, commandes d’urgence et politique de sortie sécurisée.
Architecture et contrôle
Les signaux d’abord. Des décisions fondées sur des preuves.
La détection identifie un risque potentiel ; votre politique détermine la réponse. La conception des intégrations Guard relie le signal, la décision et la trace de son application.
Protection aux frontières
Les intégrations prévues gateway, SDK, outils et MCP doivent appliquer règles de masquage, capacités et validations avant qu’une action d’agent produise un effet. Leur acceptation de bout en bout reste un travail de déploiement.
Justificatifs et couverture
Conservez la version de la politique, le demandeur, les signaux de risque, les champs modifiés et la décision finale avec le journal d’interaction. Ce contexte aide à examiner les incidents et les données quittant le système.
Cas d’usage
Enjeux d’entreprise. Décisions coordonnées.
Des réseaux de magasins aux usines et aux opérations bancaires : explorer des processus reliant systèmes, équipes et habilitations.
Équilibrer les stocks entre magasins, entrepôts et canaux numériques.
Quand la demande promotionnelle dépasse les stocks, évaluer ensemble commandes en magasin et en ligne. Arbitrer disponibilité, marge et capacité logistique.
Découvrir le workflow →Maîtriser une rupture d’approvisionnement avant l’arrêt de production.
Évaluer un composant retardé selon les usines, plans de production et engagements clients. Comparer substitution, transfert intersites et replanification dans un même dossier.
Découvrir le workflow →Coordonner les incidents de paiement selon leur impact métier.
Relier une interruption de canal aux files de transactions, rapprochements et engagements clients. Réunir opérations, technologie et risques dans un plan commun.
Découvrir le workflow →Coordonner l’entrée en relation dans un dossier partagé.
Réunir chargés de relation, vigilance client et opérations. Suivre entités, représentants habilités, justificatifs manquants et décisions dans le même dossier.
Découvrir le workflow →En pratique
Comment se déroule l’utilisation quotidienne ?
Découvrez les étapes de travail, contrôles opérationnels et limites d’évaluation du produit.
Quelle différence entre Guard et Scan Lab ?
Scan Lab organise les évaluations délibérées et leurs résultats. Guard vise l’utilisation des signaux de sécurité à l’exécution, où une politique consommatrice décide d’autoriser, refuser, transformer ou demander une validation. Les détecteurs communs ne rendent pas les produits interchangeables : résultat d’évaluation et décision appliquée répondent à des questions différentes.
Que contient déjà le socle de masquage ?
La couche commune définit des politiques versionnées par organisation et projet. Les règles relient détecteurs, champs et stratégies d’occultation, hachage, masquage partiel ou remplacement, avec priorités et activation. La traçabilité relie instantané de politique, règle et configuration ou artefact de modèle du détecteur pour examiner une transformation.
Quelles intégrations de protection évaluer ?
Identifiez d’abord la frontière à protéger : requêtes applicatives, réponses des modèles ou actions d’outils. Définissez ensuite politique consommatrice, masquage, conservation des preuves et réponse à un détecteur indisponible. Gateway, SDK, adaptateurs et playground sont prévus ; l’intégration de bout en bout doit être vérifiée avant de parler de protection déployée.
Fonctionne aux côtés de
Donnez à chaque produit une responsabilité claire.
Combinez les capacités nécessaires à votre processus. Définissez comment les produits partagent contexte, droits et résultats dans le workflow.
Pyrodit Scan Lab
Mettez à l’épreuve les changements de politiques et de détecteurs dans des évaluations contrôlées avant de valider l’intégration au runtime.
Pyrodit Agentic Runtime
Identifiez les étapes où un agent peut produire un effet externe, puis convenez des politiques, comportements en cas d’échec et preuves nécessaires.
Construire avec Mindtro