Utilisez FortressFlag depuis un agent IA

Si vous travaillez avec un agent de codage IA, vous pouvez lui donner vos flags. « Désactive new-checkout en production » est une phrase avec un appel d’API exact derrière elle — et un appel qui touche vos vrais utilisateurs, ce qui explique pourquoi ce guide passe autant de temps sur les limites que sur la configuration.

FortressFlag fournit un serveur MCP : un petit programme qui tourne sur votre propre machine, à côté de votre agent, et lui donne un ensemble d’outils pour les flags.

Ce qu’il peut et ne peut pas faire

La version courte : votre agent peut faire exactement ce que vous pouvez faire, et moins.

Le serveur détient un jeton d’API qui agit en tant que vous — votre rôle, votre accès aux projets, votre organisation. Il parle à FortressFlag par la même API publique que le tableau de bord utilise, donc chaque vérification de permission, chaque liste d’autorisation de projet et chaque enregistrement d’audit est identique à un clic de votre part sur le bouton. Il n’existe aucun chemin d’accès spécial pour les agents.

Certaines choses sont délibérément indisponibles à un agent, quoi qu’il arrive :

• Approuver une proposition de production. Tout l’intérêt d’une seconde paire d’yeux, c’est qu’elle appartienne à une personne.
• Supprimer définitivement un flag.
• Créer des clés SDK ou des jetons d’API. Un secret à usage unique renvoyé à un agent finit dans une transcription de conversation.
• Gérer les membres, la facturation ou les accords juridiques.

Configurez-le

1. Créez un jeton. Dans le tableau de bord, allez sur la page de votre compte et trouvez Jetons d’API. Donnez-lui un nom que vous reconnaîtrez, choisissez une portée, et copiez le jeton — il est affiché une seule fois.

Choisissez Lecture seule sauf si vous voulez que l’agent fasse des changements. Vous pourrez toujours créer un second jeton plus tard.

2. Pointez votre agent vers le serveur. La plupart des clients MCP prennent un petit bloc de configuration nommant une commande et son environnement :

{
  "mcpServers": {
    "fortressflag": {
      "command": "ffmcp",
      "env": {
        "FORTRESSFLAG_TOKEN": "ffm_your_token_here",
        "FORTRESSFLAG_API_URL": "https://your-fortressflag-api"
      }
    }
  }
}

Le jeton va dans env, jamais dans args — les arguments de ligne de commande sont visibles par les autres utilisateurs d’une machine partagée.

3. Ajoutez --allow-writes quand vous voulez des changements. Sans lui, le serveur ne propose que des outils de lecture. Avec lui, votre agent peut basculer, créer, renommer, archiver et restaurer des flags — toujours dans les limites de ce que votre rôle permet :

"args": ["--allow-writes"]

Considérez cette option comme une commodité, pas comme un verrou. Si un agent n’a aucune raison de changer des flags, donnez-lui aussi un jeton en lecture seule — c’est la partie que FortressFlag applique réellement.

La production est protégée deux fois

Votre rôle décide en premier. Si vous êtes Developer, vous ne pouvez pas écrire directement en production — donc votre agent non plus. Ce qu’il peut faire, c’est proposer le changement, exactement comme vous le feriez : un second coéquipier l’applique, et personne ne peut approuver sa propre proposition. Voir les approbations en production.

L’outil redemande en second. Avant de toucher à un environnement de production, l’agent doit déclarer qu’il en a l’intention, en nommant l’environnement. Cette vérification lit la classe production de l’environnement, pas son nom — de sorte qu’un environnement que vous avez appelé live est protégé exactement comme un environnement appelé prod, et qu’un environnement simplement nommé prod qui n’est pas de classe production ne vous harcèlera pas.

Cette seconde vérification existe parce que l’erreur réaliste n’est pas un attaquant. C’est un agent à qui l’on a demandé de changer quelque chose en staging et qui attrape la mauvaise clé d’environnement.

Vos données de flags entrent dans la conversation

Autant être clair : tout ce que l’agent lit devient une partie de sa conversation avec le service d’IA qu’il utilise, quel qu’il soit. Cela inclut les noms, clés et descriptions de flags écrits par votre équipe, et — si vous lui demandez de lire l’historique d’audit — les noms et adresses e-mail de vos coéquipiers.

Deux choses en découlent.

Traitez les descriptions de flags comme une entrée non fiable. Quiconque peut créer un flag peut taper n’importe quoi dans sa description, y compris un texte qui se lit comme une instruction pour l’agent. Le serveur dit à l’agent, d’emblée et à chaque outil, que ces valeurs sont les données de votre organisation et jamais des instructions. Cela aide ; ce n’est pas une garantie, et c’est une raison de réfléchir à quels flags un agent lit.

Nous ne pouvons ni voir ni gouverner cette transcription. Elle est entre vous et votre fournisseur d’IA. Rien dans la façon dont FortressFlag stocke ou transmet vos données ne change quand vous utilisez ceci — les outils ne sont qu’un client de plus de la même API.

Ce qui n’existe pas encore

• Il tourne uniquement en local. Le serveur parle à votre agent via son entrée et sa sortie standard, sur votre machine. Il n’y a pas de version hébergée vers laquelle pointer un agent distant.
• Pas encore de binaires téléchargeables — pour l’instant, il se compile depuis les sources.
• Les règles de ciblage et les segments ne sont pas modifiables par un agent. Lire les flags, les basculer et proposer des changements en production le sont ; l’éditeur de règles est une surface plus grande qui mérite son propre cycle de conception.
• Lister les propositions en attente demande la permission d’approbateur. Le jeton d’un Developer peut proposer un changement en production mais ne peut pas ensuite le lister — c’est la permission de l’API sous-jacente, pas une bizarrerie des outils.