# Limiter le rayon d’action d’un jeton d’application créé pour un agent IA

> Un mot de passe d'application donné à un agent IA doit être restreint à un périmètre précis, jamais à tout le compte administrateur. Recette pour créer des comptes de service dédiés par agent.

- Auteur : Clément Hadrot
- Publié le : 2025-10-17
- Mis à jour le : 2025-10-17
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/limiter-jeton-application-agent-ia/

## L’essentiel

- Un mot de passe d'application hérite de tous les droits du compte utilisateur
- Un compte dédié par agent limite l'impact d'une fuite
- La révocation individuelle devient possible sans tout casser

**Le problème.** Un client a équipé son site WordPress d'un agent IA autonome chargé de rédiger et publier automatiquement des brouillons d'articles de blog à partir de flux d'actualités du secteur, avant relecture humaine avant mise en ligne définitive. Pour authentifier cet agent auprès de l'API REST de WordPress, l'équipe technique a généré un mot de passe d'application depuis le profil du compte administrateur principal du site, celui utilisé au quotidien par le responsable éditorial. C'est le choix le plus rapide, mais aussi le plus risqué : ce mot de passe d'application hérite intégralement des droits du compte auquel il est rattaché, quel que soit l'usage réel qui en est fait.

Un mot de passe d'application, introduit dans WordPress 5.6, n'est jamais un compte à part entière : c'est une clé d'authentification alternative pour un compte existant. Sa révocation individuelle est possible, mais son périmètre de droits reste identique à celui de l'utilisateur propriétaire, sans distinction possible entre « ce que l'agent a le droit de faire » et « ce que l'humain propriétaire du compte peut faire ». Sur ce site, une fuite de ce mot de passe d'application, par exemple via un fichier de configuration mal sécurisé chez l'hébergeur du service d'agent, aurait donné à un attaquant les pleins pouvoirs d'administration, pour un usage qui ne nécessitait en réalité que de créer des brouillons.

## Le snippet : un compte de service dédié à l'agent

> L'essentiel à retenir : Un mot de passe d'application hérite de tous les droits du compte utilisateur ; Un compte dédié par agent limite l'impact d'une fuite ; La révocation individuelle devient possible sans tout casser

La recette consiste à créer un utilisateur WordPress distinct, dédié exclusivement à cet agent, avec un rôle sur mesure ne portant que les capacités strictement nécessaires à la rédaction de brouillons :

```
// À exécuter une seule fois, par exemple via WP-CLI ou une page d'admin temporaire.
function monsite_creer_role_agent_redaction() {
    add_role( 'agent_redaction_ia', 'Agent de rédaction IA', array(
        'read'                => true,
        'edit_posts'          => true,   // créer et modifier ses propres brouillons
        'upload_files'        => true,   // associer une image à l'article
        'publish_posts'       => false,  // jamais de publication directe
        'edit_others_posts'   => false,  // jamais les articles des autres auteurs
        'delete_posts'        => false,  // aucune suppression
    ) );
}
add_action( 'init', 'monsite_creer_role_agent_redaction' );
```

Le compte utilisateur associé se crée ensuite avec ce rôle unique, un identifiant explicite (`agent-redaction-actualites`), et une adresse email dédiée à la supervision de cet agent plutôt qu'à un humain :

```
wp user create agent-redaction-actualites \
  agent-redaction@exemple.fr \
  --role=agent_redaction_ia \
  --display_name="Agent rédaction actualités"
```

Le mot de passe d'application est ensuite généré depuis ce compte spécifique, jamais depuis le compte administrateur principal :

```
wp user application-password create agent-redaction-actualites "flux-actualites-2025"
```

## Vérifier que le périmètre tient ses promesses

Comme pour tout compte de service, la vérification par l'exemple reste indispensable : générer une requête réelle avec ce mot de passe d'application et confirmer qu'une tentative de publication directe ou de suppression échoue bien :

```
curl -u agent-redaction-actualites:xxxx-xxxx-xxxx-xxxx \
  -X POST https://exemple.fr/wp-json/wp/v2/posts \
  -d '{"title":"Test","status":"publish"}'
# Doit échouer ou forcer un statut "draft" malgré la demande de statut "publish"
```

Sur l'API REST, un utilisateur sans `publish_posts` qui tente de créer un article avec `status: publish` se voit automatiquement rétrogradé en `pending` par WordPress, plutôt que de recevoir une erreur bloquante : un comportement à connaître pour ne pas être surpris en test, et à documenter clairement pour l'équipe éditoriale qui validera ensuite ces brouillons en attente.

## Variante : un compte par agent plutôt qu'un compte partagé

Sur un site où plusieurs agents automatisés interviennent (un agent de rédaction, un agent de modération de commentaires, un agent de veille SEO), la tentation est grande de mutualiser un seul compte de service pour tous, par simplicité de gestion. Cette mutualisation reproduit exactement le problème initial à une échelle différente : impossible de révoquer l'accès d'un seul agent sans couper les autres, et impossible de distinguer, dans les journaux, quel agent a réalisé quelle action.

- Un compte utilisateur distinct par agent, même si plusieurs partagent le même rôle de base.
- Un mot de passe d'application par agent, jamais réutilisé entre plusieurs automatisations.
- Une convention de nommage explicite (`agent-redaction-actualites`, `agent-moderation-commentaires`) qui rend les journaux d'activité lisibles sans effort d'interprétation.

## Variante : une rotation périodique automatisée

Pour les agents amenés à fonctionner sur le long terme, une rotation périodique du mot de passe d'application réduit la fenêtre d'exposition en cas de fuite silencieuse, jamais détectée autrement :

```
wp user application-password delete agent-redaction-actualites "flux-actualites-2025"
wp user application-password create agent-redaction-actualites "flux-actualites-2025-v2"
```

Cette rotation, à planifier tous les trois à six mois selon la sensibilité du site, impose de synchroniser le nouveau mot de passe côté configuration de l'agent, une contrainte opérationnelle mineure comparée au bénéfice apporté en cas de compromission non détectée du secret précédent.

> Un mot de passe d'application donné à un agent devrait toujours répondre à cette question simple : si ce secret fuite demain, que peut faire concrètement celui qui l'obtient ? Sur un compte de service bien scopé, la réponse tient en une phrase courte. Sur un compte administrateur, elle n'a pas de limite.

## Ce qu'il faut retenir

Créer un compte de service dédié par agent IA, avec un rôle taillé sur mesure et jamais le rôle administrateur, prend une dizaine de minutes de configuration initiale. Ce court investissement transforme radicalement l'impact d'une fuite éventuelle : un mot de passe d'application volé sur un compte `agent_redaction_ia` ne permet de créer que des brouillons non publiés, là où le même vol sur un compte administrateur principal aurait ouvert l'intégralité du site à un attaquant.