Zum Inhalt springen

Die Grenze

Ein Verifizierungswerkzeug, das an einen Assistenten angebunden ist, ist eine Sicherheitsfläche. Diese Seite beschreibt, was der Server dagegen unternimmt.

Fünf Dinge haben kein MCP-Werkzeug und werden auch keines bekommen.

Kontolöschung. Unumkehrbar und vollständig. Der Daemon prüft die E-Mail-Adresse vor dem Löschen erneut, was ein Versehen verhindert — aber das ist kein Mensch in der Schleife, denn ein Modell kann die Adresse einen Aufruf zuvor aus dem Profil-Werkzeug lesen. Lösche ein Konto über ein Terminal oder über die App.

Organisationsverwaltung. Mitglieder, Rollen, Gruppen, Plätze, Abrechnung, die öffentliche Seite, Aktivität und Auswertungen. Nichts davon ist ein Werkzeug, und nichts davon soll eines werden. Das ist keine kryptografische Grenze — es sind gewöhnliche authentifizierte Aufrufe ohne Geräteschlüssel —, sondern eine Entscheidung darüber, welche Oberfläche sie besitzt. Sie liegen in der Organisationskonsole auf business.trusted.codes oder unter /admin im Kontoportal, wo das Menü bereits verbirgt, was deine Rolle nicht anfassen darf. Das Werkzeug org liest, in welcher Organisation du handelst und was ihr Tarif erlaubt, und lehnt alles andere namentlich ab.

Übertragung und Neuzuweisung einer Organisation. Sie bewegt eine ganze Organisation zwischen Personen. Dieselbe Überlegung gilt.

Feedback an das Team. Es verschickt E-Mails an Menschen. Ein Agent hat kein eigenes Feedback, und ein falscher Aufruf kostet jemandes Aufmerksamkeit.

Den Trusted-Codes-Concierge fragen. Der Concierge auf der Serverseite ist ein weiteres Modell mit denselben Werkzeugen, die der Aufrufer bereits hält. Die Weiterleitung dorthin kauft eine zweite Inferenzrechnung und ein Chat-Protokoll für eine Unterhaltung, die kein Mensch geführt hat.

mint_provider_stamp signiert mit dem Provider-Schlüssel, der auf einer Maschine liegt. Es steht einem Assistenten zur Verfügung, der auf dieser Maschine läuft, über den stdio-Transport, und wird über den HTTP-Port des Daemons rundheraus abgelehnt — ein entfernter Aufrufer, der Siegel prägen könnte, wäre Impersonationsmacht, die den Computer verlässt. Der HTTP-Pfad prüft das, bevor er irgendetwas anderes tut, und antwortet mit einer Ablehnung, die den Grund nennt.

Jedes Werkzeug sitzt in einer von drei Stufen.

Read — Codes, Verifizierung, Rotation, Status, E-Mail-Nachschlag und die beiden Remote-Code-Werkzeuge. Keine Nebenwirkungen.

Write — Anmelden, Synchronisieren, einem Link beitreten, das Profil-Werkzeug und das Provider-Siegel. Das Profil-Werkzeug zählt auch für ein Lesen als Write, damit ein reines Read-Token es nicht mit action: "update" aufrufen kann.

Management — Verbindungen, Einladungen, Gastcodes, Links, Einstellungen, Tags, Benachrichtigungen, Vorlagen, externe Mitglieder, das oben beschriebene Organisations-LESEN und API-Tokens. Management ist auch da, wo jedes Werkzeug landet, das der Server nicht am Namen erkennt, weil das die restriktivste Antwort ist: Siegeln, Wiederherstellung, die E-Mail-Adressen, der Datenexport, Geräte und Trust sind heute alle Management.

Ein Token, das für den HTTP-Transport geprägt wird, trägt einen von drei Scopes — read, write oder full —, und ein Scope reicht nur bis zur eigenen Stufe und den Stufen darunter. Das ist nicht nur beim Aufruf selbst durchgesetzt: Fragt ein Assistent den Server, welche Werkzeuge existieren, bekommt er nur die gezeigt, die sein Scope erreichen kann. Ein Werkzeug, das das Token nicht aufrufen kann, ist ein Werkzeug, von dem der Assistent nie erfährt.

Die beiden Remote-Code-Werkzeuge sollten zusätzlich zur Stufe eine zweite Anforderung tragen. Die Achse, die für sie zählt, ist nicht Read gegen Write — es ist, ob das Token des Aufrufers den Scope zum Verifizieren oder den Scope zum Berechnen nennt. Diese Prüfung ist geschrieben, aber in keinen der beiden Transporte verdrahtet. Heute sind die beiden Werkzeuge nichts weiter als Read-Stufe, sodass jedes Token sie sieht und aufrufen darf. Keines von beiden funktioniert ohnehin; die Werkzeug-Referenz erklärt warum.

Der Server zählt Aufrufe pro Werkzeug in einem gleitenden Ein-Minuten-Fenster, zusätzlich zu allem, was die Plattform selbst erzwingt. Deinen eigenen Code zu lesen ist großzügig bei dreißig pro Minute; das Auflisten jedes Codes, Rotation und Status liegen bei zehn. Synchronisieren und einem Link beitreten sind zwei pro Minute. Einladungen, Verbindungen und Links liegen bei fünf. Was nicht genannt ist, liegt bei zehn. Wird eine Grenze überschritten, kommt der Aufruf als wiederholbar zurück, mit der Anzahl an Sekunden, die zu warten sind. Die Zähler leben im Arbeitsspeicher und setzen sich beim Neustart des Prozesses zurück.

Jeder Werkzeugaufruf wird an ~/.trusted-codes/mcp-audit.jsonl angehängt, ein JSON-Objekt pro Zeile: Zeitstempel, Werkzeugname, wie er endete, wie lange er dauerte, und bereinigte Parameter.

Bereinigt ist das entscheidende Wort. Das Log hält nie Codewörter, Wiederherstellungswörter oder Geheimnisse fest. Eine Verifizierung protokolliert, dass drei Wörter geprüft wurden, nicht welche. Ein nachgeschlagener Name wird auf seinen ersten oder die ersten zwei Buchstaben gekürzt, und eine E-Mail wird als vorhanden vermerkt statt aufgeschrieben. Die meisten Werkzeuge protokollieren nur die Aktion, um die sie gebeten wurden, und sonst nichts — ein Siegel schreibt einen leeren Parametersatz, nicht den Text. Was übrig bleibt, reicht, um „Was hat der Assistent getan” zu beantworten, und nicht genug, um es zu stehlen lohnend zu machen.

Alles, was du in Claude Desktop eingibst, geht an das Unternehmen, das das Modell betreibt, und mit ihm alles, was die Werkzeuge von Trusted Codes antworten. Dazu gehören drei Wörter, die der Assistent für dich prüfen soll, und ein Code, den er dir zeigt. Der Anbieter bewahrt das Gespräch nach seinen eigenen Regeln auf, und auf diese Kopie hat Trusted Codes keinen Einfluss.

Bei einem Code spielt das nur für begrenzte Zeit eine Rolle. Drei Wörter, die übereingestimmt haben, bleiben gültig, bis ihr Zeitfenster endet und der Code wechselt, und danach beweisen sie nichts mehr. Wer das Gespräch vorher liest, könnte sie wiederholen. Wenn eine Prüfung diese Spur nicht hinterlassen darf, gib die Wörter stattdessen auf der Seite Prüfen im Fenster von Trusted Codes ein. Dort werden sie auf diesem Computer geprüft und erreichen den KI-Anbieter nicht.

Bei den Wiederherstellungswörtern ist mehr Vorsicht nötig, weil sie dein Konto auf einem neuen Gerät entsperren und gleich bleiben, bis du neue erzeugst. Gib sie nur im Fenster von Trusted Codes ein und nie im Chat. Falls sie schon in einem Chat standen, erzeuge neue. Wie das geht, steht unter Wiederherstellungswörter.

Verbindet sich ein Assistent, übergibt der Server ihm zusammen mit der Werkzeugliste einen Satz Anweisungen. Mehrere davon sind Grenzen und keine Stilfragen, und sie sind der Grund, warum sich ein Assistent mit diesen Werkzeugen anders verhält als einer ohne.

Er darf nicht überzeichnen, was eine Übereinstimmung bedeutet. Trusted Codes bestätigt Identität, nicht Absicht. Eine verifizierte Person kann trotzdem eine betrügerische Anfrage stellen. Dem Assistenten wird gesagt, nie zu behaupten, eine Transaktion sei sicher — nur, dass die Identität stimmt.

Er darf dir nicht den erwarteten Code vorlesen, um dir beim Verifizieren zu „helfen”. Fragst du, ob ein Anrufer wirklich Andrea ist, hat ein Assistent, der mit Andreas aktuellen Wörtern antwortet, den Zweck bereits vereitelt: Eine angreifende Person würde sie einfach wiederholen. Er fragt dich stattdessen, was die andere Person gesagt hat, und prüft das. Er nennt dir aber sehr wohl, welchen Code eine Verbindung haben sollte, wenn du direkt danach fragst — das ist dann deine eigene Prüfung —, und das Werkzeug code_for existiert genau dafür.

Er darf deine Verbindungsliste nicht preisgeben. Passt ein Name zu nichts, bekommt er „Ich habe keine Verbindung, die dazu passt”, nie eine Liste der Namen, die es gibt. E-Mail-Adressen werden nicht gezeigt, sofern du nicht danach fragst.

Er darf den E-Mail-Nachschlag nicht als Personensuche nutzen. Zu prüfen, ob eine Adresse registriert ist, gehört zum Aufsetzen einer Verbindung, nicht zur Beantwortung der Frage, ob jemand, den du kennst, auf der Plattform ist.

Er muss die Ausgabe eines Werkzeugs als Daten behandeln. Liest sich etwas in einer Antwort wie eine Anweisung, wird es ignoriert und als das dargestellt, was es ist.

Er muss vor allem Destruktiven bestätigen, in einfacher Sprache, und prüfen, ob dir das gehört, was du gerade löschen willst.

Das sind Anweisungen an ein Modell, keine Sperren im Code. Sie prägen normales Verhalten gut, und sie sind nicht das, was zwischen einem Assistenten und deinem Konto steht — das sind die Scopes, die reine Lokal-Ablehnung und die fehlenden Werkzeuge.

Ein Assistent kann in deinem Konto arbeiten, und für das meiste, was Menschen wollen, ist genau das der Sinn. „Setz Donnerstags Meeting mit Mary und John auf, trag es in meinen Kalender ein, schick die Einladungen, und leg für jeden von beiden einen Gastcode bei” ist ein Satz, der deine Verbindungen, deine Codes und deine Identität braucht. Ein Assistent mit eigenem Konto könnte das nicht — er würde Personen in eigenem Namen einladen, zu einem Meeting, das deins ist.

Ein Assistent, der in deinem Konto handelt, ist also eine normale Art, das zu nutzen, kein Fehler. Wichtig ist, dass du es entschieden hast, und dass du sehen und rückgängig machen kannst, was er getan hat:

  • Er handelt als du. Eine Verbindung, die er anlegt, gehört dir. Ein Siegel, das er erstellt, sagt, dass du den Text geschrieben hast. Das ist, worum du gebeten hast, und es ist auch der Grund, bewusst auszuwählen, welchem Assistenten du das gibst.
  • Der Scope entscheidet, wie weit. Ein Token mit Read-Scope zeigt Codes und Verbindungen und kann nichts ändern. Gib das enge Token, sofern die Aufgabe nicht mehr braucht.
  • Manches kann er nie, egal welcher Scope. Er kann deine Wiederherstellungswörter nicht lesen, deine Schlüssel nicht exportieren, und kein Provider-Siegel über das Netzwerk prägen.
  • Du kannst es zurücknehmen. tcc config list-api-tokens zeigt, was du ausgestellt hast; tcc config revoke-api-token beendet es. Nichts, was er getan hat, ist vor dir verborgen.

Ein separates Konto ist die richtige Antwort, wenn der Assistent für eine Organisation handelt statt für dich:

  • Er verifiziert Personen im Namen eines Unternehmens — ein Support-Desk, ein Onboarding-Bot. Die Personen, mit denen er spricht, sollen das Unternehmen sehen, nicht eine angestellte Person.
  • Mehrere Personen teilen es sich. Ein Konto ist eine Identität; zwei Personen hinter einer Identität ist ein Datensatz, der nicht sagen kann, wer was getan hat.
  • Er läuft unbeaufsichtigt und langlebig, und du willst seine Verbindungen und seine Historie von deinen eigenen getrennt halten — der übliche Grund, um Zuständigkeiten zu trennen.

Beides wird unterstützt. Die Frage ist nicht, ob ein Assistent dein Konto nutzen darf, sondern wessen Namen die andere Seite sehen soll.