Cette page décrit des mécanismes appliqués par le serveur, pas des intentions. Elle est écrite pour être lue par votre équipe IT.
La réponse tient en une phrase : il agit avec vos droits, et chaque geste est tracé. Le reste de la page déplie cette phrase, mécanisme par mécanisme.
Beaucoup d’intégrations fonctionnent avec un compte technique : un identifiant unique, très privilégié, partagé par tous les usages. C’est pratique à construire et impossible à auditer. Le MCP Faast ne fonctionne pas comme cela.
Le serveur ne détient aucun identifiant, aucune session permanente, aucun accès global. Il n’a rien à prêter à un assistant. Chaque requête qui arrive porte le jeton de la personne qui parle, et chaque action recalcule les droits de cette personne au moment où elle s’exécute, avec le même moteur d’autorisation que l’application web.
Les écritures empruntent exactement les mêmes chemins que l’interface : mêmes transactions, mêmes verrous de version, mêmes journaux. Il n’existe pas de voie parallèle avec des règles plus souples.Un assistant branché sur Faast ne dépasse jamais la personne qui lui parle.
Ajoute Camille à l’équipe du live du 8 septembre
L’action s’exécute avec vos droits. Si votre rôle ne vous autorise pas à gérer l’équipe de ce live, elle est refusée, avec le même verdict que si vous aviez cliqué dans l’application.
Deux chemins, et un seul principe : votre mot de passe ne transite jamais par l’assistant.
L’assistant interroge l’adresse du serveur. Celui-ci publie ses métadonnées au standard
RFC 9728, sur /.well-known/oauth-protected-resource. L’assistant sait
alors où s’authentifier, sans configuration manuelle de votre part.
Le client MCP (Claude, ChatGPT, Cursor, VS Code, Gemini CLI) s’enregistre auprès du serveur via l’enregistrement dynamique standard, RFC 7591. Personne n’a de clé à créer à la main. Les enregistrements restés inactifs sont purgés automatiquement.
Une page Faast s’ouvre dans votre navigateur. Vous vous connectez avec votre compte habituel, sur le domaine Faast, avec vos moyens d’authentification habituels. L’assistant ne voit pas cet échange.
Un écran nomme le client qui demande l’accès et attend votre validation. Rien ne s’active tant que vous n’avez pas validé.
Le code d’autorisation est à usage unique et protégé par PKCE en S256. Aucun jeton ne transite dans une URL. C’est de l’OAuth 2.1 standard, sans variante maison.
La session se renouvelle seule grâce au jeton de rafraîchissement prévu par le standard. Si elle expire, un clic sur « Se connecter » la relance.
Certains outils ne parlent pas OAuth, ou vous préférez une configuration figée pour un agent interne. Dans ce cas, la page Assistant IA de l’application (entrée de la barre latérale, pas un sous-menu des réglages) permet de créer un jeton d’accès personnel, à coller comme jeton porteur dans le client de votre choix.
Un jeton personnel porte les droits de son propriétaire, et rien d’autre. Il vit et meurt avec le compte qui l’a créé.
La même page liste vos jetons et permet d’en supprimer un. La suppression coupe l’accès du client qui l’utilisait à la requête suivante, sans toucher aux autres jetons ni à votre compte. Désactiver le compte Faast d’une personne coupe simultanément tous ses accès MCP : le serveur n’entretient aucune liste d’accès séparée qui pourrait survivre au compte.
Ces règles ne dépendent ni du client branché, ni de la formulation de la demande. Elles s’appliquent au moment de l’exécution, côté serveur.
La liste des actions présentée à l’assistant s’adapte à votre compte. Cette visibilité n’est qu’un confort d’usage : la frontière réelle est ailleurs, dans le contrôle que le serveur refait à l’exécution de chaque action.
Certaines opérations n’ont rien à faire au bout d’une phrase mal formulée. Elles sont retirées du MCP, pour tous les rôles, sans exception ni contournement.
À quoi s’ajoute une validation stricte des entrées : chaque action déclare son schéma, et un argument hors schéma est rejeté avant d’atteindre la base.
C’est le point que les équipes sécurité regardent en premier depuis que les assistants manipulent du texte venu de l’extérieur. Un scénario, un commentaire de validation, une fiche produit peuvent contenir n’importe quelle phrase, y compris une phrase qui ressemble à une instruction.
Les instructions du serveur rappellent explicitement à l’assistant que tout contenu retourné est une donnée à traiter, jamais un ordre à exécuter, et que les actions destructives demandent votre confirmation. Cette consigne renforce le comportement de l’assistant. Le rempart, lui, est plus bas : un texte piégé n’obtient aucun droit qu’il n’avait déjà, et sa demande de supprimer la marque se heurte au refus opposé à tous.
Chaque bloc de scénario porte un verrou de version. Si le bloc a changé entre la lecture et l’écriture, la modification est refusée avec un conflit 409. L’assistant relit alors la version fraîche et réapplique sa modification.
Ce mécanisme n’est pas propre au MCP : il protège de la même façon deux personnes dans l’application, une personne et un assistant, ou deux assistants. Personne n’écrase silencieusement le travail d’un collègue.
Supprime complètement le live du 8 septembre
Refusé, pour tout le monde et quel que soit le rôle. L’assistant vous renvoie vers l’application, où la suppression demande une confirmation humaine.
Ce point mérite d’être dit franchement, parce qu’il ne dépend pas de Faast. Quand vous utilisez un assistant IA, votre conversation transite par l’éditeur de cet assistant : Anthropic si vous utilisez Claude, OpenAI si vous utilisez ChatGPT, et ainsi de suite selon le client que vous branchez. Cela vaut pour vos questions comme pour les réponses que Faast renvoie et que l’assistant lit pour vous répondre.
Si votre politique interne interdit qu’un contenu donné sorte du système d’information, la question à trancher n’est pas « peut-on brancher le MCP », mais « quel assistant, avec quel contrat, avec quels réglages de conservation ». La réponse ne change rien au modèle d’autorisation décrit plus haut.
La politique de confidentialité de la plateforme s’applique au MCP comme au reste de Faast : app.faast.tv/legal/privacy.
Rien de ce qui est branché ici n’est difficile à débrancher.
Le MCP n’ajoute aucun stockage propre de vos contenus.
Les questions posées en revue de sécurité, avec la réponse.
Non. Le serveur n’a aucun identifiant propre. Chaque appel porte le jeton d’un utilisateur nominatif, et les droits sont recalculés au moment de l’exécution.
OAuth 2.1 avec PKCE en S256, découverte au standard RFC 9728, enregistrement dynamique de client au standard RFC 7591. En alternative, un jeton d’accès personnel créé et révoqué dans l’application.
HTTPS de bout en bout. Le protocole est le Model Context Protocol en Streamable HTTP, sans état conservé côté serveur entre deux appels.
Oui, c’est le même moteur d’accès : marques, lives et équipes accessibles selon le rôle, recalculés à chaque appel. Il n’y a pas de table de droits spécifique au MCP.
Elle est refusée. La liste d’actions présentée est adaptée au compte pour le confort d’usage, mais l’autorisation est vérifiée côté serveur, indépendamment de ce que le client affiche.
Non. Le refus est indistinct : « ressource introuvable ou accès refusé », sans révéler laquelle des deux situations s’applique.
Chaque appel, lectures comprises : utilisateur, action, décision, origine. Les arguments sont stockés sous forme d’empreinte uniquement. La durée de conservation relève de la politique de la plateforme : demandez-la à l’équipe Caast si vous devez la documenter.
Les suppressions critiques (live entier, marque, compte) sont refusées à tous via le MCP. Les suppressions du quotidien sont possibles avec les droits correspondants, et les instructions du serveur demandent à l’assistant votre confirmation.
Budget de l’ordre de 120 appels par minute et par utilisateur appliqué par instance, pagination à 200 éléments, budgets temps par action (60 secondes en général, jusqu’à 5 minutes pour les générations), validation stricte des entrées contre le schéma de chaque action.
Un contenu piégé ne confère aucun droit supplémentaire : il se heurte aux mêmes refus. Les instructions du serveur rappellent en outre à l’assistant de traiter tout contenu comme une donnée, jamais comme un ordre.
Oui, vers l’éditeur de l’assistant que vous choisissez, comme pour tout usage d’un assistant IA. La conservation et l’usage pour l’entraînement se règlent dans les paramètres de votre organisation chez cet éditeur. Faast n’émet aucun envoi en dehors des réponses à vos appels.
Supprimer le jeton depuis la page Assistant IA, ou désactiver le compte. L’accès tombe à la requête suivante. Il n’existe aucune liste d’accès MCP séparée qui survivrait à la désactivation du compte.
L’accès du support au nom d’un utilisateur existe pour l’assistance, et il est tracé avec l’identité de l’opérateur, pas seulement celle de l’utilisateur concerné.
88 sur 193. Les 105 restantes sont réservées à l’équipe Caast et n’apparaissent pas chez une marque.
Non. La médiathèque se consulte mais ne s’alimente pas par le MCP ; un document de brief se rattache par son lien. C’est une limite assumée, et elle réduit d’autant la surface d’écriture.
Oui, par construction : une seule personne branche son compte, avec ses droits, et rien n’est ouvert aux autres tant qu’elles ne se connectent pas elles-mêmes. Il n’y a pas d’activation globale à l’échelle de la marque.
Les points qui ne figurent pas sur cette page (hébergement, certifications, sous-traitants, durées de conservation contractuelles, engagements de niveau de service) relèvent du dossier plateforme de Faast, pas du MCP : demandez-les à l’équipe Caast plutôt que de les déduire d’ici.
Le modèle technique tient. Ce qui l’affaiblit, en pratique, ce sont les habitudes : un compte par personne, aucun jeton qui circule, un départ traité au bon endroit. Le quatrième bloc est la liste à cocher du premier jour.
Chaque membre de l’équipe se connecte avec son propre compte Faast. C’est ce qui rend l’audit lisible : sans cela, le journal dit « quelqu’un a modifié le scénario » au lieu de dire qui. C’est aussi ce qui rend les droits utiles : deux personnes qui posent la même question à leur assistant reçoivent des réponses différentes, chacune bornée à son périmètre.
Rien à activer côté marque : toute personne qui a déjà un compte Faast peut brancher son assistant, seule, en quelques minutes.Un jeton d’accès personnel est personnel. Le copier dans un canal d’équipe, un fichier de configuration partagé ou un outil interne commun casse d’un coup la traçabilité et la révocation.
Un jeton dédié à un automatisme ressemble à un compte de service, mais n’en est pas un : il porte les droits d’une personne réelle et disparaît avec son compte. Choisissez cette personne en conséquence, et documentez le rattachement.
Le départ d’un collaborateur se traite au même endroit que d’habitude, et cela suffit.
https://mcp.faast.tv
Une personne suffit pour évaluer : elle branche son compte, avec ses droits, et rien n’est ouvert aux autres tant qu’elles ne se connectent pas elles-mêmes.