Nutze FortressFlag aus einem KI-Agenten

Wenn du mit einem KI-Coding-Agenten arbeitest, kannst du ihm deine Flags geben. „Schalte new-checkout in der Produktion aus“ ist ein Satz mit einem exakten API-Aufruf dahinter — und einer, der deine echten Nutzer berührt, weshalb diese Anleitung genauso viel Zeit auf die Grenzen verwendet wie auf die Einrichtung.

FortressFlag liefert einen MCP-Server: ein kleines Programm, das auf deinem eigenen Rechner läuft, neben deinem Agenten, und ihm einen Satz Flag-Tools in die Hand gibt.

Was er kann und was nicht

Die Kurzfassung: Dein Agent kann genau das, was du kannst, und weniger.

Der Server hält ein API-Token, das als du handelt — deine Rolle, dein Projektzugriff, deine Organisation. Er spricht mit FortressFlag über dieselbe öffentliche API, die das Dashboard benutzt, sodass jede Berechtigungsprüfung, jede Projekt-Allowlist und jeder Audit-Eintrag identisch damit ist, dass du den Button klickst. Es gibt keinen speziellen Zugangspfad für Agenten.

Manche Dinge stehen einem Agenten bewusst überhaupt nicht zur Verfügung:

• Einen Produktionsvorschlag genehmigen. Der ganze Sinn eines zweiten Paars Augen ist, dass sie einer Person gehören.
• Ein Flag endgültig löschen.
• SDK-Schlüssel oder API-Tokens erstellen. Ein einmaliges Geheimnis, das an einen Agenten zurückgegeben wird, landet in einem Gesprächsprotokoll.
• Mitglieder, Abrechnung oder rechtliche Vereinbarungen verwalten.

Richte ihn ein

1. Erstelle ein Token. Geh im Dashboard auf deine Kontoseite und such API-Tokens. Gib ihm einen Namen, den du wiedererkennst, wähl einen Umfang und kopier das Token — es wird einmal angezeigt.

Wähl Nur Lesen, außer du willst, dass der Agent Änderungen vornimmt. Ein zweites Token kannst du jederzeit später erstellen.

2. Richte deinen Agenten auf den Server. Die meisten MCP-Clients nehmen einen kleinen Konfigurationsblock, der einen Befehl und seine Umgebung benennt:

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

Das Token gehört in env, nie in args — Kommandozeilenargumente sind für andere Nutzer auf einem geteilten Rechner sichtbar.

3. Füge --allow-writes hinzu, wenn du Änderungen willst. Ohne bietet der Server nur Lese-Tools an. Damit kann dein Agent Flags umschalten, anlegen, umbenennen, archivieren und wiederherstellen — weiterhin begrenzt durch das, was deine Rolle erlaubt:

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

Betrachte dieses Flag als Bequemlichkeit, nicht als Schloss. Wenn ein Agent nichts an Flags zu ändern hat, gib ihm zusätzlich ein Nur-Lesen-Token — das ist der Teil, den FortressFlag tatsächlich durchsetzt.

Die Produktion ist doppelt geschützt

Deine Rolle entscheidet zuerst. Wenn du Developer bist, kannst du die Produktion nicht direkt schreiben — also kann es dein Agent auch nicht. Was er kann, ist die Änderung vorschlagen, genau wie du: Ein zweites Teammitglied wendet sie an, und niemand kann den eigenen Vorschlag genehmigen. Siehe Produktionsfreigaben.

Das Tool fragt als Zweites noch einmal nach. Bevor er eine Produktionsumgebung anfasst, muss der Agent erklären, dass er das beabsichtigt, und die Umgebung benennen. Diese Prüfung liest die Produktionsklasse der Umgebung, nicht ihren Namen — eine Umgebung, die du live genannt hast, ist also genau so geschützt wie eine namens prod, und eine, die bloß prod heißt, aber keine Produktionsklasse hat, nervt dich nicht.

Diese zweite Prüfung existiert, weil der realistische Fehler kein Angreifer ist. Es ist ein Agent, der etwas in Staging ändern soll und nach dem falschen Umgebungs-Key greift.

Deine Flag-Daten gehen in das Gespräch

Um es klar zu sagen: Alles, was der Agent liest, wird Teil seines Gesprächs mit dem KI-Dienst, den er benutzt. Dazu gehören Flag-Namen, -Keys und -Beschreibungen, die dein Team geschrieben hat, und — wenn du ihn die Audit-Historie lesen lässt — die Namen und E-Mail-Adressen deiner Teammitglieder.

Zwei Dinge folgen daraus.

Behandle Flag-Beschreibungen als nicht vertrauenswürdige Eingabe. Jeder, der ein Flag anlegen kann, kann alles in seine Beschreibung tippen, auch Text, der sich wie eine Anweisung an den Agenten liest. Der Server sagt dem Agenten vorab und bei jedem Tool, dass diese Werte die Daten deiner Organisation sind und nie Anweisungen. Das hilft; es ist keine Garantie, und es ist ein Grund, sorgfältig zu überlegen, wessen Flags ein Agent liest.

Wir können dieses Protokoll weder sehen noch steuern. Es ist zwischen dir und deinem KI-Anbieter. Nichts daran, wie FortressFlag deine Daten speichert oder überträgt, ändert sich, wenn du das benutzt — die Tools sind nur ein weiterer Client derselben API.

Was es noch nicht gibt

• Er läuft nur lokal. Der Server spricht mit deinem Agenten über seine Standardein- und -ausgabe, auf deinem Rechner. Es gibt keine gehostete Version, auf die ein entfernter Agent zeigen könnte.
• Noch keine herunterladbaren Binaries — vorerst wird er aus dem Quellcode gebaut.
• Targeting-Regeln und Segmente sind für einen Agenten nicht bearbeitbar. Flags lesen, sie umschalten und Produktionsänderungen vorschlagen schon; der Regel-Editor ist eine größere Fläche, die ihre eigene Designrunde verdient.
• Offene Vorschläge aufzulisten braucht Genehmigungsberechtigung. Das Token eines Developers kann eine Produktionsänderung vorschlagen, sie dann aber nicht auflisten — das ist die Berechtigung der darunterliegenden API, keine Eigenheit der Tools.