Aller au contenu principal
Avancé•12–18 heures

Audit de la chaîne d’approvisionnement des capacités agent

Auditez les Agent Skills, plugins, serveurs MCP et catalogues de tools comme une chaîne d’approvisionnement de capacités exécutables couvrant provenance, limites d’installation, schémas, autorisation, cache, dérive de version et révocation.

chaîne d’approvisionnement IAsécurité MCPprovenance des toolsautorisationcontrôle de versionrévocation

Scénario

Tâche

Une organisation connecte des dizaines de serveurs MCP, Agent Skills et plugins. Le catalogue de tools évolue indépendamment du release applicatif, une installation locale peut exécuter des commandes et les métadonnées en cache peuvent survivre à un redéploiement. Prouvez quelles capacités sont réellement autorisées pour un release précis de l’agent et comment les révoquer.

Exécution pas à pas

1. Construisez l’inventaire des capacités

Résultat: Aucune dépendance inconnue de tool, plugin ou skill ne subsiste dans le release.

Tâches

  • →Recenser les serveurs MCP et les tools
  • →Enregistrer version, digest et provenance
  • →Marquer les limites de commande des installations locales
  • →Classifier les accès lecture, écriture, egress et données

Vérifications

  • ✓Chaque capacité possède un owner
  • ✓Un package portable n’est pas considéré fiable uniquement à cause de son format

2. Séparez accès protocolaire et autorité métier

Résultat: Une requête OAuth ou MCP valide ne signifie pas qu’une action à conséquences est autorisée.

Tâches

  • →Vérifier le binding issuer/client
  • →Attribuer les scopes de permission métier
  • →Ajouter des approbations exact-action
  • →Appliquer deny-by-default aux nouveaux tools

Vérifications

  • ✓Un nouveau tool ne reçoit pas automatiquement d’autorité
  • ✓Toute extension de privilège exige une revue distincte

3. Lancez les tests de dérive et de poisoning

Résultat: Les changements de métadonnées, schéma ou cache ne contournent pas la policy.

Tâches

  • →Modifier la description du tool
  • →Changer le schéma d’entrée
  • →Créer un catalogue en cache obsolète
  • →Simuler un mismatch header/body
  • →Tester un tool révoqué après reconnexion

Vérifications

  • ✓Les métadonnées non fiables ne définissent pas la policy de permission
  • ✓Une capacité révoquée ne réapparaît pas via un cache obsolète

4. Exécutez un drill de révocation

Résultat: L’équipe peut isoler et révoquer une capacité compromise sans blackout complet.

Tâches

  • →Trouver tous les agents affectés
  • →Révoquer credentials et scopes
  • →Purger les caches
  • →Vérifier les travaux en cours
  • →Revenir à une version known-good

Vérifications

  • ✓Le time-to-revoke est mesuré
  • ✓La suite de régression passe après restauration

Critères d’acceptation

  • Le Capability BOM est complet
  • Les nouvelles capacités sont deny-by-default
  • L’authentification protocolaire est séparée de l’autorité métier
  • La dérive des métadonnées et schémas des tools est couverte par des tests
  • Le drill de révocation démontre un retour known-good