Sécurité, permissions et frontières de déploiement

Regarder la vidéo

1 · La compétence

Examinez les limites de la démonstration, le chargement des variables d’environnement, vos hypothèses concernant CORS et les journaux, puis exécutez un test d’accès négatif — sans ouvrir un seul fichier de secrets.

• Moindre privilège : utilisateurs, services et outils ne reçoivent chacun que les accès réellement nécessaires.
• Limite des données : une séparation technique réelle entre démonstration, préproduction et production, couvrant les données et les identifiants qui les déverrouillent.
• Injection de prompt/de données : contenu documentaire ou utilisateur non fiable qui tente de détourner le comportement du système ou de divulguer des informations qui devraient rester secrètes.
• CORS, concrètement : api/app.py définit allow_origins=["*"] — ce n’est pas une hypothèse à vérifier, mais un fait observable à lire par vous-même. Décidez si cela est acceptable pour le modèle de menace de cette démonstration, et ce qui devrait changer pour un vrai déploiement multi-tenant.

Lecture principale : OWASP — Top 10 des applications à grands modèles de langage

2 · Exécuter la boucle de preuve

Commencez par la limite d’ingestion — c’est un essai à blanc, il ne change rien :

cd demo
python3 setup_demo.py ingest --dry-run

Lisez les commandes affichées et vérifiez le chemin des secrets : .env.demo.local (réservé à la démonstration, exclu de Git) est un fichier distinct de demo/.env (une copie de l’environnement de production) — la pile de démonstration ne lit jamais ce dernier.

Testez ensuite la limite au moment de la requête, en conditions réelles. Une fois la pile démarrée (python3 setup_demo.py up), appelez /api/v1/qa deux fois — même question, tout identique, sauf workspace :

curl -s -X POST http://localhost:8000/api/v1/qa \
  -H "Content-Type: application/json" \
  -d '{"question": "Qu'\''est-ce qui a changé entre la V3 et la V4 de PR-QA-MRD-009 ?", "workspace": "meridian_demo"}'

curl -s -X POST http://localhost:8000/api/v1/qa \
  -H "Content-Type: application/json" \
  -d '{"question": "Qu'\''est-ce qui a changé entre la V3 et la V4 de PR-QA-MRD-009 ?", "workspace": "not-a-real-workspace"}'

Comparez stats.graph_context_chars et les citations sous sources entre les deux réponses. Si la preuve liée au graphe change — ou disparaît — entre les deux appels alors que les citations vecteur/résumé/plein texte restent identiques, vous venez d’observer en direct la limite réelle : bien réelle pour le canal du graphe, absente pour les trois autres.

Pour chaque limite, notez ce qui la protège actuellement, une commande sûre qui le démontre et l’endroit où subsiste une lacune d’application.

Peu importe la précision de la réponse : si elle expose un document restreint ou un secret, c’est un échec.

3 · Fiche de décision

4 · Exercice de récupération

5 · Livrable et prochaine action

1. Enregistrez la sortie de commande ou le rapport.
2. Complétez la fiche de décision.
3. Notez un cas d’échec et la prochaine vérification à exécuter.

Une liste de contrôle MVP légère des menaces et des permissions, accompagnée d’un test négatif prouvant que chaque limite fonctionne réellement.

Prochaine étape : leçon 16 — revue du pilote et plan d’implémentation sur 30 jours.

Posez-moi vos questions sur les preuves, l’indicateur, le cas d’échec ou l’expérience à tenter ensuite : je suis votre enseignant pour cette formation.