MCP vs CLI: Was passiert, wenn Ihr KI-Agent den Connector nicht findet

Wenn ein KI-Agent auf einer Maschine handeln muss, ist der saubere Weg das Model Context Protocol (MCP). Ein MCP-Server stellt eine definierte Menge an Werkzeugen bereit, der Agent ruft sie auf, und man kann nachvollziehen, was er tun darf, weil die Liste kurz und schriftlich festgehalten ist. Dann braucht der Agent etwas ohne Connector, wie ein internes Ticketsystem oder eine Business-App, die seit 2012 niemand mehr angefasst hat, und die Geschichte ändert sich. Ein Agent, der entschlossen ist, seine Aufgabe zu beenden, sucht eine andere Tür, und diese Tür ist fast immer die Befehlszeile.

Die meisten Online-Diskussionen über MCP vs CLI drehen sich um Token-Kosten, OAuth und die Anmeldeinformationen-Verwaltung, was berechtigte Themen sind. Sehr selten wird gefragt, was der Endpunkt tatsächlich ausführt, sobald der Agent den MCP-Pfad verlässt, und das ist der Teil, den IT-Administratoren übernehmen.

MCP vs CLI

Die beiden Ansätze geben einem Agenten sehr unterschiedliche Macht. Mit MCP erhält der Agent eine definierte Liste von Werkzeugen und sonst nichts. Mit einer CLI steuert der Agent eine Shell, und eine Shell hat alle Rechte des angemeldeten Benutzers. Der Code-Modus, das neuere Muster, das unten behandelt wird, verhält sich wie die CLI-Seite dieser Linie, wenn er auf einem verwalteten Desktop ausgeführt wird, da der Agent sein eigenes Programm schreibt und die Maschine es ausführt.

Dieser Unterschied erklärt, warum Entwickler die CLI mögen (sie verbraucht wenige Tokens und Agenten sind mit Tools wie git und docker vertraut) und warum Sicherheitsteams MCP bevorzugen (eine kurze Liste ist leichter zu prüfen und OAuth bietet zentrale Authentifizierung). Beide Seiten haben Recht. Was keiner klärt, ist, was einen agent daran hindert, etwas auszuführen, das niemand genehmigt hat, sobald er die Werkzeugliste verlässt.

Agenten greifen auf die CLI zurück

Angenommen, ein Entwickler bittet einen Agenten, Daten aus diesem Ticket-System abzurufen. Ohne Connector schreibt der Agent ein Skript, lädt eine Hilfsdatei herunter und fügt einige Befehle zusammen, und niemand hat das genehmigt, weil Ihre MCP-Governance es nie gesehen hat. Der Agent hat die MCP-Welt komplett verlassen. Es wirkt wie ein Heist-Film, in dem das Sicherheitsteam monatelang den Haupttresor bewacht, während die Crew durch den Laderaum hereinkommt; die Crew hier ist gut gemeinte Software, und der Laderaum ist genauso offen.

Der Fallback ist ebenfalls still, da ein MCP-Protokoll keinen Eintrag über einen PowerShell command enthält, den der Agent eigenständig ausgeführt hat.

Die Codeausführung mit MCP bringt agentgeschriebenen Code auf Ihre Endpunkte

MCP selbst verändert sich. Statt ein Tool nach dem anderen aufzurufen und jedes Ergebnis durch das Modell zu leiten, wechseln Agenten in den Codemodus: Der Agent schreibt ein kleines Programm, das die MCP-Tools aufruft, die Rückgaben filtert und kombiniert und das Ganze ausführt. Anthropic beschrieb dieses Muster in seinem Engineering-Blog, und der Reiz ist leicht zu erkennen, da ein Skript zwanzig Tool-Aufrufe tätigen kann, ohne jedes Ergebnis durch das Modell zu schicken. Es spart Tokens und macht Agenten leistungsfähiger, weshalb es an Bedeutung gewinnt.

Es platziert auch echten, vom Agenten erstellten Code auf Ihren Endpunkten. Die Codeausführung mit MCP verlagert die Kontrollfrage von den Werkzeugen, die der Agent aufrufen darf, zu den Programmen, die der Endpunkt ausführt, und ein Programm ist nur so vertrauenswürdig wie derjenige, der es geschrieben hat. Einige Setups führen diesen Code in einer Sandbox aus, und eine Sandbox hilft sehr. Ein verwalteter Windows- oder Mac-Desktop ist jedoch normalerweise keine Sandbox, und wenn die Maschine alles ausführt, was ihr übergeben wird, ist Ihre genehmigte Werkzeugliste nur ein Vorschlag, da der Code des Agenten den MCP-Server genauso leicht umgehen kann, wie er ihn durchläuft.

Was eine Rogue-Shell oder ein Agentenskript mit lokalen Administratorrechten anrichten kann

Der Schaden hängt davon ab, wessen Rechte der Agent ausleiht. Unter einem lokalen Administrator, hat der CLI-Fallback die volle Kontrolle über die Maschine, sodass er Software installieren oder Schutzmaßnahmen ohne Rückfrage deaktivieren kann. Ein Agent eines Standardbenutzers kann dennoch eine ausführbare Datei ausführen, die niemand überprüft hat, entweder wegen eines eigenen Fehlers oder weil eine Eingabeaufforderungsinjektion in einem gelesenen Dokument ihn dazu aufgefordert hat.

Grenzen dort durchsetzen, wo der Code ausgeführt wird

Viele Teams versuchen, den Agenten selbst mit Systemaufforderungen, Schutzvorrichtungen und klar verständlichen Richtlinien einzuschränken. Das hilft, wirkt aber nur auf der KI-Seite, und ein Agent kann verwirrt oder manipuliert werden. Der verlässliche Schritt ist, Grenzen dort durchzusetzen, wo der Code ausgeführt wird, damit das Ergebnis sicher bleibt, egal was der Agent versucht. Der Endpoint ist der Teil des Stacks, den die IT bereits besitzt, und dort funktioniert PolicyPak.

Wie PolicyPak MCP vs CLI handhabt: Least Privilege und Allowlisting

PolicyPak geht das Problem aus zwei Richtungen an, wobei die erste das Prinzip der geringsten Rechte ist. PolicyPak Least Privilege Manager entfernt lokale Administratorrechte von Benutzern und gewährt Administratorrechte nur für die spezifischen Anwendungen und Aufgaben, die sie benötigen, unter Windows und Mac. Ein Agent, der unter einem Standardbenutzer auf die CLI zurückfällt, kann keine Treiber installieren oder Sicherheitstools manipulieren, und die Ausnahmen, die Sie gewährt haben, bleiben auf die von Ihnen benannten Apps beschränkt.

Der zweite Punkt ist die Allowlist. PolicyPak SecureRun funktioniert über Dateibesitz: Ausführbare Dateien, die von Standardbenutzern oder einem Agenten, der als solcher agiert, eingeführt werden, laufen nicht, es sei denn, sie gehören einem vertrauenswürdigen Konto, wie Ihrem Softwarebereitstellungstool oder einem Administrator. Das ist für den Code-Modus wichtig. Wenn ein Agent ein Skript schreibt oder eine Hilfsdatei ablegt, vertraut SecureRun der Datei nicht und blockiert sie, weshalb es auch als Ein-Klick-Ransomware-Schutz funktioniert. Sie erhalten eine umfassende Allowlist ohne hashweise Pflege und ohne die Entfernung der bereits verwendeten Tools.

Agenten können MCP weiterhin überall dort verwenden, wo ein Connector vorhanden ist. Wo keiner existiert, läuft der CLI-Fallback auf einer Maschine, auf der der Benutzer keine Administratorrechte hat und die Datei, die der Agent gerade geschrieben hat, keinen vertrauenswürdigen Eigentümer besitzt. Das bleibt so, wenn die Codeausführung mit MCP die Norm ist.