# Avant d’ouvrir un accès en lecture seule à un agent IA sur un catalogue sensible

> Un accès limité à la lecture semble sans risque à première vue. Une checklist en douze points avant d'ouvrir cet accès à un agent IA sur des données commerciales.

- Auteur : Clément Hadrot
- Publié le : 2025-12-15
- Mis à jour le : 2025-12-15
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/checklist-acces-lecture-agent-ia-catalogue-sensible/

## L’essentiel

- La lecture seule ne protège pas contre l'exfiltration massive de données
- La portée doit être limitée aux champs réellement nécessaires, pas à l'objet entier
- Un accès en lecture non journalisé est aussi risqué qu'un accès en écriture non journalisé

Un accès qui ne permet que la lecture semble, presque par réflexe, moins risqué qu'un accès en écriture. C'est une intuition trompeuse dès qu'un agent IA est capable de récupérer, en quelques appels automatisés, l'intégralité d'un catalogue que consulter manuellement prendrait des semaines à un humain. La lecture seule limite la nature du risque, elle ne l'élimine pas : l'exfiltration massive de données commerciales sensibles reste possible sans aucune écriture.

Avant de connecter un agent à un catalogue de produits, de tarifs négociés ou de fiches clients, même en lecture stricte, une vérification systématique évite les surprises. Voici les douze points qui reviennent le plus souvent dans ce type de mise en place.

## Cadrer la portée exacte de l'accès

1. Identifier précisément quels champs de données l'agent doit consulter, pas l'objet complet par défaut
2. Vérifier qu'aucun champ de tarification négociée ou confidentielle ne figure dans la réponse par défaut d'une route existante
3. Limiter le nombre d'enregistrements retournés par appel pour empêcher une extraction complète en une seule requête
4. Créer une ability ou une route dédiée à cet usage plutôt que de réutiliser une route générique existante

## Encadrer le jeton utilisé par l'agent

1. Générer un mot de passe d'application dédié à cet agent, distinct de tout autre usage
2. Associer ce jeton à un compte de service dédié, sans capacité d'administration
3. Fixer une date de révision de ce jeton dans le calendrier de l'équipe, pas seulement à sa création

> L'essentiel à retenir : La lecture seule ne protège pas contre l'exfiltration massive de données ; La portée doit être limitée aux champs réellement nécessaires, pas à l'objet entier ; Un accès en lecture non journalisé est aussi risqué qu'un accès en écriture non journalisé

## Journaliser avant d'autoriser

1. Vérifier qu'un mécanisme de journalisation est actif avant même le premier appel réel de l'agent
2. S'assurer que le journal capture le volume de données retourné, pas uniquement le succès ou l'échec de l'appel
3. Définir un seuil d'alerte sur un volume de lecture anormal en une session

## Prévoir la réversibilité

1. Documenter la procédure de révocation immédiate du jeton en cas de comportement inattendu
2. Tester cette procédure de révocation avant la mise en production, pas seulement la décrire sur le papier

## Le champ le plus souvent oublié : les données dérivées

Un agent connecté en lecture à un catalogue de produits peut sembler inoffensif tant qu'on regarde uniquement les champs directement exposés. Le problème survient lorsque l'agent croise plusieurs appels successifs pour reconstituer une information qui n'était volontairement exposée dans aucune réponse individuelle : un volume de stock déduit de plusieurs consultations de disponibilité, une structure tarifaire déduite de la comparaison entre plusieurs fiches. Ce risque de recomposition ne se corrige pas au niveau d'un seul champ, mais au niveau du volume total de données accessible sur une période donnée.

### Limiter le débit, pas seulement le contenu

Une limitation de fréquence appliquée spécifiquement au jeton de l'agent, distincte des limites appliquées aux utilisateurs humains, réduit ce risque de recomposition sans nécessiter de complexifier chaque route individuellement.

```
add_filter('rest_pre_dispatch', function ($result, $server, $request) {
    $jeton_agent = 'ID_JETON_CONNU';
    if (mon_plugin_est_jeton_agent($jeton_agent)) {
        if (mon_plugin_limite_atteinte($jeton_agent)) {
            return new WP_Error(
                'limite_agent_atteinte',
                __('Limite de lecture atteinte pour ce jeton.', 'mon-plugin'),
                ['status' => 429]
            );
        }
    }
    return $result;
}, 10, 3);
```

> Un accès en lecture seule n'est prudent que si sa portée, son volume et sa traçabilité sont pensés avec la même rigueur qu'un accès en écriture : la nature de l'opération ne dispense jamais de ces trois vérifications.

## Ce qu'il ne faut pas confondre avec l'accès en écriture

Cette checklist ne couvre volontairement pas les mêmes enjeux qu'un accès en écriture accordé à un agent, où la question centrale devient la réversibilité de l'action elle-même plutôt que la confidentialité des données lues. Les deux cas méritent des grilles de vérification distinctes, car les risques qu'ils couvrent ne se recoupent que partiellement.

## En résumé

Douze points, aucun n'étant à lui seul suffisant, mais leur combinaison réduit considérablement le risque d'un accès en lecture qui semble anodin au premier abord. La portée des champs exposés, l'encadrement du jeton, la journalisation systématique et la limitation de débit forment ensemble un dispositif raisonnable avant d'ouvrir un catalogue sensible à un agent IA, même pour un usage strictement limité à la consultation.