Sécurité MCP : comment FlipLink encadre les actions destructrices

Connecter un assistant IA à un vrai outil, c'est passionnant ... jusqu'au moment où tu réalises que l'assistant peut désormais agir — créer, publier et, oui, supprimer. Quand tu confies à un agent IA les clés de ton compte FlipLink via un serveur MCP, la question évidente est : qu'est-ce qui l'empêche de supprimer un flipbook publié ou de modifier un prix parce qu'il a mal interprété ta demande ?

Ce guide explique comment le serveur MCP de FlipLink gère la sécurité d'un serveur MCP — les trois modes dans lesquels tu peux le faire tourner, le garde-fou par jeton de confirmation qui protège les actions destructrices et financières, et comment choisir la bonne configuration selon ta façon de travailler.

Pourquoi laisser une IA écrire et supprimer est risqué

Une IA en lecture seule présente peu d'enjeux. Le pire qu'elle puisse faire, c'est résumer la mauvaise liste. Mais dès qu'un assistant peut appeler flipbook_delete ou changer une tarification, un seul malentendu a de vraies conséquences : une instruction mal interprétée, une boucle un peu trop zélée de “nettoyage des vieux flipbooks”, ou une tentative d'injection de prompt cachée dans un document peuvent toutes se transformer en actions que tu n'avais jamais voulues.

La solution n'est pas d'interdire l'écriture — cela irait à l'encontre de l'intérêt de l'automatisation. La solution, c'est la confiance graduée : n'exposer que ce dont la tâche a besoin, et placer un ralentisseur délibéré devant les actions que tu ne peux pas facilement annuler.

Les trois modes

Le serveur MCP de FlipLink est livré avec trois modes, définis par la variable d'environnement FLIPLINK_MCP_MODE. Chaque mode contrôle précisément quels outils le client IA peut même voir — si un outil n'est pas exposé, l'assistant ne peut pas l'appeler.

Quelques points méritent d'être soulignés :

• safe est le mode par défaut. Si tu ne définis rien, tu obtiens uniquement les écritures réversibles — créer, publier/dépublier, définir une expiration, assigner à un dossier, configurer la capture de leads. Les actions que tu serais à l'aise d'annuler à la main.
• readonly est parfait pour l'analytique et le reporting. Pointe un assistant sur ton compte pour répondre à “combien de flipbooks avons-nous publiés ce trimestre ?” sans aucun risque d'écriture.
• full débloque les 8 derniers outils — suppression et achat — mais ceux-ci ne se déclenchent pas au premier appel. Ils passent par le garde-fou du jeton de confirmation.

Tu définis le mode dans le bloc de configuration de ton client, à côté de ta clé API :

{
  "mcpServers": {
    "fliplink": {
      "command": "npx",
      "args": ["-y", "fliplink-mcp"],
      "env": { "FLIPLINK_API_KEY": "<YOUR_KEY>", "FLIPLINK_MCP_MODE": "safe" }
    }
  }
}

Le garde-fou du jeton de confirmation

En mode full, les deux catégories les plus risquées — les actions destructrices (supprimer un flipbook) et les actions financières (vente et changements de tarification) — ne s'exécutent jamais au premier appel. À la place, le serveur utilise une poignée de main en deux temps : aperçu, puis confirmation.

Quand l'assistant appelle un outil encadré, le serveur n'exécute pas l'action. Il renvoie un aperçu d'une ligne de ce qui se passerait, accompagné d'un confirm_token à courte durée de vie. Ce jeton est lié aux arguments exacts de l'appel et expire au bout de 5 minutes. Pour réellement exécuter l'action, l'assistant doit rappeler l'outil avec le jeton correspondant.

Voici l'aller-retour. Premier appel — l'assistant demande de supprimer un flipbook :

// Call 1: flipbook_delete { "FlipbookID": "90442" }
// Server response (nothing deleted yet):
{
  "preview": "Will permanently delete flipbook 90442 (\"Q3 Sales Deck\").",
  "confirm_token": "cf_9f3a...e21",
  "expires_in": 300
}

L'assistant te montre cet aperçu. Si tu donnes le feu vert, il rappelle avec le jeton :

// Call 2: flipbook_delete { "FlipbookID": "90442", "confirm_token": "cf_9f3a...e21" }
// Now the action runs:
{ "Result": "OK" }

Parce que le jeton est lié aux arguments, un assistant ne peut pas obtenir un jeton pour supprimer le flipbook A et le réutiliser sur le flipbook B — les arguments ne correspondront pas et le serveur le rejette. Et parce qu'il expire au bout de cinq minutes, un jeton oublié quelque part dans une longue conversation devient caduc tout seul.

Comment choisir un mode

Une règle simple :

• Tu explores ou tu fais du reporting ? Utilise readonly. Tu obtiens des informations sans aucun risque.
• Automatisation du quotidien — créer et publier des flipbooks ? Utilise safe (le mode par défaut). Tout ce que tu fais est réversible.
• Tu as réellement besoin de la suppression ou de l'automatisation tarifaire ? Utilise full, et appuie-toi sur le garde-fou du jeton de confirmation pour que les actions irréversibles restent délibérées.

La plupart des gens devraient rester en safe. Ne passe à full que lorsqu'un workflow précis l'exige — par exemple, un script de fin de trimestre qui retire les vieux flipbooks — et même là, le garde-fou garantit que chaque suppression est prévisualisée avant de se produire.

🚀

Essaie FlipLink gratuitement

Convertis ton PDF en quelques secondes. Sans inscription, sans carte bancaire — il suffit de téléverser.

Drop your PDF here or click to browse

Max 40 Mo

Les forfaits payants à partir de $39 font passer cette limite à 150 MB.

Application côté serveur (l'API reste inchangée)

Un détail important : tout cela vit dans le serveur MCP, pas dans l'API FlipLink. L'API REST est exactement la même qu'avant — mêmes endpoints, même authentification X-Api-Key, même modèle de réponse Result. Les modes et le garde-fou du jeton de confirmation sont des protections que la couche MCP ajoute par-dessus.

Cela compte pour deux raisons. D'abord, tes intégrations et scripts API existants ne sont pas affectés — rien ne change pour eux. Ensuite, la sécurité n'est pas quelque chose que le client IA peut contourner par la parole : le serveur n'expose tout simplement pas d'outils cachés en readonly/safe, et il refuse d'agir sur un outil encadré sans jeton valide. L'application est structurelle, pas indicative.

Si ta clé API est manquante ou erronée, chaque outil renvoie des instructions de configuration claires au lieu d'échouer en silence — ainsi un client mal configuré te dit quoi corriger.

Annotations MCP

En plus du filtrage par mode et du garde-fou, chaque outil porte des annotations MCP standard — des indices de métadonnées que les clients IA bien conçus lisent pour comprendre la nature d'un outil :

• readOnlyHint — l'outil ne fait que lire ; il ne change rien.
• destructiveHint — l'outil peut supprimer ou écraser des données (par exemple, une suppression).
• idempotentHint — l'appeler deux fois avec les mêmes arguments a le même effet que l'appeler une seule fois.

Ces indices permettent à un client réfléchi d'afficher ses propres avertissements ou de demander une confirmation avant d'invoquer un outil destructeur — une couche de prudence supplémentaire qui complète le garde-fou côté serveur plutôt que de le remplacer.

FAQ

MCP est-il sûr à utiliser avec un vrai compte ? Oui, lorsque le serveur est conçu avec des garde-fous. FlipLink est par défaut en mode safe (écritures réversibles uniquement), et les actions irréversibles du mode full sont protégées par un garde-fou à jeton de confirmation. Tu décides du niveau d'accès à accorder via FLIPLINK_MCP_MODE.

Qu'autorise réellement le mode par défaut ? Le mode safe expose 79 outils : lectures, écritures réversibles (créer, publier, définir une expiration, assigner à un dossier) et paramètres de contrôle d'accès. Il n'inclut pas la suppression ni aucun outil de vente/tarification.

L'IA peut-elle supprimer un flipbook sans mon approbation ? Pas en readonly ni en safe — l'outil de suppression n'est même pas exposé. En mode full, la suppression est encadrée : le serveur renvoie d'abord un aperçu et un jeton de confirmation valable 5 minutes, et l'action ne s'exécute que lorsque l'assistant rappelle avec ce jeton exact.

Tout cela change-t-il l'API FlipLink ? Non. Les modes, le garde-fou et les annotations vivent tous dans le serveur MCP. L'API sous-jacente — les endpoints, l'authentification X-Api-Key et le modèle Result — reste inchangée, donc tes intégrations existantes continuent de fonctionner telles quelles.

Lectures complémentaires

• Qu'est-ce qu'un serveur MCP ?
• Connecter FlipLink à Claude avec un serveur MCP
• Créer un agent IA qui génère des flipbooks
• Aperçu du serveur MCP de FlipLink
• Référence de l'API FlipLink