Nur-Lese-Tokens und auf ein Projekt beschränkte MCP-Tokens für KI-Agenten

„Sollte ich einem KI-Agenten Zugriff auf meine Aufgabenliste geben?“ sind in Wahrheit drei getrennte Fragen, die sich als eine ausgeben: Wie viel kann er sehen, wie schnell kann ich ihm den Zugriff entziehen, wenn etwas nicht stimmt, und was braucht weiterhin meine Freigabe, auch während er verbunden ist? Keine davon hängt davon ab, welches Modell du verwendest. Es sind Eigenschaften davon, wie der Server den Zugriff durchsetzt, und nicht des Urteilsvermögens des Agenten.

Warum der Zugriffsumfang wichtiger ist als das Modell

Ein Agent kann nur tun, was seine Zugangsdaten ihm erlauben, egal wie fähig oder sorgfältig das Modell dahinter ist. Das ist eine bewusst langweilige, serverseitige Garantie und keine Hoffnung auf das Verhalten eines Modells. Aus demselben Grund würdest du den API-Schlüssel für jeden anderen Dienst auf genau das beschränken, was er braucht, und nicht auf alles, was er theoretisch anfassen könnte.

Vollzugriff, nur lesen oder ein einzelnes Projekt

Jedes Konto bekommt seinen eigenen MCP-Endpunkt und seine eigenen Tokens, nie einen geteilten oder globalen. In Pro und Teams lässt sich ein Token weiter einschränken: auf reinen Lesezugriff, sodass ein Agent die Warteschlange und den Kontext aus den Kommentaren sehen, aber nie etwas ändern kann, oder auf ein einzelnes Projekt, sodass er immer nur die Aufgaben dieses einen Projekts sieht und nichts vom Rest deines Kontos. Fang enger an, als du glaubst, es zu brauchen. Später zu erweitern ist einfach. Nachträglich einzuschränken heißt, einem Agenten zu vertrauen, der bereits weiteren Zugriff hatte.

Zugriff sofort entziehen

Wenn du ein Token neu erzeugst oder widerrufst, wird es sofort ungültig, ohne dass irgendwo erst ein Cache ablaufen muss. Und wenn du dich von etwas erholst, bei dem du dir nicht sicher bist: Das Ändern oder Zurücksetzen deines Passworts widerruft auf einen Schlag alle API-Zugangsdaten des Kontos, einschließlich der MCP-Tokens und der verbundenen Apps. Ein vermuteter Einbruch lässt also keinen Agentenzugriff still weiterleben, nachdem du das Passwort längst geändert hast.

Die Freigabe als zweite Leine

Beim Zugriffsumfang geht es darum, was ein Agent sehen und anfassen kann. Bei der Freigabe geht es darum, was er abschließen kann, ohne zu fragen. Eine als Auto-OK markierte Aufgabe kann direkt geschlossen werden, was für umkehrbare Arbeit mit geringem Risiko in Ordnung ist. Alles andere läuft über propose_completion und wartet auf Freigabe, bis ein Mensch zustimmt, und nur ein Mensch kann eine Aufgabe überhaupt als Auto-OK markieren. Die beiden Mechanismen decken unterschiedliche Risiken ab: Der Zugriffsumfang begrenzt, wie weit ein Schaden reichen kann, die Freigabe begrenzt, was unbeaufsichtigt endgültig wird.

Nachvollziehbare Läufe und Budgets

Jede Agentensitzung läuft als protokollierter Lauf mit einem eigenen Budget für Tool-Aufrufe und Zeit. check_budget sagt dir, wie viel übrig ist, bevor das Budget einer Sitzung aufgebraucht ist. Ist das Budget einer budgetierten Aufgabe erschöpft, wird start_run ganz abgelehnt, statt die Sitzung auf geliehener Zeit weiterlaufen zu lassen. Das ist ein dritter, unabhängiger Hebel. Er betrifft weder den Zugriff noch die Endgültigkeit, sondern wie viel eine einzelne Sitzung tun kann, bevor sie anhalten und sich zurückmelden muss.

Eine vernünftige Grundeinstellung

Starte einen Agenten mit reinem Lesezugriff oder auf ein einzelnes Projekt beschränkt, lass die meisten Aufgaben ohne Auto-OK und beobachte ein paar Läufe, bevor du irgendetwas davon lockerst. Erweitere den Umfang des Tokens oder fang an, Routineaufgaben als Auto-OK zu markieren, sobald du wirklich gesehen hast, was der Agent mit seinem Zugriff anfängt, und nicht vorher. Mit Misstrauen hat das nichts zu tun. Es ist dieselbe Haltung, mit der du eine neue Mitarbeiterin oder einen neuen Mitarbeiter in ein System einarbeiten würdest, in dem Fehler echte Folgen haben.