# Un agent IA consomme WPGraphQL : ce qu’il ne faut jamais lui laisser écrire

> Checklist des mutations WPGraphQL à interdire formellement à un agent qui ne devrait faire que lire un catalogue pour générer du contenu de présentation.

- Auteur : Clément Hadrot
- Publié le : 2025-05-07
- Mis à jour le : 2025-05-07
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/agent-ia-wpgraphql-mutations-interdites/

## L’essentiel

- Aucune mutation de suppression ou de publication accessible à l'agent
- Rôle applicatif dédié avec capacités WordPress restreintes
- Journalisation systématique de chaque requête exécutée

« Les mutations permettent de créer, modifier ou supprimer des données via l'API GraphQL », rappelle la documentation de WPGraphQL, en une phrase qui prend tout son sens lorsqu'un agent IA vient s'y connecter. Un projet e-commerce fictif, baptisé ici « Atelier Lampes », avait mis en place un agent chargé de générer des fiches de présentation attractives à partir du catalogue de produits stocké dans WordPress. Sur le papier, une tâche de lecture pure : parcourir des CPT « produit », en extraire les caractéristiques, en tirer un texte marketing. En pratique, le schéma GraphQL exposé à cet agent contenait aussi, par défaut, l'ensemble des mutations d'écriture standard.

Cette checklist recense les mutations qu'il faut interdire, comment les bloquer techniquement, et pourquoi la seule confiance dans le prompt système de l'agent ne suffit jamais. Elle ne traite pas la qualité du contenu rédactionnel généré, qui relève d'un tout autre sujet.

## Pourquoi le risque est réel, pas théorique

Un agent IA connecté à une API GraphQL ne « sait » pas intrinsèquement qu'il ne doit lire que le catalogue. Il dispose d'un schéma introspecté, potentiellement de tout le schéma exposé par WPGraphQL, et d'un jeton d'authentification. Si ce jeton correspond à un utilisateur WordPress avec des droits d'édition ou d'administration, rien n'empêche techniquement l'agent d'appeler `updatePost`, `deleteProduct` (sur un CPT personnalisé) ou `createComment`, que ce soit par une instruction ambiguë de l'utilisateur final, une hallucination du modèle, ou une injection de prompt glissée dans une description produit mal filtrée.

## La checklist des mutations à proscrire

1. **Aucune mutation de suppression** : `deletePost`, ou l'équivalent généré pour tout CPT personnalisé enregistré avec `show_in_graphql`, doit être totalement absent du schéma accessible à l'agent.
2. **Aucune mutation de changement de statut** : un agent qui génère du texte ne doit jamais pouvoir faire passer un produit de `draft` à `publish`, ni l'inverse.
3. **Aucune mutation sur les utilisateurs** : `updateUser`, `createUser` et toute mutation touchant aux rôles ou aux capacités doivent rester hors de portée, sans exception.
4. **Aucune mutation sur les commentaires publics** : un agent qui pourrait publier des commentaires en autonomie ouvre la porte à un usage détourné à des fins de spam ou de manipulation d'avis.
5. **Aucune mutation générique non explicitement whitelistée** : le principe par défaut doit être le refus, pas l'autorisation.

> L'essentiel à retenir : Aucune mutation de suppression ou de publication accessible à l'agent ; Rôle applicatif dédié avec capacités WordPress restreintes ; Journalisation systématique de chaque requête exécutée

## Comment retirer les mutations concrètement

WPGraphQL permet de retirer des champs et des types du schéma via le filtre `graphql_request_data` ou, plus proprement, via `register_graphql_field` combiné à une désactivation ciblée. La méthode la plus fiable reste cependant de créer un rôle WordPress dédié à l'agent, dépourvu de toute capacité d'écriture, puis de générer un jeton d'application lié exclusivement à ce rôle :

```
add_role( 'agent_lecture_catalogue', 'Agent de lecture catalogue', array(
    'read'         => true,
    'edit_posts'   => false,
    'delete_posts' => false,
    'publish_posts'=> false,
) );
```

Avec ce rôle, même si le schéma GraphQL expose techniquement une mutation d'écriture, la couche de capacités de WordPress la refusera systématiquement, car WPGraphQL respecte par défaut les `capabilities` natives de chaque type de contenu avant d'exécuter une mutation.

## Le filtrage du schéma en complément, pas en remplacement

Restreindre les capacités du rôle est la protection de fond, indispensable. Mais filtrer aussi le schéma introspectable réduit la surface visible par l'agent, et donc le risque qu'il tente une mutation vouée à l'échec (avec un message d'erreur qui pourrait, dans de rares cas, être exploité pour deviner la structure interne du site) :

```
add_filter( 'graphql_schema_config', function( $config ) {
    $config->addTypeConfigDecorator( 'RootMutation', function( $type_config ) {
        unset( $type_config['fields']['deleteProduct'] );
        return $type_config;
    } );
    return $config;
} );
```

## Journaliser chaque requête, sans exception

Un rôle restreint et un schéma filtré réduisent le risque, mais ne dispensent pas de journaliser chaque requête exécutée par l'agent : requête reçue, réponse renvoyée, horodatage, jeton utilisé. En cas d'incident, cette trace est la seule façon de reconstituer précisément ce que l'agent a tenté de faire, et de distinguer une hallucination isolée d'une tentative répétée révélatrice d'un prompt détourné.

> Sur ce type d'intégration, le conseil qui revient le plus souvent est simple : ne jamais faire confiance aux instructions données à l'agent pour définir ses limites, seulement aux capacités techniques réellement appliquées côté serveur.

## Pour aller plus loin

Un agent de génération de contenu n'a besoin, dans l'immense majorité des cas, que d'un accès en lecture au catalogue et à quelques métadonnées associées. Toute capacité d'écriture accordée au-delà de ce périmètre constitue une dette de sécurité qui ne se voit pas tant qu'aucun incident ne survient. La documentation officielle de WPGraphQL, régulièrement mise à jour sur son dépôt GitHub, reste la référence à consulter avant toute décision de filtrage de schéma en production.