Ein Agent, der einen MCP-Server aufrufen, einen Shell-Befehl ausführen, ein Repository lesen oder Arbeit an einen anderen Agent delegieren kann, hat eine wichtige Grenze überschritten: Er erzeugt nicht mehr nur Text. Er kann Wirkungen in anderen Systemen anfordern.

Damit ist „Welche Tools sind verfügbar?“ die falsche erste Sicherheitsfrage. Schwieriger ist: Was steht zwischen der Anfrage eines Modells und einer tatsächlichen Wirkung – und hält diese Kontrolle noch, wenn sich Workspace, Executor, Berechtigungszustand oder delegierter Agent ändern?

Die Antwort ist Capability Mediation. Das ist ein Architekturmuster, bei dem jede relevante Fähigkeit eines Agent durch einen expliziten Kontrollpunkt läuft, bevor sie ausgeführt wird – und bei Bedarf erneut, bevor ihr Ergebnis in den Context des Modells gelangt. Der Kontrollpunkt kann einen Vorgang erlauben, ablehnen, einschränken, verändern, protokollieren, begrenzen oder eine Freigabe verlangen. Er bewertet die Anfrage in ihrem tatsächlichen Ausführungskontext, statt eine Tool-Beschreibung als dauerhafte Berechtigung zu behandeln.

Einfach gesagt: Ein Tool ist keine Berechtigung. Capability Mediation macht aus der Anfrage eines Agent entweder eine eng begrenzte reale Aktion – oder gar keine.

Das ist kein neues, für KI umbenanntes Sicherheitsprinzip. Es folgt der Logik eines Reference Monitor: eines Kontrollpunkts, der sicherheitsrelevante Zugriffe vollständig sehen, gegen Manipulation geschützt sein und anhand von Policy entscheiden muss. Bei Agent-Systemen ist das in der Praxis komplizierter, weil es mehrere Mediatoren geben kann: eine Agent-Runtime, ein MCP-Gateway, ein Remote-Executor, eine Sandbox und ein Identity-Service. Ein Design ist nur so stark wie der Pfad, der alle diese Kontrollen umgeht.

Warum das jetzt wichtig ist

Das Model Context Protocol (MCP) trennt Tools, Resources und Prompts als unterschiedliche Fähigkeiten. Seine Spezifikation verlangt außerdem User Consent und Authorization Controls für Datenzugriffe und Operationen. MCP-Spezifikation Diese Trennung ist nützlich, aber Protocol Discovery ist noch keine Enforcement-Architektur.

Codex 0.151.0, veröffentlicht am 29. August, macht das operative Problem sichtbar. Extensions können MCP-Tool-Ergebnisse prüfen oder ersetzen, bevor sie das Modell erreichen. Die Version erhält außerdem wiederhergestellte Permission Profiles über TUI-Turns hinweg, verhindert, dass /cd Sandbox-Beschränkungen abschwächt, nutzt für die Sandbox Enforcement das tatsächliche Home Directory, Betriebssystem und die Path Conventions des Remote-Executors, rechnet Token-Nutzung verschachtelter Subagents auf Budgets des Root Goal an und verhindert, dass veraltete Guardian-Klassifikationen nach Änderungen des Permission State Aktionen autorisieren. Codex 0.151.0

Das sind nicht einzelne Features namens „Sicherheit“. Es sind Fehler an unterschiedlichen Stellen im Lifecycle eines Agent-Tools: Discovery, Invocation, Execution, Rückgabe von Ergebnissen, Delegation und Zustandswechsel. Die dauerhafte Lehre lautet: Ein einzelner Approval-Dialog oder eine Allowlist beim Start kann diese Last nicht allein tragen.

Wie Mediation funktioniert

Sie beginnt bei Discovery. Ein Agent kann Tools kennenlernen, wenn sich ein MCP-Server verbindet, wenn ein lokales Projekt Konfiguration liefert oder wenn ein optionaler Server verfügbar wird. Discovery sollte beantworten, was dem Agent beschrieben werden kann, nicht was er ausführen darf. Codex 0.151.0 führte zum Beispiel eine konfigurierbare Grace Period für die Discovery von Tools optionaler MCP-Server ein. Codex 0.151.0 Verfügbarkeit ist ein Betriebszustand, keine Berechtigung.

Bei der Invocation erhält der Mediator eine vorgeschlagene Operation: Tool-Name, Argumente, Identität des Aufrufers, Task, aktuelles Permission Profile, Trust Level des Workspace sowie Zielserver oder Executor. Er prüft die Anfrage gegen eine Policy. Entscheidend ist, dass er Authority Attenuation anwenden kann: Er stellt weniger Macht bereit, als das dahinterliegende System besitzt. Ein Repository-Tool kann auf einen Checkout und schreibgeschützte Pfade eingegrenzt werden. Ein Deployment-Tool kann nur Staging akzeptieren. Ein Network-Tool kann auf benannte Ziele beschränkt werden. Ein delegierter Agent kann eine kleinere Capability-Menge und ein festes Budget erhalten.

Die Entscheidung muss Context Binding einschließen. Das heißt, eine Authorization-Entscheidung wird an tatsächlich relevante Fakten gebunden: Session, aktuelle Policy-Version, Agent oder Subagent, Executor-Identität, Betriebssystem, Home Directory, Path Rules und Sandbox-Zustand. Ein gecachtes „erlaubt“ ohne diese Bindungen ist gefährlich. Wenn du Berechtigungen änderst, den Executor wechselst oder einen nicht vertrauenswürdigen Workspace öffnest, kann eine zuvor gültige Klassifikation ungültig sein.

Einfach gesagt: „Früher erlaubt“ heißt nicht „hier, jetzt und für diesen Executor erlaubt“. Sicherheitsentscheidungen brauchen genug Context, um bei Änderungen dieses Context zu verfallen.

Dann folgt die Execution. Eine Sandbox begrenzt die umgebenden Befugnisse eines Executors: Welche Dateien, Prozesse oder Netzwerkziele er auch bei fehlerhaftem Code erreichen kann. Sie ist unverzichtbar, reicht aber nicht aus. Eine Sandbox kann normalerweise nicht ausdrücken, dass delete_issue nur für Issues erlaubt ist, die dieser Task angelegt hat, oder dass ein Package Installer nur ein internes Registry verwenden darf. Invocation Mediation liefert diese semantischen Regeln auf Argumentebene; die Sandbox ist die Rückfallebene, wenn sie versagen.

Nach der Execution folgt Result Mediation. Tool Output ist nicht automatisch vertrauenswürdig, nur weil der Call erlaubt war. Er kann Secrets, sehr große Payloads, irreführende Anweisungen, fehlerhafte Daten oder einen Error enthalten, der strukturiert bleiben sollte. Ein Result Mediator kann Größe begrenzen, definierte sensible Werte schwärzen, strukturierte Errors erhalten, Daten als nicht vertrauenswürdig markieren oder Output ablehnen, bevor er modell-sichtbarer Context wird. Der neue Extension Point von Codex zum Prüfen oder Ersetzen von MCP-Ergebnissen ist ein Beispiel für diese Grenze. Codex 0.151.0

Zum Schluss kommen Delegation und Zeit. Ein Child Agent ist keine saubere Accounting-Grenze, wenn er Ressourcen des Parent ausgibt oder auf dessen Ziel hinarbeitet. Die Accounting-Regel von Codex für Tokens verschachtelter Subagents am Root Goal zeigt einen Teil eines Root Task Budget. Codex 0.151.0 Ein praktisches Budget kann auch Laufzeit, Delegationstiefe, Anzahl der Tool Calls, Kosten und Klassen von Nebenwirkungen umfassen. Es sollte im Mediator durchgesetzt werden, nicht nur in einem Prompt stehen.

Was es nicht ist

Capability Mediation ist nicht Authentication. Authentication stellt fest, wer oder was eine Anfrage stellt. Sie kann nötige Eingabe für eine Policy sein, entscheidet aber nicht, ob genau diese Operation in diesem Context sicher ist.

Sie ist auch nicht nur Authorization. Authorization ist die Entscheidung zwischen erlauben und ablehnen. Mediation ist die größere Anordnung, die sicherstellt, dass Entscheidungen auf allen relevanten Pfaden stattfinden, und die Argumentvalidierung, Execution Constraints, Output Handling, Budgets und Audit Records umfassen kann.

Sie behauptet außerdem nicht, dass jedes System ein reines Object-Capability-Design braucht. In Object-Capability-Systemen ist der Besitz einer berechtigungsführenden Referenz zentral für den Zugriff. Eine Agent-Plattform kann Scoped Credentials, Identitäten, Policies oder eine Kombination einsetzen. Entscheidend ist, dass Berechtigung explizit, reduzierbar und an der Stelle geprüft wird, an der sie Wirkung entfaltet.

Die MCP-Authorization-Guidance macht eine verwandte Grenze deutlich: Clients müssen ressourcenspezifische Tokens handhaben; Token Passthrough an Downstream Services ist verboten, weil ungeprüftes Weiterleiten Confused-Deputy- und Trust-Boundary-Fehler erzeugen kann. MCP Authorization MCP Security Practices Ein Mediator sollte Credentials für die vorgesehene Resource beschaffen oder austauschen, statt blind das Credential weiterzureichen, das zufällig von oben kam.

Ein praktisches Engineering-Beispiel

Stell dir einen hypothetischen internen Coding Agent vor, der einen Service aktualisieren und einen Pull Request öffnen soll. Er kann ein Repository lesen, Tests in einem Remote-Executor ausführen, über MCP einen Issue Tracker abfragen und einen Release-Subagent um eine Risikoeinschätzung für das Deployment bitten.

Eine schwache Implementierung veröffentlicht alle vier Tools an das Modell und lässt jedes Tool seine lokalen Regeln selbst durchsetzen. Das erzeugt Lücken. Der Issue Tracker kann einen Kommentar mit Anweisungen für das Modell zurückgeben. Der Remote-Executor kann andere Pfade als der Controller haben. Der Release-Subagent kann mehr Calls machen, als das Budget des Parent vorsieht. Eine Permission Approval, die vor dem Wechsel des Repository gecacht wurde, kann zu lange gültig bleiben.

Ein vermitteltes Design beginnt damit, dem Task eine Root-ID und eine begrenzte Capability-Menge zuzuweisen. Repository-Zugriff ist nur innerhalb des ausgecheckten Project Root lesend und schreibend erlaubt; Shell Execution läuft in einer Sandbox, die mit der tatsächlichen Umgebung des Remote-Executors konfiguriert ist; Issue-Tracker-Calls erhalten ein ressourcenspezifisches Credential mit genau dem nötigen Scope; und der Subagent erhält schreibgeschützten Repository-Zugriff sowie eine Token- und Zeitzuweisung aus dem Root Budget.

Jeder vorgeschlagene Call zeichnet die angeforderte Operation, die effektiv eingeschränkte Capability, relevanten Context, Policy-Version, Entscheidung und Behandlung des Ergebnisses auf. Der Mediator lehnt einen Write außerhalb des Project Root vor der Process Execution ab. Er verhindert, dass ein geändertes Credential eine alte Approval wiederverwendet. Er markiert Issue-Tracker-Text als nicht vertrauenswürdig, bevor er in den Context kommt, und setzt definierte Größenlimits. Widerruft eine Policy den Deployment-Zugriff, müssen spätere Anfragen neu bewertet werden; lang laufende Arbeit braucht möglicherweise eine eigene Cancellation-Behandlung.

Einfach gesagt: Baue Tools als leistungsfähige Backend-Services, gib jedem Agent aber nur den kleinsten und kurzlebigsten Ausschnitt an Macht, den der aktuelle Task braucht.

Das verlangt keinen einzigen riesigen Policy Service. Ein Filesystem Wrapper, ein Command Launcher, ein MCP Proxy und ein Subagent Scheduler können jeweils ihre eigene Grenze vermitteln. Sie brauchen aber gemeinsame Konzepte: Task-Identität, Trust State, Policy-Version, Budget, Audit-Schema und eine bewusste Regel für Revocation. Andernfalls widersprechen sich verteilte Kontrollen genau in den Fällen, die Angreifer und Produktionsfehler finden.

Wo es scheitert

Der erste Fehler ist unvollständige Abdeckung. Wenn ein Agent einen Subprocess direkt starten kann, während sein Shell Tool vermittelt wird, besiegt der direkte Pfad das Design. Dasselbe gilt für alternative MCP Clients, geerbte Credentials, gecachte Handles oder Zustand, der außerhalb der Result-Grenze ins Modell gelangt. Kartiere alle Pfade mit Wirkungen, bevor du komplexe Policies schreibst.

Der zweite Fehler besteht darin, Content Safety mit Access Control zu verwechseln. Result Mediation kann nicht vertrauenswürdigen Text markieren oder filtern, beweist aber nicht, dass dieser Text wahr oder harmlos ist. Prompt Injection, der Umgang mit sensiblen Daten und Data-Flow Controls bleiben getrennte Probleme.

Drittens kann übermäßige Transformation schaden. Geschwärzter Output kann Diagnosen verdecken. Strukturierte Errors in Prosa umzuwandeln kann dem Agent und den Betreibenden Informationen nehmen, die zur Wiederherstellung nötig sind. Erhalte maschinenlesbare Fehlerinformationen, wenn das sicher möglich ist; die Erhaltung strukturierter MCP-Tool- und Resource-Errors in App-Server-Responses durch Codex weist in diese Richtung. Codex 0.151.0

Schließlich ist Revocation keine sofortige Magie. Einen künftig abgelehnten Call zu stoppen, ist einfach. Ein bereits ausgegebenes Token, ein bereits laufender Job oder ein schon gestarteter Subprocess können Credential Expiry, Cancellation, Process Control und Zusammenarbeit nachgelagerter Systeme erfordern. Zustandsänderungen müssen gecachte Entscheidungen ungültig machen, aber das System muss auch festlegen, was mit laufender Berechtigung geschieht.

Was du diese Woche tun kannst

Verfolge einen Agent Workflow von der Tool Discovery bis zum letzten modell-sichtbaren Ergebnis. Markiere jede Stelle, an der er Daten lesen, Zustand verändern, Geld ausgeben, erhebliche Rechenzeit verbrauchen oder Arbeit delegieren kann. Frage für jede Grenze: Welche Identität und welchen Context nutzt die Entscheidung? Kann die Capability eingeschränkt werden? Was passiert nach Policy-Änderungen? Kann dieser Pfad den vorgesehenen Mediator umgehen?

Wähle dann ein wichtiges Tool und kapsle es. Halte die erste Policy einfach: Argumente eingrenzen, Approval an Task- und Executor-Context binden, ein Budget setzen, einen Decision Record loggen und Output als nicht vertrauenswürdige Eingabe behandeln. Teste Übergänge, nicht nur statische Fälle: Ändere Workspace Trust, ändere Permissions, wechsle Executors und wiederhole eine gecachte Anfrage.

Das Ziel ist nicht, einen Agent unschädlich zu machen. Seine tatsächliche Berechtigung soll so sichtbar, begrenzt und widerrufbar werden, dass Engineering-Teams sinnvoll darüber nachdenken können.

Die heutigen KI-Trends

Codex macht Tool Handling zu einem Lifecycle-Problem. Codex 0.151.0 ergänzt Result Interception und verschärft zugleich Permission Persistence, Sandbox Context, den Umgang mit veralteter Authorization und Budgets für verschachtelte Agents. Release Die praktische Konsequenz: Prüfe Agent Controls als zusammenhängende Lifecycle-Grenzen statt als unabhängige Tool Settings.

Gemini CLI lässt eingeschränkte Workspaces die MCP-Verfügbarkeit reduzieren. Die Nightly-Version vom 29. August erzwingt Fail-Closed Workspace Trust und filtert MCP-Server im Restricted Mode. Release Bei internen Coding Agents sollte ein nicht vertrauenswürdiges Repository Capabilities automatisch entfernen, statt sich auf erinnerte Entscheidungen von Nutzern zu verlassen.

Der MCP Adapter von LangChain hält operative Kontrollen sichtbar. Das Alpha-Release 1.4.0a2 führt einen MCPAdapter ein, der MCP-Server zu Tools macht, während Authentication, Caching, Timeouts und verwandtes Verhalten bei FastMCP Clients bleiben; Multi-Server-Konfigurationen vergeben Namespaces für Tools nach Server. Release Ein Protocol zu normalisieren ist nützlich, aber Transport- und Credential-Policy gehören weiter in die Anwendungsarchitektur.