Sécuriser les abilities d’un agent IA relié à Stripe et Brevo

L’Abilities API, intégrée au noyau WordPress avec la version 6.9 sortie en décembre 2025, change la donne pour les boutiques qui souhaitent connecter un agent IA à leurs services de paiement et d’emailing : plutôt que d’exposer des fonctions PHP arbitraires à un agent externe, elle permet de déclarer des capacités précises, nommées, décrites et dotées de permissions vérifiables, consommables ensuite par un client MCP ou tout autre orchestrateur d’agents.

Cette checklist s’adresse à une boutique WooCommerce qui envisage d’ouvrir des abilities à un agent chargé d’orchestrer des tâches touchant à la fois Stripe pour les paiements et Brevo pour l’emailing transactionnel. La configuration précise de ces deux services tiers ne fait pas l’objet de cette checklist ; l’accent porte sur les limites à fixer côté abilities elles-mêmes avant toute activation.

1. Déclarer une ability par capacité métier précise, jamais une ability généraliste

La tentation initiale consiste souvent à déclarer une ability unique et large, du type « gérer commande client », censée couvrir l’ensemble des opérations possibles sur une commande. Cette approche reproduit exactement le défaut observé sur de nombreux outils MCP mal conçus : une capacité fourre-tout qui masque des niveaux de risque très différents sous un intitulé unique.

wp_register_ability( 'boutique/consulter-statut-commande', array(
    'label'               => __( 'Consulter le statut d\'une commande', 'boutique' ),
    'category'            => 'lecture',
    'execute_callback'    => 'boutique_consulter_statut',
    'permission_callback' => function () {
        return current_user_can( 'read' );
    },
) );

Chaque ability déclarée ainsi correspond à une action métier unique et identifiable, ce qui facilite l’audit ultérieur de ce qu’un agent a réellement le droit de faire.

2. Séparer strictement les abilities de lecture des abilities d’action financière

Une ability permettant de consulter le statut d’une commande ne présente aucun risque comparable à une ability permettant de déclencher un remboursement Stripe ou l’envoi d’une campagne Brevo à l’ensemble d’une liste de contacts. Cette distinction doit se refléter dans la catégorie déclarée pour chaque ability, et surtout dans le niveau de capacité WordPress exigé par sa fonction de permission.

• Abilities de lecture : accessibles à tout agent authentifié disposant d’un rôle standard.
• Abilities de notification : envoi d’un e-mail transactionnel unitaire via Brevo, réservées à un rôle disposant d’une capacité dédiée.
• Abilities financières : remboursement ou modification de paiement Stripe, réservées à un rôle disposant d’une capacité spécifiquement créée à cet effet, distincte des capacités WordPress standard.

3. Fixer des limites de montant explicites directement dans l’ability

Une ability de remboursement ne devrait jamais transmettre un montant arbitraire à l’API Stripe sans plafond de contrôle intégré à la définition même de l’ability, indépendamment de ce que l’agent orchestrateur propose comme valeur :

wp_register_ability( 'boutique/proposer-remboursement', array(
    'label'            => __( 'Proposer un remboursement', 'boutique' ),
    'category'         => 'financier',
    'execute_callback' => function ( $args ) {
        if ( $args['montant'] > 5000 ) { // en centimes, soit 50 euros
            return new WP_Error( 'plafond_depasse', 'Validation humaine requise au-delà de 50 euros.' );
        }
        return boutique_enregistrer_proposition_remboursement( $args );
    },
    'permission_callback' => function () {
        return current_user_can( 'gerer_remboursements_ia' );
    },
) );

4. Documenter chaque ability exposée dans un registre consultable

L’Abilities API expose une méthode de découverte permettant à tout client autorisé de lister les abilities disponibles et leur description. Ce registre doit être doublé, côté équipe, d’une documentation interne recensant chaque ability, sa catégorie de risque, le rôle requis pour l’exécuter et l’historique de ses modifications.

1. Exporter régulièrement la liste des abilities enregistrées via wp ability list ou l’équivalent disponible en ligne de commande.
2. Comparer cette liste au registre documentaire interne pour détecter toute ability ajoutée par une extension tierce sans validation.
3. Réviser cette documentation à chaque montée de version majeure de WordPress ou des extensions concernées.

Une ability sans plafond intégré n’est qu’une fonction PHP déguisée avec un nom rassurant ; le plafond, la catégorie et la capacité dédiée sont ce qui la transforme réellement en un point de contrôle fiable.

En résumé

L’Abilities API introduite avec WordPress 6.9 offre un cadre structuré pour exposer des capacités à un agent IA, mais ce cadre ne protège rien par lui-même si les abilities déclarées restent trop larges ou dépourvues de limites explicites. Découper les capacités par action métier précise, séparer lecture et action financière, fixer des plafonds de montant dans le code même de l’ability et tenir un registre documentaire à jour forment la checklist minimale avant d’ouvrir un tel accès à un agent orchestrant paiement et emailing.