Sécurité
Comment Mnemom est sécurisé.
AEGIS contrôle les appels de modèle de vos agents pendant leur exécution. En dessous, les contrôles qui protègent la plateforme elle-même. Questionnaires de sécurité et preuves de contrôle disponibles sous NDA.
Contrôle à l'exécution AEGIS
Chaque appel de modèle est contrôlé en quatre points.
Les appels de modèle qui passent par la passerelle Mnemom sont contrôlés à l'entrée, à l'usage des outils, dans le raisonnement de l'agent et à la sortie. Pour chaque agent, vous choisissez si un contrôle enregistre seulement, avertit ou intervient.
- 1
front door
Le dernier message de l'utilisateur et les résultats d'outils, avant qu'ils n'atteignent le modèle.
- 2
inside.autonomy
Les outils proposés au modèle et les appels d'outils qu'il effectue.
- 3
inside.integrity
Le raisonnement de l'agent, examiné par notre contrôle d'intégrité (AIP).
- 4
back door
La réponse, avant son retour à votre application.
Ce que nous contrôlons
| Menace | Contrôlé à | Comment |
|---|---|---|
| Injection de promptfront door | Des règles de motifs, puis un juge fondé sur un modèle. Le texte est d'abord normalisé, pour que les caractères ressemblants ou cachés ne passent pas. | |
| Instructions cachées dans les résultats d'outilsfront door | Les mêmes contrôles sur les résultats d'outils, comme une page ou un document récupéré. En mode enforce, un résultat signalé est remplacé avant que le modèle ne le voie. | |
| Outils interdits et opérations protégéesinside.autonomy | Les outils sont comparés à l'Alignment Card de l'agent. Les appels d'outils sont comparés aux ressources et opérations que votre organisation marque comme protégées, comme la suppression d'une table. | |
| Données sensibles dans les réponsesback door | Numéros de carte, numéros de sécurité sociale américains, clés d'API, clés privées, jetons d'accès, chaînes de connexion, e-mails, numéros de téléphone et adresses IP. Masqués dans les réponses sans streaming, enregistrés dans les réponses en streaming. | |
| Fraude au paiement et usurpationfront door | Signale un changement de bénéficiaire ou de compte bancaire associ é à l'urgence, au secret ou à une pression pour contourner une validation. | |
| Fausses revendications d'autoritéfront door | Signale les messages qui prétendent venir d'un système, d'un administrateur ou de Mnemom. | |
| Raisonnement dangereuxinside.integrity | Un modèle examine le raisonnement de l'agent pour détecter l'injection de prompt, le désalignement de valeurs, les violations d'autonomie, le raisonnement trompeur et les intentions non déclarées. |
Trois réglages par agent
- Safe House couvre la front door, les appels d'outils et la back door. Chacun peut être activé ou désactivé.
- Autonomie couvre l'usage des outils au regard de l'Alignment Card.
- Intégrité couvre le raisonnement de l'agent.
Les réglages s'appliquent au niveau de la plateforme, de l'organisation, de l'équipe et de l'agent, et le plus strict l'emporte. Un niveau inférieur peut ajouter une protection, mais ne peut ni retirer ni affaiblir une protection définie au-dessus. Les administrateurs de l'organisation définissent les niveaux organisation, équipe et agent.
Quatre modes par réglage
| Mode | Ce qui se passe |
|---|---|
| off | Le contrôle ne s'exécute pas. |
| observe | Le contrôle s'exécute et le résultat est enregistré. La requête et la réponse ne changent pas. |
| nudge | La requête passe avec un avertissement visible par le modèle et votre application. Les données sensibles des réponses sortantes sont masquées. |
| enforce | Le contenu signalé ne passe pas. Un message dangereux est remplacé par un avis de quarantaine, un tour d'outil interdit ou un contrôle d'intégrité échoué est remplacé par un refus, et les données sensibles sont masquées. |
Le résultat figure dans chaque réponse
Chaque réponse de la passerelle indique le résultat de chaque point de contrôle dans un en-tête. Chaque checkpoint d'intégrité est aussi signé et chaîné, comme décrit plus bas sous Enregistrement signé.
x-mnemom-verdict: front=pass; autonomy=pass; integrity=pass; back=passComment les règles restent à jour
- Les règles de détection parviennent à chaque passerelle sous la forme d'un ensemble de règles signé avec Ed25519. Chaque passerelle vérifie la signature avant d'utiliser les règles et applique les changements en quelques minutes.
- Nous testons le contrôle en continu avec un attaquant automatisé et adaptatif qui agit contre des agents de test dans un environnement isolé, jamais contre des agents clients.
- Les nouvelles règles sont relues avant d'arriver en production.
OWASP Top 10 pour les applications agentiques
Où nous couvrons les risques agentiques, et où nous ne les couvrons pas.
| Risque | Couverture | Ce que fait Mnemom |
|---|---|---|
| ASI01 Agent goal hijackPartiel | Les messages entrants et les résultats d'outils sont contrôlés pour l'injection directe et indirecte, et le risque est suivi sur les tours d'une session. | |
| ASI02 Tool misusePartiel | Les outils interdits par la card peuvent être refusés, et les appels visant des ressources ou opérations protégées peuvent être retenus. Tous les appels d'outils dangereux ne sont pas détectés. | |
| ASI03 Identity and privilege abusePartiel | Les permissions d'outils viennent de la card de l'agent, et les revendications entrantes d'autorité système ou administrateur sont signalées. | |
| ASI04 Supply chainNon couvert | Nous enregistrons le fournisseur, le modèle et la version du SDK derrière chaque requête contrôlée, plus un hash de lockfile optionnel. Nous ne détectons pas les dépendances compromises. | |
| ASI05 Unexpected code executionNon couvert | Exécutez le code généré dans un bac à sable au sein de votre application. | |
| ASI06 Memory and context poisoningLimité | Le contenu empoisonné qui revient sous forme de résultat d'outil est contrôlé. Nous ne nous intégrons pas aux magasins de mémoire. | |
| ASI07 Insecure inter-agent communicationPartiel | Les messages d'autres agents sont contrôlés comme toute autre entrée, et les fausses revendications d'autorité sont signalées. Les messages entre agents ne sont pas authentifiés. | |
| ASI08 Cascading failuresNon couvert | À traiter dans l'architecture de votre application. | |
| ASI09 Human-agent trust exploitationCouvert | La pression par l'urgence, l'autorité, le secret ou un changement de paiement dans les messages entrants est signalée. | |
| ASI10 Rogue agentsPartiel | Le comportement est comparé à l'Alignment Card de l'agent. Les administrateurs peuvent mettre en pause ou arrêter un agent, et la mise en pause automatique après des violations répétées peut être activée. |
Source : OWASP GenAI Security Project, genai.owasp.org.
NIST AI Risk Management Framework
Des contrôles et des enregistrements pour chaque fonction.
L'AI RMF est un cadre volontaire que votre organisation met en œuvre. Ce n'est pas une certification. Mnemom fournit des contrôles à l'exécution et des enregistrements que chaque fonction peut utiliser.
| Fonction | Ce que fournit Mnemom |
|---|---|
| Govern | Une politique lisible par machine pour chaque agent (l'Alignment Card), des réglages aux niveaux organisation, équipe et agent, et un journal de qui a modifié quoi. |
| Map | L'objet déclaré et les limites de chaque agent, et la correspondance OWASP ci-dessus. |
| Measure | Un résultat à chaque point de contrôle à chaque tour, et des checkpoints d'intégrité signés que vous pouvez vérifier. |
| Manage | Les modes observe, nudge et enforce, et des commandes de pause et d'arrêt pour chaque agent. |
Plateforme
Comment nous protégeons la plateforme.
Registre signé
- Chaque checkpoint d'intégrité est signé en Ed25519 et lié dans une chaîne de hachage SHA-256 au sein de sa session d'agent : un checkpoint supprimé ou réordonné est détectable.
- Chaque certificat de checkpoint inclut une preuve d'inclusion Merkle. Chacun peut vérifier un certificat via notre endpoint public de vérification, ou vérifier sa signature avec n'importe quelle bibliothèque Ed25519 standard.
- Notre clé publique de signature est publiée sur api.mnemom.ai/v1/keys.
- Les attestations d'agent cards sont enregistrées dans un journal public en ajout seul, inspiré de Certificate Transparency (RFC 6962). Sa racine signée et ses preuves de cohérence sont publiques.
- Les webhooks sont signés en HMAC-SHA256 sur un horodatage et le corps.
- Les clés de signature sont conservées dans Azure Key Vault et chargées dans nos services via une identité managée.
Infrastructure
- Chaque environnement fonctionne comme une cellule autonome avec son propre réseau, sa base de données, son cache, son key vault, son stockage et son service d'identité. Les cellules ne partagent aucun réseau.
- Les bases de données, le cache, le key vault et le stockage n'ont pas d'accès Internet public et ne sont joignables que par des endpoints privés.
- Tout le trafic public nous parvient via Cloudflare. Les origines de production n'acceptent que les connexions venant de Cloudflare.
- Les services internes n'ont aucun endpoint public.
- La base de données de production conserve un serveur de secours dans une seconde zone de disponibilité. Les sauvegardes sont conservées 30 jours et copiées dans une seconde région.
Chiffrement
- Les endpoints publics n'acceptent que TLS 1.2 et TLS 1.3. Les bases de données, le cache et le stockage n'acceptent que des connexions chiffrées.
- Toutes les données clients sont chiffrées au repos.
- Notre application chiffre en plus en AES-256-GCM les secrets de signature des webhooks et les clés de fournisseurs de modèles stockées.
Accès
- Les organisations ont cinq rôles : owner, admin, member, viewer et auditor. L'API vérifie l'appartenance et le rôle de l'appelant à chaque requête d'organisation.
- Les modifications faites via l'API sont journalisées avec leur auteur. Owners, admins et auditeurs peuvent consulter le journal de leur organisation.
Connexion
- Vous vous connectez toujours sur une page Mnemom. Le service d'identité tourne dans chaque cellule, et ses propres pages de connexion et d'administration ne sont pas accessibles depuis Internet.
- Passkeys (nous ne stockons que la clé publique) et MFA par application d'authentification. Désactiver la MFA, retirer une passkey ou déconnecter d'autres sessions exige une nouvelle vérification du second facteur.
- Les sessions navigateur utilisent un cookie chiffré, HttpOnly et Secure, qui expire après 7 jours d'inactivité et au plus tard après 30 jours. Nous vous prévenons par e-mail quand votre compte se connecte depuis un nouvel appareil.
- Les clés d'API ne sont affichées qu'une fois et stockées uniquement sous forme de hachage SHA-256. Elles ont des scopes et peuvent être révoquées ou renouvelées à tout moment.
- La connexion de la CLI et des agents utilise OAuth avec PKCE ou le flux device code.
Comment nous livrons
- Les changements de production passent par un pipeline de déploiement unique. Une version n'atteint la production qu'après approbation par un ingénieur nommément désigné ou, pour les changements classés à faible risque, après la réussite d'un canary automatisé.
- Les branches principales exigent des contrôles automatisés, dont la détection de secrets.
- Notre organisation GitHub impose l'authentification à deux facteurs. L'accès aux ressources cloud de production est limité à quelques personnes nommément désignées et à des identités d'automatisation aux droits restreints. Les outils internes sont derrière Cloudflare Access.
Conformité
Prêts pour la conformité SOC 2 Type II, RGPD et HIPAA. Audit indépendant en cours. Les questionnaires de sécurité et les preuves de contrôle sont disponibles sous NDA.
EU AI Act : articles 10 et 12 et annexe IV mis en correspondance avec le registre signé. Un mapping technique, pas une certification.
Voir la page TrustSignaler une vulnérabilité
Écrivez à [email protected]. Notre politique de divulgation figure dans notre security.txt et sur la page Trust.
[email protected]Avancez vite. Restez debout.
Sachez ce que vos agents font vraiment, avant que le board ne demande.
Deux commandes pour installer. Un registre signé dès la première décision.
