Ein Carbon-Forge-MCP-Token auf einen Agenten zuschneiden

Auch auf: English, Español, Português, 日本語, Français, 한국어, 简体中文, Italiano, हिन्दी · Alle Anleitungen auf Deutsch

Offenlegung: Wir entwickeln Carbon Forge bei 100monkeys.ai, lesen Sie dies also als Bericht des Herstellers. Einer unserer KI-Agenten hat diese Anleitung aus der öffentlichen Dokumentation (auf Englisch) entworfen, vor allem MCP token scopes (R#62460), MCP tokens (R#61824) und der Tokens-Katalogseite (R#62188), und das Unternehmen hat sie geprüft; diese deutsche Fassung ist eine Übersetzung der englischen Originalanleitung. Preset-Namen, Argumente und zitierte Sätze stammen aus der Dokumentation; sie gibt keinen durchgearbeiteten Mint-Aufruf, daher steht hier die Argumentliste statt eines Beispiels. Zitate bleiben auf Englisch, mit der Übersetzung daneben. Wo die Dokumentation eine Frage offen lässt, sagt es der letzte Abschnitt.

Zwei Grenzen auf jedem Token

Ein Token trägt eine Rollengrenze (viewer, editor oder admin) und einen Werkzeugbereich, "the explicit set of MCP tools the bearer is allowed to call." (die ausdrückliche Menge von MCP-Werkzeugen, die der Inhaber aufrufen darf.) Die Rollengrenze ist die Obergrenze der Berechtigung; der Bereich grenzt sie weiter ein. Das Beispiel der Dokumentation: Ein SCM-reader-Bereich auf einem admin-Token liefert denselben Werkzeugkatalog wie derselbe Bereich auf einem viewer-Token.

Schritt 1. Festlegen, was der Agent tun muss

Schreiben Sie die Aufgabe des Agenten in einer Zeile auf, bevor Sie das Formular öffnen: abrufen und schlussfolgern, Notizen führen, Code lesen, auf einer Lane bauen oder releasen. Jede entspricht einem Preset unten. Die Regel der Dokumentation: "Default to the narrowest preset that still covers what the client needs." (Nehmen Sie standardmäßig das engste Preset, das noch abdeckt, was der Client braucht.)

Schritt 2. Die Rollengrenze setzen

Öffnen Sie die Einstellungen, wählen Sie API tokens und dann den Workspace und eine Rollengrenze. Die SCM-Presets nennen die Rolle, zu der sie passen: SCM reader zu viewer, SCM agent und SCM release zu editor.

Schritt 3. Das engste Preset wählen

Die Presets, mit den Werkzeugzahlen der Dokumentation (jedes enthält cortex.ground):

• Read-only memory (read_only_memory, 14): Seiten und Atome lesen, suchen, Querverweisen folgen; keine Schreibzugriffe.
• Basic LLM memory (basic_memory, 30): Seiten, Atome und Tags lesen und schreiben, und suchen.
• Knowledge-graph reader (knowledge_graph_reader, 31): jede Inhaltsoberfläche und der Graph, keine Schreibzugriffe.
• SCM reader (scm_reader, 58): Code-Bäume, Lanes, Changesets, Cuts und der Dateibaum, mit Seiten und Suche; keine Schreibzugriffe.
• SCM agent (scm_agent, 104): die SCM-Lesezugriffe plus Seiten, Atome, Lanes und Bäume schreiben, Lanes landen, Cuts setzen und rendern.
• SCM release (scm_release, 67): die SCM-Lesezugriffe plus Lanes landen und freigeben, Cuts setzen, Archive pushen und eine Site veröffentlichen.
• Full access (full, 177): jedes Werkzeug, innerhalb der Rollengrenze.

Ein Coding-Agent, der auf einer Lane baut, bekommt SCM agent; der Prüfer, der freigibt, SCM release; ein Recherche-Agent einen Reader. Full access behält die Dokumentation einem Client vor, der "trusted with anything the role can do" (mit allem betraut ist, was die Rolle kann).

Schritt 4. Custom für ein zusätzliches Werkzeug nutzen

Fehlt einem Preset ein Werkzeug, wählen Sie Custom und suchen Werkzeuge in der gruppierten Auswahl aus. Das Beispiel der Dokumentation ist ein Veröffentlichungs-Agent, "that should be able to create comments but not pages" (der Kommentare anlegen können soll, aber keine Seiten). Der Bereich wird in der Werkzeugliste, im Manifest unter /api/mcp/manifest und bei jedem Aufruf durchgesetzt. Ein Werkzeug außerhalb antwortet Unknown tool: <name>, "exactly as a tool that does not exist" (genau wie ein Werkzeug, das es nicht gibt), sodass ein Client nicht erfahren kann, was seinem Token fehlt.

Schritt 5. Das Token erzeugen und das Secret aufbewahren

Benennen Sie das Token nach dem Agenten oder der Umgebung, die es hält, und kopieren Sie dann das Secret: "it is shown once, then only the prefix." (es wird einmal angezeigt, danach nur noch das Präfix.) Jedes Token behält seinen eigenen aktuellen Workspace, sodass zwei Agenten mit zwei Tokens nicht gegenseitig ihren Zeiger verschieben.

Schritt 6. Ausführungs-Tokens nur für einen Orchestrator erlauben

Ein Ausführungs-Token ist "a short-lived child of one of your tokens, minted for a single AEGIS run" (ein kurzlebiges Kind eines Ihrer Tokens, erzeugt für einen einzigen AEGIS-Lauf), wobei AEGIS by 100monkeys.ai, in beta, der Orchestrator ist, der den Agenten ausführt. Ein Token kann nur dann Kinder erzeugen, wenn sein Besitzer im Token-Formular May mint execution tokens ankreuzt. Das ist standardmäßig aus, kein Preset setzt es, und die Dokumentation sagt, "leave it off unless an orchestrator holds the token." (lassen Sie es aus, außer ein Orchestrator hält das Token.) Das Mint-Werkzeug steht nur im Preset full.

Schritt 7. Ein Kind-Token für einen Lauf erzeugen

Das Eltern-Token ruft tokens.mint_execution mit diesen Argumenten auf:

execution_id, instance_id, workspace_id, tree_path, lane_label, tools, role_cap, lifetime_seconds, workflow

Eine Instanz, ein Workspace, ein Baumpfad, ein Lane-Label, 1 bis 166 Werkzeuge, die das Eltern-Token hat, eine Rollengrenze gleich der des Eltern-Tokens oder viewer, und eine Lebensdauer von höchstens 86.400 Sekunden, die nie über den Ablauf des Eltern-Tokens hinausgeht. workflow ist optional: der Name des Gates einer Landing-Regel, das der Lauf ausführt. Die Antwort:

{ token_id, parent_token_id, execution_id, instance_id, workspace_id, tree_path, lane_label, workflow, role_cap, tools, expires_at, secret }

Jede Erweiterung wird mit einem Satz abgelehnt und erzeugt nichts. Jeder Schreibzugriff des Kindes muss seine Lane nennen und unter seinem Pfad bleiben; die Ablehnungen der Dokumentation für die Lane forge/run-1 und den Pfad apps/web:

This execution token writes only to lane "forge/run-1", not to the trunk.
This execution token writes only under "apps/web", not to "apps/api/x.ts".

Ein Kind ist nie eine zweite Identität: Jede Änderung, die es macht, verzeichnet Sie als Akteur und den Lauf, für den es erzeugt wurde.

Schritt 8. Widerrufen und das Audit-Log lesen

Das Kind widerruft sich selbst, oder sein Eltern-Token widerruft es, mit tokens.revoke_execution; es authentifiziert sofort nicht mehr auf dem Server, der es widerrufen hat, und innerhalb von 30 Sekunden überall. Das Eltern-Token zu widerrufen oder seinen Bereich zu ändern, widerruft jedes Kind. Jeder Werkzeugaufruf landet im Audit-Log unter der Token-Identität, und jedes Erzeugen und Widerrufen schreibt eine Audit-Zeile, die Eltern, Kind und Lauf nennt.

Damit die Freigabe eines Laufs auf einem geschützten Trunk zählt, lesen Sie unsere Anleitung Landing-Regeln: Code-Owner im Datensatz, mit einem AEGIS-Workflow als Gate.

Was die Dokumentation offen lässt

• Ein durchgearbeitetes Beispiel. Der Katalog nennt Argumente und Antwort des Mint-Aufrufs, zeigt aber keinen Beispielaufruf.
• Die Werkzeug-Obergrenze. Ein Kind nimmt 1 bis 166 Werkzeuge, während das Preset full 177 enthält; welche Werkzeuge nicht an ein Kind gehen können, ist nicht aufgeführt.
• Wie ein Orchestrator das Eltern-Token erhält. Die Dokumentation sagt, das Erzeugen nur zu erlauben, wenn ein Orchestrator das Token hält, aber nicht, wie AEGIS dieses Token bekommt.
• Wo die Preset-Listen stehen. Die Zahlen sind angegeben; die Werkzeugnamen je Preset stehen nur in der Auswahl des Formulars.