Spécifie que le contenu récupéré non fiable ou fourni par l'utilisateur ne peut pas autoriser des outils ni exfiltrer des secrets, que le modèle suit une hiérarchie d'instructions documentée, et que les sorties sont filtrées avant les effets secondaires privilégiés.
Statut du package : contexte de référence prêt pour revue humaine. Le contrat et les scénarios de test sont complets, mais aucune affirmation n'est faite quant à la réussite de leur passage par une implémentation adoptante.
Décision
Les fonctionnalités du modèle de langage traitent les tours utilisateur, les segments récupérés et les résultats d'outils comme non fiables. Ces canaux ne peuvent pas accorder d'outils, créer des capacités de session, ni placer de secrets dans le contexte. Une hiérarchie d'instructions documentée aide le modèle à interpréter les instructions, tandis que les vérifications de capacités à l'exécution, l'isolation des outils, le principe du moindre privilège et l'isolation des secrets forment la principale frontière de sécurité. Le filtrage des sorties constitue une défense en profondeur contre les fuites reconnaissables, mais ne prouve pas qu'un contenu sensible arbitraire ne peut pas être exfiltré. Le nombre de sauts d'outils est limité.
Portée
- Chemins de réponse Copilot et RAG pouvant appeler des outils.
- Emballage des prompts, vérifications de capacités, filtres de sortie et limites de sauts dans le profil d'adoption.
- Cartographie dans
threat-model.md.
Hors de ce bloc
- Qualité du modèle, jeux de données d'évaluation ou formatage des citations ; voir le bloc de référence associé.
- Politique produit complète d'appel d'outils au-delà de l'injection ; voir le bloc d'autorisation associé.
- Alignement des modèles fondamentaux au moment de l'entraînement.
Contrat
- Les canaux non fiables sont étiquetés dans le prompt emballé et ne peuvent pas définir
cap-exportoucap-egress. - Un outil listé comme privilégié s'exécute uniquement lorsque la session détient déjà la capacité correspondante.
- Le rang des instructions est : politique système, puis manifeste développeur-outil, puis tour utilisateur, segment récupéré, et résultat d'outil.
- Les jetons API et chaînes de connexion sont interdits dans le contexte du modèle ; les fixtures ne doivent pas intégrer de secrets actifs.
- Une sortie correspondant aux
block_patternsn'est pas livrée telle quelle à l'utilisateur, et l'accès à d'autres outils est refusé. - L'agent s'arrête après
max_tool_hopsmême si le modèle demande plus d'appels.
Guide d'implémentation
- Emballez les prompts avec une hiérarchie vérifiée par machine. Autorisez les outils à l'exécution après que le modèle propose un appel, minimisez les données accessibles et les effets secondaires de chaque outil, et gardez les secrets hors du contexte visible par le modèle.
- Ne placez pas le texte récupéré dans la politique système. Les outils inconnus échouent en mode fermé.
Gestion des échecs et mesures de sécurité
- L'absence de capacités signifie refuser les outils privilégiés. L'échec du filtrage entraîne un refus fermé pour ces outils.
- Les segments récupérés trop volumineux sont supprimés. Les workers plantés ne doivent pas reprendre la boucle de saut.
Vérification et exploitation
- Rejouez les fixtures de
threat-model.mden CI sans exécuter les outils privilégiés. - Surveillez
prompt_injection_blocked; ne consignez pas les secrets bruts issus des détections de filtre.
Les exemples exécutables de ce package sont des fixtures et des contrats d'acceptation. Lancez
python tools/validate.py depuis la racine de la collection pour vérifier la structure et les métadonnées du package ; puis
implémentez et exécutez les scénarios dans le dépôt cible.
Hypothèses d'adoption
- Les noms et valeurs numériques dans
example.yamlconstituent un profil d'adoption, pas des valeurs par défaut universelles. - L'équipe adoptante doit cartographier les acteurs, classes de données, vocabulaire d'erreur et propriété à son système.