L'IA construit votre logiciel. Par défaut, elle ne peut ni le détruire, ni le divulguer, ni y faire entrer quoi que ce soit.
Le cloisonnement est l'état par défaut, pas un réglage dont vous espérez qu'il tienne. Chaque construction s'exécute de façon isolée, sans accès aux bases de données et sans chemin vers la production, avec des appels sortants uniquement là où vous les autorisez, et chaque action consignée. Un relecteur sécurité peut valider parce que les défaillances qui ont fait les gros titres sont absentes par conception.
Aucun chemin de sortie permanent. Chaque action consignée.
La crainte que tout relecteur sécurité apporte face à une construction par IA
Donnez un accès réel à un agent IA et les défaillances qui font les gros titres suivent. Ce ne sont pas des hypothèses : c'est ce qui arrive quand un agent dispose d'une portée permanente et d'un garde-fou qu'il peut contourner par la parole.
Elle efface la production.
Un agent avec une connexion active supprime la base de données, puis annonce un succès, parce que rien n'a délimité ce qu'il pouvait atteindre.
Elle divulgue vos secrets.
Les clés et les données s'éparpillent sur les postes et dans les prompts, et une instruction injectée les envoie vers une destination jamais autorisée.
Elle introduit du code non maîtrisé.
Un agent sans bornes récupère une dépendance hallucinée ou empoisonnée, et votre chaîne d'approvisionnement en hérite le risque, sans bruit.
Et une demande de confirmation qu'on prie simplement l'agent de respecter n'est pas un contrôle.
Des garde-fous dont on espère qu'ils tiennent, ce n'est pas du cloisonnement
La réponse habituelle, c'est un agent sans bornes avec un accès large, clôturé après coup : une étape de confirmation, un réseau qui autorise puis filtre, un scan une fois que c'est fini.
Les garde-fous se contournent.
Une consigne qu'on demande à l'agent d'honorer peut être contournée par la parole, et l'accès reste là pour la seule entrée qui passera.
Les droits restent larges.
Des identifiants larges et permanents sont la norme, le rayon d'impact d'une seule mauvaise étape est donc votre environnement tout entier.
Maleus renverse la logique : la portée dangereuse n'est pas filtrée, elle est absente. La construction est cloisonnée et au moindre privilège par construction, avant la première ligne de code.
Ce qui permet à un relecteur de valider
Pas des garde-fous rapportés, mais une portée qui n'a jamais existé. Chaque point se déplie pour votre équipe sécurité.
Elle ne peut pas atteindre la production, ni toucher vos données
Les constructions s'exécutent dans des environnements cloud isolés, jamais sur le poste d'un développeur. Par défaut les agents n'ont aucun accès aux bases de données et aucun chemin d'écriture vers vos systèmes de production.
La défaillance qui a défini cette catégorie, un agent supprimant une base de données active, ne peut pas naître ici. Elle n'est pas bloquée par une consigne : la portée est simplement indisponible.
Moindre privilège, par construction
Chaque agent s'exécute selon une liste blanche explicite : les chemins exacts qu'il peut toucher et les commandes exactes qu'il peut lancer, rien de plus. La plupart tournent en lecture seule, et la portée de chaque agent est déclarée d'avance.
Les droits excessifs sont la première douleur de sécurité IA ailleurs. Ici le rayon d'impact de chaque étape est borné avant son exécution, pas audité après.
Rien ne sort, par défaut
Les accès sortants sont refusés par défaut, puis mis sur liste blanche : vous déclarez les domaines qu'une application peut appeler, et seuls ceux-là se résolvent. Parce que la construction s'exécute en cloud managé, les secrets ne s'éparpillent jamais sur les postes locaux.
Le chemin d'exfiltration par injection de prompt, une entrée empoisonnée qui convainc un agent d'envoyer des données dehors, est fermé par construction : il n'y a nulle part de non approuvé où les envoyer.
Tout est consigné
Vous recevez la piste d'audit complète, chaque action sensible, qui l'a menée et quand, ouverte à vos propres ingénieurs et filtrable par utilisateur et par projet.
Vous ne croyez pas la construction sur parole quant à ce qu'elle a fait. La piste est le relevé, pas le résumé qu'en fait l'agent.
Chaque action sensible, qui l'a menée, et quand. Filtrable par utilisateur et par projet.
Chaque construction est scannée et notée
Avant toute mise en production, le code généré est scanné : analyse statique pour les vulnérabilités, et vos dépendances contrôlées par niveau de gravité, avec un score de sécurité sur chaque construction.
La surface d'exposition, dépendances comprises, n'est pas un espoir : elle est mesurée à chaque fois. Le socle et la stack fixes gardent cette surface réduite.
Scanned and scored on every build.
Faites la correspondance avec votre liste de contrôles
Les contrôles qu'une revue de plateforme de construction par IA réclame, et où se situe Maleus par défaut.
Aligné sur les pratiques qu'attend votre revue
Le code que Maleus génère est conçu selon l'OWASP Top 10, et la plateforme de construction suit les recommandations de sécurité de l'ANSSI. Le reste de votre grille de conformité se trouve sur la page voisine.
S'intègre à la gestion d'identité que vous utilisez déjà
Voyez le cloisonnement, pas une diapositive qui en parle.
Réservez une démo et nous montrerons l'absence d'accès aux bases par défaut, les sortants sur liste blanche, et le journal complet de session sur une construction réelle, puis nous parcourrons votre liste de contrôles ligne à ligne.
Créé par l'équipe derrière un backend open source largement utilisé et une plateforme de données temps réel.