Wie man einem KI-Agenten Zugriff gibt, ohne die Kontrolle aufzugeben

Der schnelle Weg — dem Agenten Admin-Zugriff geben und die Details später klären — erzeugt genau den Explosionsradius, an dem Teams sich die Finger verbrennen. Hier ist das gestufte Modell, das das vermeidet, Zeile für Zeile geprüft an dem, was tatsächlich ausgeliefert wurde.

Der schnellste Weg, einen KI-Agenten an ein echtes System anzubinden, ist, ihm denselben Zugriff zu geben, den man einer neuen Mitarbeiterin am ersten Tag geben würde: volle Admin-Rechte, jedes Tool, Details später klären. Zugriff richtig zuzuschneiden braucht Zeit – jemand muss entscheiden, welche Tools der Agent anfassen darf, welche Daten er lesen darf und was er tun darf, ohne vorher nachzufragen. In einem kleinen Team, das ohnehin schon an der Kapazitätsgrenze arbeitet, will niemand die Person sein, die das verlangsamt. Also wird der Standard „gib ihm einfach Zugriff", und alle machen mit dem Nächsten weiter.

Dieser Instinkt ist falsch, und der Grund hat nichts damit zu tun, ob der Agent heute vertrauenswürdig wirkt. Es geht darum, was an dem Tag passiert, an dem er es nicht ist. Ein Agent mit Admin-Reichweite, der einen Routinefehler macht, eine vergiftete Anweisung untergeschoben bekommt, die in einem Dokument versteckt ist, das er lesen sollte, oder einfach selbstbewusst und falsch darüber ist, was ein Tool-Aufruf bewirken wird, hat jetzt die Reichweite eines Admins. Der Fehler ist keine schlechte Chatbot-Antwort, die man mit einem Achselzucken abtun kann – es ist der Explosionsradius eines kompromittierten Admin-Kontos, nur dass er in Maschinengeschwindigkeit handeln kann, über jedes System hinweg, das er berührt, ohne dass jemand in Echtzeit zusieht, um es zu stoppen, bevor sich der Schaden summiert.

Die Schichten, die den Explosionsradius tatsächlich eindämmen

Gutes Zugriffsdesign für einen KI-Agenten ist kein einzelner Schalter, den man umlegt. Es sind sechs separate Entscheidungen, die aufeinander aufbauen, wobei jede Schicht dazu da ist, eine bestimmte Art zu verhindern, wie der erste Fehler zu einem viel größeren wird. Eine Schicht auszulassen heißt nicht, dass man etwas vereinfacht hat – man hat den Ausfallpunkt nur an eine weniger sichtbare Stelle verschoben.

Keine dieser sechs Schichten ist exotisch. Jede schließt eine Lücke, die die Schicht darüber weit offen lässt – Identität allein stoppt keinen zu breiten Tool-Zugriff, und eine Tool-Allowlist allein stoppt keine stille, irreversible Aktion. Sie funktionieren nur gestapelt.

Identität: ein Login, kein Schatten-Login

Man beginnt mit der Identität, weil alles darüber davon abhängt. Wenn der Zugriff eines Agenten an ein Login gebunden ist, von dem die IT nicht weiß, dass es existiert, spielen alle späteren Schichten keine Rolle – man kann keine Genehmigung widerrufen, von der man nie wusste, dass sie existiert. FabricLoops Enterprise-Plan verdrahtet den Workspace über SSO und SAML mit dem Identitätsanbieter der Organisation – demselben Mechanismus, der bereits die Anmeldung für E-Mail und den Rest der Unternehmenssoftware steuert. Das ist speziell für den Agentenzugriff wichtig, weil es bedeutet, dass KI-Verbindungen und gewöhnlicher Kollaborationszugriff über eine einzige Identitätsgeschichte laufen statt über zwei. Wenn die IT jemanden im Identitätsanbieter deprovisioniert, entfernt diese eine Aktion den FabricLoop-Zugriff dieser Person und damit auch alle MCP-Verbindungen, die an ihr Login gebunden sind – statt eine verwaiste Agenten-Zugangsdaten zurückzulassen, an deren Aufräumen sich niemand erinnert.

Eine Genehmigung pro Person, in beide Richtungen

FabricLoops KI-Verbindungen laufen in zwei Richtungen, und dasselbe Prinzip – kein geteiltes, team-weites Zugangsdatum – gilt für beide.

Eingehend bedeutet, dass sich ein externes Tool wie Cursor, Claude oder ChatGPT als MCP-Client mit FabricLoop verbindet, um mit den tatsächlichen Berechtigungen einer Person Aufgaben, Notizen und Nachrichten zu lesen oder zu schreiben. FabricLoops eigene Setup-Anleitung ist ausdrücklich, dass dies ein Prozess pro Person ist: Jede Person öffnet den Zustimmungsbildschirm unter app.fabricloop.com/oauth/consent, wählt den Workspace aus und genehmigt die spezifischen Tool-Scopes, die dieser Client erhält – kein workspace-weiter Schalter, den ein Admin einmal für alle umlegt. Die Anleitung für Teams nennt direkt den Fehlerfall, den das verhindern soll: den Zugangstoken einer Person nicht im Team teilen, weil jede Person ihre eigene Zustimmung abschließen soll. Das Ergebnis ist eine Liste verbundener Clients, die pro Person sichtbar und pro Person widerrufbar ist – kein Zugangstoken, das in einer Konfigurationsdatei vergraben ist und den Grund seiner Erstellung überlebt.

Ausgehend ist der Spiegelfall: FabricLoop verbindet sich mit einer Drittanbieter-App aus seinem eigenen MCP-Katalog, etwa einem Projekt-Tracker oder einem Kalendertool. Hier ist die Aufteilung bewusst gewählt. Ein Admin aktiviert die App für den gesamten Workspace – eine Entscheidung darüber, ob das Tool überhaupt in der Organisation existieren darf – und danach verbindet jede Person, die es nutzen möchte, ihr eigenes individuelles Konto. Ein Admin, der diesen Schalter umlegt, übergibt nicht die Identität jedes Mitarbeiters an die App; er macht die Option nur verfügbar, und jede Person muss sich trotzdem als sich selbst authentifizieren, bevor die Verbindung irgendetwas tut.

Scope: nur lesen oder eine Allowlist – kein Alles-oder-nichts

Identität beantwortet die Frage nach dem Wer. Genehmigungen pro Person beantworten, wessen Konto es ist. Keine der beiden beantwortet die Frage, die die tatsächliche Größe eines Fehlers bestimmt: was die Verbindung tun kann, sobald sie live ist. Das ist die Aufgabe der dritten Schicht.

Auf dem Detailbildschirm jeder verbundenen App kann ein Admin einen Anzeigenamen festlegen, den Nur-Lese-Modus aktivieren und eine Tool-Richtlinie wählen – entweder jedes verfügbare Tool oder eine spezifische Allowlist. Das ist der Unterschied zwischen „dieser Agent kann unser Aufgabenboard lesen" und „dieser Agent kann unser Aufgabenboard lesen und außerdem Einträge löschen, Verantwortliche neu zuweisen und in jedem Kanal posten." Die meisten Verbindungen brauchen die zweite Version nicht, und die meisten Horrorgeschichten darüber, wie ein Agentenzugriff so schiefgeht, wie Leute es befürchten, beginnen mit einer Verbindung, der standardmäßig jedes Tool gewährt wurde, weil niemand daran dachte, die Box anzukreuzen, die das einschränkt.

FabricLoops Security-Seite beschreibt die resultierenden Genehmigungen als „scoped" und ausdrücklich als „keinen permanenten, unsichtbaren Zugriff" – auditiert und widerrufbar, dieselbe Sprache, die das Unternehmen auf seiner Seite zur Erklärung von Legibility verwendet, der Idee, dass KI-Zugriff etwas sein sollte, das man benennen und prüfen kann, statt Stammeswissen darüber, welches alte Bot-Token noch funktioniert.

Laufzeitverhalten: der Agent entwirft, eine Person sendet

Alles oberhalb dieser Schicht steuert, was ein Agent erreichen kann. Diese hier steuert, was er tun darf, sobald er dort angekommen ist – und es ist die Schicht, die die meisten Teams auslassen, weil sie sich am langsamsten anfühlt.

FabricLoops eingebauter Assistent, Loop, ist um eine Einschränkung aufgebaut, die das Unternehmen in seiner eigenen Produktdokumentation klar formuliert: „Loop entwirft; du sendest. Er postet nicht selbst in einen Kanal und benachrichtigt niemanden von sich aus." Bittet man ihn, einen Thread zusammenzufassen, fasst er zusammen. Bittet man ihn, ein Update zu schreiben, schreibt er einen Entwurf – und eine Person muss ihn trotzdem prüfen und senden, bevor jemand anderes ihn sieht. Dasselbe Muster gilt für Agenten, die als Teammitglieder in einem Kanal leben: Wenn einer dieser Agenten auf eine Entscheidung einer Person wartet, rät er nicht und macht einfach weiter. Er erscheint unter „Wartet auf dich" im Tab „Apps & Agenten" dieses Kanals – genau die Oberfläche, die das Team bereits prüft, keine separate Konsole, an die sich niemand mehr erinnert.

Das ist die praktische Form dessen, was die Fachliteratur zu Agenten-Frameworks ein ask_human-/resume-Muster nennt: Der Agent pausiert an dem Punkt, an dem Urteilsvermögen gefragt ist, fragt nach und macht erst weiter, sobald eine Person antwortet. FabricLoop fasst die zugrundeliegende Idee als Quote für menschliche Eingriffe – nicht als „wie oft braucht der Agent einen Menschen", das man als Fehler wegoptimieren müsste, sondern als eine Zahl, die jedes Team, das Agenten betreibt, tatsächlich messen und dafür designen sollte, statt sie zum ersten Mal während eines Vorfalls zu entdecken.

Der Schutzschalter: ein Ausgabenlimit, das Läufe wirklich stoppt

Zugriffskontrolle betrifft nicht nur, was ein Agent lesen oder ändern kann. Es geht auch darum, was er kosten kann – und ein außer Kontrolle geratener Agent muss nichts Sensibles berühren, um echten Schaden anzurichten, wenn er in einer Schleife, die niemand beobachtet, teure Modellaufrufe macht.

Admins auf FabricLoops kostenpflichtigen Plänen legen unter Nutzung & Abrechnung ein monatliches Ausgabenlimit für Agentennutzung fest und können einen harten Stopp aktivieren, der neue Agentenarbeit automatisch pausiert, sobald die Ausgaben diese Zahl erreichen. Das ist ein echter Schutzschalter, kein Monitoring-Dashboard: der Unterschied zwischen dem Bemerken, dass die Rechnung am Monatsende hoch war, und neuen Agentenläufen, die sich selbst stoppen, in dem Moment, in dem sie die von jemandem festgelegte Zahl überschreiten. Kostenlose Workspaces bekommen kein Dollarlimit, weil es keine Produktionsausgaben gibt, die man begrenzen müsste – sie laufen stattdessen mit enthaltenen, nur zum Testen gedachten Credits, was für sich genommen eine Scope-Beschränkung ist, nur anders durchgesetzt. In einem kostenpflichtigen Plan ist das Anheben des Limits der einzige Weg, um nach einem harten Stopp fortzufahren, und das ist genau die Reibung, die man in diesem Moment will: Jemand muss aktiv entscheiden, mehr auszugeben, statt dass das System still auf unbegrenzt zurückfällt.

Audit und Widerruf: eine Person oder alle auf einmal

Die letzte Schicht geht davon aus, dass die ersten fünf irgendwann irgendwo für irgendjemanden versagen werden, und fragt, was dann passiert.

FabricLoop trennt zwei Arten des Widerrufs, und dieser Unterschied ist wichtig. „Meine Verbindung widerrufen" steht jeder einzelnen Person zur Verfügung und trennt sofort nur den Zugriff dieser Person – das Tool funktioniert für sie nicht mehr, ohne dass es irgendjemand anderen im Team betrifft, der ebenfalls verbunden ist. „App für den Workspace deaktivieren" ist nur für Admins und die weiterreichende Aktion: Sie archiviert die App vollständig und widerruft alle Verbindungen zu ihr auf einmal, für den Fall, dass das Problem nicht das Konto einer Person, sondern die App selbst ist. Dieselbe Aufteilung existiert auf der eingehenden Seite, wo jede Person einen von ihr verbundenen MCP-Client sofort unter Einstellungen → KI / MCP widerrufen kann.

Nichts davon spielt eine Rolle ohne Einblick in das, was passiert ist, bevor sich jemand entschied, den Stecker zu ziehen. FabricLoops Enterprise-Audit-Logs sind nicht nur eine Login-Historie – das Unternehmen beschreibt sie als Abdeckung von Admin- und Agentenaktivität, und seine eigenen Materialien zum Legibility-Konzept nennen „MCP-Audit-Events" ausdrücklich als etwas, das Sicherheitsteams überprüfen können, nicht nur aus dem Kontext ableiten müssen. Das ist der Unterschied zwischen einem Sicherheitsteam, das fragt „hat hier jemand etwas angefasst?" und eine echte Antwort erhält, und dem Rekonstruieren einer Zeitlinie aus alten Nachrichten und der Erinnerung jemandes daran, was ein Agent an diesem Nachmittag zu tun schien.

Was FabricLoop sagt, ist noch nicht wahr

Jede Behauptung oben ist etwas, das FabricLoop tatsächlich ausgeliefert hat. Es lohnt sich, genauso klar darüber zu sein, was noch nicht ausgeliefert wurde, denn ein Unternehmen, das nur die erste Hälfte erzählt, bittet einen darum, ihm blind zu vertrauen – und blindes Vertrauen ist nicht das, was eine legible Sicherheitshaltung bedeutet.

FabricLoops eigene Security-Seite listet auf, was heute wahr ist, und dann einen separaten Abschnitt, schlicht mit „Noch nicht vorhanden" überschrieben, der drei konkrete Lücken benennt: SOC-2- oder ISO-27001-Zertifizierung, Penetrationstests durch Dritte und SCIM-Provisioning. Die Formulierung der Seite ist für eine Anbieter-Security-Seite ungewöhnlich direkt: Statt jede Zertifizierung aufzulisten, die andere Anbieter haben, sagt sie: Hier ist genau das, was gerade jetzt wahr ist – und was noch nicht vorhanden ist, weil das Unternehmen es lieber klar sagt, als einen Kunden es später herausfinden zu lassen.

Für ein Team, das abwägt, ob es einen Agenten mit echten Unternehmensdaten verbinden soll, sind das keine vagen Risiken – es sind drei benannte, überprüfbare Punkte, die man in einem Sicherheitsreview ansprechen, verfolgen und vor der Verlängerung nachverfolgen kann. Eine benannte Liste von Lücken ist mehr wert als eine vage Zusicherung, dass alles in Ordnung ist, gerade weil sie überprüfbar ist. Das ist dasselbe Argument, das hinter Legibility als Konzept steht: Zugriff und Sicherheitsstatus, die man benennen und verifizieren kann, schlagen Zugriff und Sicherheitsstatus, denen man einfach vertrauen soll.