Ein forschungsgestützter Blick auf den Übergang von Vorschlags-Engines zu autonomen Teamkollegen. Warum er jetzt stattfindet, was dabei zerbricht und wie man KI einsetzt, ohne die Schlüssel zum Königreich aus der Hand zu geben.

Die Copilot-Ära stagniert

Am 15. April 2026 postete Sam Altman auf X, dass OpenAI diese Woche „Codex-Updates mit Fokus auf Teams und Großunternehmen" ausrolle.

Die Antworten waren aufschlussreich. Auf jede Entwicklerfrage zur Roadmap folgte eine schwerere: Warum muss ich Codex eigentlich immer noch babysitten? Sechs Monate zuvor hatten Forscher von BeyondTrust einen Proof of Concept veröffentlicht, der zeigte, dass sich Codex durch einen speziell gestalteten Git-Branch-Namen dazu bringen ließ, das GitHub-Token des Nutzers abzugreifen. Ein Copilot, der sich über einen Branch-Namen zum Token-Leak verleiten lässt, ist kein Kollege. Er ist eine geladene Waffe mit Sicherung.

Diese Spannung liegt 2026 unter jedem Enterprise-KI-Gespräch. Copiloten haben ihre Decke erreicht, und die Zahlen belegen es:

Die NANDA-Initiative des MIT berichtete 2025, dass 95 % der Pilotprojekte für generative KI keinen messbaren Geschäftswert liefern.
Eine RAND-Studie, die Anfang 2026 vielfach auf Reddits r/ArtificialIntelligence zitiert wurde, fand heraus, dass 80 bis 90 % der KI-Agent-Projekte in Produktionsumgebungen scheitern.
Die Akzeptanzrate von GitHub Copilot unter Entwicklern pendelt sich bei 35 bis 40 % ein, während Cursor bei 42 bis 45 % liegt und Claude Code in der 2026er AI-Coding-Umfrage einen 46 %-„most loved"-Wert erreichte. Eine erstaunliche Wende für ein Tool, das erst im Mai 2025 erschien.
Satya Nadella soll Microsofts internen Copilot-Rollout Ende 2025 als „nahezu unbrauchbar" bezeichnet haben, und das Unternehmen kündigte intern einen als „hochriskanten Reset" beschriebenen Produkt-Neustart an.
Eine Ende 2025 auf arXiv veröffentlichte Studie ergab, dass Copilot-artiger Autocomplete die Frustration erfahrener Entwickler sogar erhöht, weil er ihren Flow mit plausiblen, aber subtil falschen Vorschlägen unterbricht.

Das Plateau ist kein Versagen der zugrunde liegenden Modelle. Es ist ein Versagen des Interaktionsmusters. Ein Copilot operiert auf der Ebene einzelner Tastenanschläge oder Fragen. Ein Kollege operiert auf der Ebene des Workflows. Bits&Chips formulierte es im April-2026-Essay „From copilot to colleague" präzise: „Ein Copilot agiert auf der Ebene der einzelnen Interaktion, während ein Agent auf der Ebene des Workflows agiert. Das ist wichtig, denn in den meisten Organisationen ist der Engpass nicht die einzelne Aufgabe, sondern die Koordination zwischen Aufgaben."

Genau diesen Sprung versuchen Unternehmen jetzt zu schaffen. Ungleichmäßig, unvollkommen und in relevantem Maßstab.

Das Autonomiespektrum

„Agent" ist ein Marketing-Wort geworden, also werden wir konkret. Es gibt vier klar unterscheidbare Stufen von KI-Autonomie, und die Enttäuschungen der Jahre 2025 und 2026 entstanden meist aus der Verwechslung einer mit der anderen.

Stufe 1: Copilot

Schlägt vor. Fragt um Erlaubnis. Bleibt auf eurem Bildschirm. Der Autocomplete von GitHub Copilot ist der Archetyp. Der Wert wird in gesparten Tastenanschlägen gemessen.

Stufe 2: Assistent

Beantwortet Fragen und erstellt auf Anfrage Artefakte. ChatGPT, Claude im Browser, das Chat-Panel von Microsoft 365 Copilot. Der Wert wird in Entwurfsqualität und Kontextsynthese gemessen.

Stufe 3: Agent

Nimmt ein Ziel entgegen, plant eine Abfolge von Schritten, führt sie über Tools hinweg aus und berichtet zurück. Claude Code scannt ein Repo und öffnet einen PR. ChatGPTs Deep Research recherchiert 20 Minuten lang und liefert einen zitierten Report. Anthropic dokumentierte eine Claude-Instanz, die für Rakuten eine 7-stündige autonome Engineering-Aufgabe abschloss. Der Wert wird in abgeschlossenen Workflows pro aufgewendeter Personen-Stunde gemessen.

Stufe 4: Kollege

Ein Agent, der innerhalb eures bestehenden Berechtigungsmodells arbeitet, an den Kommunikationskanälen eures Teams teilnimmt, Kontext über Tage und Wochen hält und demselben Audit-Trail unterliegt wie ein menschlicher Mitarbeiter. Das ist die Frontier.

Reddits r/ChatGPT-Community brachte einen pragmatischen Test hervor, um diese Stufen zu unterscheiden, sinngemäß: Ergreift das Ding die Initiative oder wartet es auf jede Anweisung? Bewältigt es unerwartete Situationen oder stürzt es ab und zwingt euch zur Neu-Formulierung? Behält es Kontext über eine mehrstufige Aufgabe hinweg oder müsst ihr euch wiederholen? Die meisten 2025 als „KI-Agenten" vermarkteten Produkte versagten an jeder dieser Fragen. Jene, die bestanden, sind das, was Leute heute meinen, wenn sie „Kollege" sagen.

Computer Use vs. Skills: Warum die Sanitärinstallation zählt

Eine kollegengleiche KI muss in der Welt handeln. Dafür gibt es zwei architektonische Ansätze mit sehr unterschiedlichen Risikoprofilen.

Computer Use

Die KI steuert eine simulierte Maus und Tastatur. Sie sieht buchstäblich einen Bildschirm und klickt Buttons. Anthropic brachte Computer Use Ende 2024, OpenAIs Operator folgte. Der Reiz ist Universalität: Jede Software mit GUI wird adressierbar.

Der Preis ist der Schadensradius. Ein computer-nutzender Agent erbt jede Berechtigung des eingeloggten Nutzers. Im Oktober 2025 demonstrierte BeyondTrusts Security-Team, dass sich OpenAIs Codex-Agent über einen bösartigen Git-Branch-Namen mit eingebetteten Shell-Befehlen dazu bringen ließ, das GITHUB_TOKEN des Nutzers auszulesen und zu exfiltrieren. Der Agent tat genau das, was ein menschlicher Entwickler getan hätte (Branch auschecken), hatte aber keine Intuition dafür, dass der Branch-Name selbst feindlicher Input war. In diesem Vorfall war das Berechtigungsmodell alles-oder-nichts. Das ist der Standard-Fehlermodus von Computer Use.

Skills

Die KI ruft diskrete Skills auf. Jeder Skill ist eine explizite, typisierte Funktion mit engem Vertrag: „durchsuche Slack nach Nachrichten, die q entsprechen", „erstelle ein Linear-Issue mit title und body", „lese diese GitHub-Datei". Anders als bei Computer Use hat ein Skill eine vorab genehmigte Form. Der Agent kann ihn nur mit Parametern aufrufen, die dem Vertrag entsprechen, und die Plattform kann den Aufruf erlauben, verweigern oder rückfragen, bevor er die Sandbox verlässt.

Der Unterschied läuft sicherheitstechnisch auf das Prinzip der geringsten Rechte hinaus. Es ist eine Grundidee der Informationssicherheit: Ein Prozess soll nur Zugriff auf die Ressourcen haben, die er für seine Funktion braucht, und nicht mehr. Skills erlauben, das Prinzip pro Aufruf durchzusetzen. Computer Use nicht.

Eine Kollege-Klasse-Deployment nutzt Skills für strukturierte Aktionen (Schreiben in ein CRM, Öffnen eines Tickets) und reserviert Computer Use für den schmalen Schwanz an Anwendungen, die keine API anbieten. Das Verhältnis ist entscheidend. Wenn jede Aktion eures Agenten durch eine simulierte Maus läuft, habt ihr eine Produktivitäts-Demo, kein Produktionssystem.

Die Trust-Architektur, die Unternehmen wirklich brauchen

Der Sprung vom Copilot zum Kollegen ist kein Modell-Upgrade. Es ist ein Infrastruktur-Upgrade. Drei Elemente trennen einen deploybaren Kollegen von einer Haftungsfalle.

1. Permission Isolation

Jeder Agent operiert innerhalb seiner eigenen Berechtigungsgrenze, mit Credentials, die der Agent selbst nicht aus seiner Sandbox herausholen kann. Andrej Karpathys virales autoresearch-Experiment vom März 2026, in dem er einen Agenten zwei Tage lang unbeaufsichtigt 700 Trainingsexperimente laufen ließ, ist lehrreich für das, was er nicht tat. Karpathys eigenes Repo weist Nutzer an, im autonomen Modus „alle Berechtigungen zu deaktivieren". Auf einem persönlichen Research-Laptop ist das in Ordnung. In einem regulierten Unternehmen ist das ein Kündigungsgrund.

Das Gegenbeispiel ist Moltbook, das reine KI-Social-Network, das Ende Januar 2026 mit 1,5 Millionen autonomen Agenten kurz viral ging. Karpathy lobte es als „das unglaublichste Sci-Fi-Takeoff-nahe Ding, das ich kürzlich gesehen habe". Dann entdeckten Security-Forscher von Wiz einen im Frontend exponierten Datenbank-API-Key, der vollen Lese-/Schreibzugriff auf die gesamte Produktionsdatenbank gewährte, einschließlich der Authentifizierungstoken für alle 1,5 Millionen Agenten. Karpathy ruderte innerhalb von 24 Stunden zurück: „Es ist ein Dumpster Fire. Ich rate definitiv davon ab, dieses Zeug auf dem eigenen Rechner laufen zu lassen." Die Lektion ist nicht „Agenten sind gefährlich". Die Lektion ist: Agenten, die ohne pro-Identität Permission Isolation deployt werden, kollabieren zu einem gemeinsamen Schadensradius.

2. Audit-Trails

Jede Aktion geloggt, jede Entscheidung nachvollziehbar. Das im Januar 2026 in Davos veröffentlichte IMDA-Framework Singapurs kodifiziert dies mit einer Zwei-Achsen-Risikomatrix, die den Aktionsraum eines Agenten (lesen vs. schreiben, reversibel vs. irreversibel) gegen seine Autonomie (wie eigenständig er entscheidet) abträgt. Je höher eine der Achsen steigt, desto reichhaltiger die Audit-Anforderung. Europäische und US-amerikanische Regulierer studieren dieses Framework genau, weil es eines der ersten ist, das Governance von abstrakten Prinzipien in ein operationales Kalibrierungswerkzeug übersetzt.

Simon Willison plädiert parallel für einheitliches Logging, damit Agenten ihre eigenen Operationen überwachen und aus Fehlern zurückfinden können: „Agenten mit vollem Systemzugriff sind mächtig und gefährlich." Der praktische Punkt: Wenn euer Agent-Deployment kein einheitliches Log hat, das ein Compliance Officer der Reihe nach lesen kann, seid ihr exakt einen Vorfall davon entfernt, das Recht zum Deployen zu verlieren.

3. Scoped Skill Access

Nicht „Zugriff auf E-Mail". Sondern Zugriff auf search inbox where from:@customer.com AND within last 7 days. Moderne Agent-Plattformen bewegen sich zu parametrisierten Scopes, in denen die Berechtigung eines Agenten, einen Skill aufzurufen, durch Argumente begrenzt wird, die ein Admin vorab genehmigt hat — nicht durch den groben OAuth-Scope, den der Mensch nutzen würde.

Setzt diese drei Teile zusammen und sie beantworten die Frage, die jeder CISO gerade stellt: Was macht dieser Agent, wenn er sich irrt, und woher weiß ich es? Die 2026er McKinsey-State-of-AI-Studie ergab, dass 72 % der Enterprise-Befragten Cybersicherheit als Sorge bei generativer KI nannten, und Sicherheit wurde von rund zwei Dritteln als #1-Barriere für das Skalieren agentischer Workflows genannt. Permission Isolation, Audit-Trails und Scoped Skill Access sind kein Compliance-Theater. Sie sind die Gating-Infrastruktur.

Warum das jetzt zählt: drei konvergierende Kräfte

Der Sprung vom Copilot zum Kollegen wird 2026 nicht von einem einzigen Durchbruch getragen. Er ist das Ergebnis dreier sich kreuzender Kurven.

Kraft 1: Integration ist nicht mehr Maßarbeit

2024 bedeutete das Verdrahten eines Agenten in einen Corporate-SaaS-Stack, pro Tool einen eigenen Connector zu schreiben. Anfang 2026 haben typisierte Skill-Verträge und fertige Connectoren diese Arbeit kollabieren lassen. Ein Agent, der 2024 sechs Wochen Integrationsarbeit brauchte, braucht 2026 einen Nachmittag. Die Oberfläche eines typischen Mid-Market-Unternehmens (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, Kalender) ist heute durch reife Open-Source-Connector-Bibliotheken abgedeckt, die mit typisierten Berechtigungen ausgeliefert werden.

Kraft 2: Multi-Agent wird real

Gartner führte Multi-Agent-Systeme als strategischen Top-Technologie-Trend für 2026 auf. Distinguished VP Analyst Gene Alvarez lieferte die Metapher, die inzwischen in jeder Enterprise-KI-Folie steht: „Stellt euch eine Formel-1-Boxencrew vor. Jedes Mitglied hat eine spezialisierte Rolle (Reifenwechsler, Tanker, Wagenheber-Operator), aber alle sind auf ein einziges Ziel choreographiert. Genau diese Form haben Enterprise-Agent-Deployments 2026." Single-Agent-Systeme stoßen bei Langzeit-Aufgaben an Reasoning-Decken. Multi-Agent-Systeme umgehen diese Decken heute mit spezialisierten Rollen und expliziten Übergaben.

Kraft 3: Enterprise-Budgets lösen sich

G2 meldete in seinem 2026er State-of-Software-Research, dass 57 % der Unternehmen KI-Agenten im Produktionsbetrieb haben (gegenüber rund 20 % ein Jahr zuvor).
McKinsey fand, dass 23 % der Unternehmen agentische KI aktiv skalieren, 62 % sind im Experimentierstadium. Das lässt nur noch etwa 15 % der Großorganisationen am Seitenrand.
Deloittes 2026er Umfrage unter 3.235 Enterprise-Führungskräften identifizierte Financial Services als führenden Adopter, mit einer dokumentierten Fallstudie zu einem KI-Agenten, der Meeting-Ergebnisse über eine Deal-Pipeline hinweg erfasste und darauf reagierte, die zuvor drei Analysten band.
Stanfords Enterprise AI Playbook, Anfang 2026 veröffentlicht, katalogisierte 51 Produktions-Deployments, wobei ein Fintech-ETL-Migrationsfall zur Referenzimplementierung für regulierte Industrien wurde.
Die gemeldete Investition in Enterprise-KI-Infrastruktur überschritt im 2025er Zyklus 600 Milliarden US-Dollar.
Anthropic-CEO Dario Amodei gab auf der Code-with-Claude-Konferenz eine 70- bis 80 %-Wahrscheinlichkeit dafür, dass 2026 das erste Ein-Personen-Unternehmen mit Milliarden-Bewertung entstehen werde, getragen von Agent-Arbeitskräften.

Das Geld ist da, das Protokoll ist da, die Architektur ist da. Was jetzt in jedem Boardroom verhandelt wird, ist wie viel Autonomie, unter welcher Governance und für welche Workflows.

Die Gegenthese: was Reddit, arXiv und die Vorfallsberichte sagen

Ein verantwortungsvoller Blick auf diesen Wandel muss sich ernsthaft mit denjenigen auseinandersetzen, die das Ganze für überverkauft halten.

Auf Reddit ist der Konsens über r/LocalLLaMA, r/ClaudeCode und r/ChatGPT pragmatisch: Coding-Agenten sind angekommen und nützlich. Die meisten anderen „Agenten" sind Automations-Workflows im Chatbot-Kostüm. Die in Dutzenden 2026er Threads zitierte Zeile, „Nutze Copilot, wenn du Vorschläge willst. Nutze Claude Code oder Cursor, wenn du willst, dass es wirklich etwas tut," fasst die produktive Trennung. Dieselben Communities sind bei Benchmarks unnachgiebig. Selbst die besten Agenten erreichen rund 60 % im Terminal-Bench-Gesamtscore und fallen bei harten Aufgaben auf 16 %. Claude Opus 4.5 führt SWE-bench mit 80,9 %, was immer noch heißt, dass jede fünfte Aufgabe scheitert.

Die akademische Skepsis ist schwerer abzuschütteln. Vishal Sikka (ehemaliger SAP-CTO, Schüler von John McCarthy) und sein Koautor veröffentlichten Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models und argumentieren mathematisch, dass Transformer-LLMs in ihrer Fähigkeit, komplexe computationale und agentische Aufgaben auszuführen, fundamental begrenzt sind. Sikkas Schlussfolgerung, „Es gibt keinen Weg, wie sie zuverlässig sein könnten" für hochkritische Operationen, kursiert gerade in jedem CISO-Slack. Das Paper behauptet nicht, dass Agenten nutzlos sind. Es behauptet, dass es eine Problemklasse gibt, bei der man den Menschen nicht aus der Schleife nehmen kann, egal wie gut das Modell wird.

Reale Vorfälle stützen die Skepsis. Ein Retail-CX-Leader aus der 2026er Yellow.ai-Umfrage: „Wir mussten unseren KI-Support nach gerade zwei Wochen zurückziehen, weil er in etwa 1,35 % der Tickets falsche Rückgaberichtlinien zitierte und Rabattangebote erfand. Die Kosten dafür, diese Fehler einzulösen, überstiegen bei Weitem, was wir einsparen wollten." Im Maßstab wird selbst eine Sub-2 %-Fehlerquote schnell teuer.

Die Synthese: Kollege-Klasse-KI ist real im Coding, in der Recherche, in strukturierten Ops und engen Support-Workflows. Sie ist noch nicht real in offenen, kundengerichteten Interaktionen ohne menschlichen Reviewer. Die Unternehmen, die 2026 Wert schaffen, sind diejenigen, die ehrlich einordnen, in welchen Eimer ein Workflow gehört.

Praktische Folgerung: fünf Fragen vor dem Deployment

Wenn euer Team einen KI-Teamkollegen evaluiert (intern gebaut oder Third-Party), trennen diese Fragen ein Produktions-Deployment von einem Beinahe-Unfall.

Wie groß ist der Schadensradius der schlimmsten Einzelaktion, die dieser Agent auslösen kann? Kartiert ihn buchstäblich. Wenn der Worst Case „verschickt einen unfertigen Entwurf an die falsche Person" ist, liegt die Governance-Schwelle niedrig. Wenn er „ändert Produktionsdaten" oder „sendet Überweisungsanweisungen" heißt, liegt sie eine Größenordnung höher. Kartiert vor dem Deployment, nicht nach dem ersten Vorfall.
Wie kommt der Agent an seine Credentials, und kann er das Roh-Token jemals lesen? Es gibt drei Antworten, und nur eine ist sicher. Wenn der Agent eine Kopie des OAuth-Tokens des Nutzers in seiner Umgebung hat, habt ihr dem LLM faktisch eure Brieftasche gegeben. Wenn der Agent „seine eigene" Identität über ein separates Service-Account-OAuth hat, müsst ihr ihn als echten Principal verwalten, widerrufen und auditieren. Die dritte Antwort, die ihr wollt: Das Token erreicht den Agenten nie. Es lebt verschlüsselt auf der Plattform und wird auf Netzwerk-Proxy-Ebene just-in-time injiziert, nur für Aufrufe, die eine Policy-Prüfung passiert haben, nur bis der Aufruf zurückkehrt.
Wird jede Aktion an einem Ort geloggt, den ein Compliance Officer der Reihe nach lesen kann? Einheitlich, abfragbar, manipulationssicher. Wenn eure Antwort „wir haben irgendwo in CloudWatch ein paar Logs" lautet, seid ihr nicht bereit.
Könnt ihr Skill-Zugriff auf die spezifischen Parameter dieses Workflows scopen? Pro Aufruf, nicht pro Integration. Lesen vs. Schreiben. Nach Ressourcen-ID. Nach Zeitfenster. Die Berechtigungen des Agenten sollten ein eng um den Job gezeichnetes Rechteck sein, nicht das ganze Lager.
Wie sieht die Rollback-Story aus, wenn etwas schiefgeht? Wie kehrt man eine Aktion um? Wie schnell? Wer wird pagert? Irreversible Aktionen (Geldtransfers, kundengerichtete E-Mails, Produktions-Deploys) brauchen einen Bestätigungsschritt oder ein Verzögerungsfenster. Reversible können autonom laufen.

Arbeitet euch durch die fünf. Wenn ihr alle beantworten könnt, seid ihr bereits über die Copilot-Ära hinaus und in dem Teil, der wirklich verändert, wie euer Team liefert. Wenn ihr zwei oder drei beantworten könnt, ist das der Fokus für die nächste Etappe, kein Grund zu warten. Der kollegen-grade Teamkollege, nach dem eure Roadmap greift, läuft heute schon irgendwo in Produktion. Die Lücke zwischen euch und ihm ist eine Infrastrukturlücke, keine Frontier-KI-Lücke. Und Infrastrukturlücken schließen sich schnell.

Ihr müsst nicht auf den nächsten Modell-Release warten. Ihr müsst eine Plattform wählen, die diese fünf bereits für euch beantwortet, und eurem Agenten echte Arbeit geben.

Häufig gestellte Fragen

Was ist der echte Unterschied zwischen einem Copilot und einem KI-Kollegen?

Ein Copilot schlägt vor, fragt um Erlaubnis und lebt in einem einzigen Tool. Ein Kollege nimmt Ziele an, plant quer durch Systeme, handelt mit gescopten Berechtigungen und unterliegt demselben Audit-Trail wie ein Mensch. Bits&Chips brachte es sauber auf den Punkt: Copiloten arbeiten auf Interaktionsebene, Kollegen auf Workflow-Ebene.

Wie sollen Agenten mit Nutzer-Credentials umgehen?

Keine der naheliegenden Optionen ist richtig. Das OAuth-Token des Nutzers in die Agent-Umgebung zu kopieren, legt ein Live-Credential in den LLM-Kontext. Jedem Agenten eine eigene Identität zu prägen, macht jeden Agenten zu einem Principal, den ihr wie einen Menschen verfolgen, widerrufen und auditieren müsst. Das Muster, das in der Praxis funktioniert, ist Brokered Access: Das Token lebt verschlüsselt auf der Plattform; der ausgehende Netzwerk-Proxy der Sandbox ruft zur Laufzeit die Plattform zurück; die Plattform entschlüsselt das Token und liefert nur die aufgelösten Auth-Header für Aufrufe, die eine Policy-Prüfung passiert haben, zurück; der Agent selbst liest, loggt oder fragt nie das Roh-Token ab.

Computer Use oder Skills — was sollen wir wählen?

Skills als Default, für alles mit API. Computer Use nur, wenn das Zielsystem keine programmierbare Schnittstelle hat. Der BeyondTrust-Codex-Vorfall ist die Warngeschichte: Computer Use erbt die vollen Nutzer-Berechtigungen, und bösartiger Input irgendwo im Sichtfeld des Agenten kann zum Exploit werden.

Wie autonom sollten wir Agenten tatsächlich laufen lassen?

Nutzt Singapurs IMDA-Rahmung auf zwei Achsen: Aktionsraum × Autonomie. Enger Aktionsraum (nur lesen, reversibel) toleriert hohe Autonomie. Weiter Aktionsraum (schreiben, irreversibel, kundengerichtet) verlangt menschliche Bestätigung oder ein Zeitverzögerungs-Fenster zum Eingreifen. Die schlechteste Konfiguration ist hohe Autonomie auf hochriskanten Aktionen ohne Audit-Trail.

Wie messen wir ROI?

Hört auf, gesparte Tastenanschläge zu zählen. Messt abgeschlossene Workflows pro Personen-Stunde, Time-to-Resolution bei Ops-Vorfällen und Escape-Rate (Aufgaben, die der Agent an einen Menschen zurückgibt). Deloittes 2026er Ergebnisse legen nahe, dass die führenden Adopter drei Kennzahlen verfolgen: Workflow-Abschlussrate, Fehlerrate und Rate menschlicher Intervention, und das Verhältnis zwischen ihnen optimieren.

Was tun wir gegen die 95 %-Pilot-Failure-Rate?

Lest MIT NANDAs Aufschlüsselung sorgfältig. Die gescheiterten Piloten liefen meist auf „Dumb RAG" (alles in den Kontext kippen), „Brittle Connectors" (kaputte API-Integrationen) und ohne event-getriebene Architektur. Die erfolgreichen Piloten hatten eine operative Schicht um das LLM: Memory, I/O und Berechtigungen. Der LLM-Kernel ist nicht der Engpass. Die umgebende Infrastruktur ist es.

Hier kommt VM0 ins Spiel

Wir haben Zero um eine architektonische Wette gebaut: Der Agent soll niemals das Credential halten. Nicht in seiner Umgebung, nicht in seinem Prompt, nicht in seinem Memory. Das Token bleibt auf der Plattform. Jeder ausgehende Aufruf des Agenten wird über einen Netzwerk-Proxy vermittelt, der pro Aufruf entscheidet, ob ein Auth-Header injiziert oder die Anfrage blockiert wird.

Das ist eine ungewöhnliche Wahl. Die gängigen Muster 2026 sind entweder dem Agenten eine eigene OAuth-Identität zu geben (schon habt ihr einen zweiten Principal zu auditieren und zu widerrufen) oder ihm eine Kopie des Nutzer-Tokens in einer Env-Variable auszuhändigen (schon kann das LLM eure Brieftasche lesen). Wir tun keins von beidem. So funktioniert es konkret.

Das Token erreicht den Agenten nie. Wenn ihr einen Connector mit Zero verbindet (GitHub, Slack, Gmail, Linear, Notion, HubSpot usw.), wird das OAuth-Token verschlüsselt auf der Plattform gespeichert. Refresh-Tokens bleiben in der Datenbank und verlassen sie nie. In der Sandbox gibt es keine GITHUB_TOKEN-Umgebungsvariable zu lesen, keine Secrets-Datei zu öffnen, kein Tool, das das Token zurückgibt.

Ein Netzwerk-Proxy vermittelt jeden Aufruf. Jede HTTP-Anfrage, die die Sandbox verlässt, läuft durch ein mitmproxy-basiertes Addon. Der Proxy identifiziert den Connector am Hostnamen, schaut die Firewall-Policy für diesen Agenten nach und prüft, ob Methode-und-Pfad erlaubt sind. Wenn ja, ruft der Proxy das Plattform-Webhook zurück. Die Plattform entschlüsselt das Token, aktualisiert es, wenn es abgelaufen ist, löst Header-Templates auf (${{ secrets.GITHUB_TOKEN }} wird zum realen Wert) und liefert nur die aufgelösten Auth-Header an den Proxy. Der Proxy injiziert diese Header in die ausgehende Anfrage. Wenn der Aufruf zurückkehrt, sind die Header aus dem Proxy-Speicher verschwunden. Der Agent hat sie nie gesehen.

Berechtigungen sind pro Agent, pro Connector und auf Endpoint-Ebene typisiert. Jeder Agent trägt ein Policy-Objekt, das jeden Connector auf einen Satz benannter Berechtigungsgruppen abbildet. github:repo-read ist kein vager Scope. Es ist ein Bündel spezifischer Methode-und-Pfad-Regeln, zum Beispiel GET /repos/{owner}/{repo}/pulls. GitHub-Zugriff zu gewähren, gewährt nicht GitHub. Es gewährt eine Form von Intent innerhalb von GitHub.

Drei Policy-Zustände, nicht zwei. Jede Berechtigung löst sich zu allow, deny oder ask auf. Letzteres fragt einen Menschen, bevor die Aktion feuert. Alles, was die Firewall nicht explizit matcht, fällt durch auf eine pro-Connector-unknownPolicy, die default auf deny steht. Least Privilege ist der Default, kein Opt-in.

Eine Sandbox pro Run. Jede Agent-Ausführung läuft in ihrer eigenen Firecracker-MicroVM mit isoliertem Netzwerk-Namespace. Wenn der Run endet, wird der Namespace abgebaut. Zwei Runs desselben Agenten sind zwei separate Sandboxes mit zwei separaten Audit-Trails.

Audit-Trail pro Anfrage. Derselbe Proxy, der allow/deny entscheidet, schreibt auch ein Per-Run-JSONL-Log mit Firewall-Metadaten zu jeder Anfrage: den Connector, die gematchte Berechtigungsgruppe, die spezifische gematchte Regel, die Entscheidung, den Zeitstempel. Diese Logs gehen zurück an die Plattform. Wenn ein CISO wissen muss, was der Agent am 14. April zwischen 15 und 17 Uhr CST tat, ist das eine Query.

Ein CLI, das seine eigenen Denials erklärt. Wenn eine Berechtigung einen Aufruf blockiert, kann der Agent (oder der Mensch daneben) zero doctor permission-deny <connector> --method <M> --path <P> ausführen und erhält die exakte Berechtigungsgruppe, die die Anfrage blockierte, plus einen Remediation-Link. zero doctor permission-change lässt Admins Berechtigungen direkt umschalten oder Mitglieder eine schriftliche Anfrage einreichen (auf 500 Zeichen begrenzt, damit die Begründung tatsächlich lesbar bleibt), die an einen Admin geroutet wird. Hochriskante Berechtigungen wie slack:chat:write oder gmail.send lösen eine zusätzliche Warnung aus, die auf eine sicherere Bot-gescopte Alternative verweist.

Zwei Rollen, ein Genehmigungsfluss. Owners und Admins ändern Berechtigungen direkt. Members reichen eine Anfrage mit Begründung ein, die an einen Admin geroutet wird. Es gibt keine dritte „Halb-Admin"-Stufe. Der Fluss ist klein genug, dass Leute ihn tatsächlich nutzen, was der Sinn der Sache ist.

Wir reservieren Computer Use für den schmalen Satz an Legacy-Systemen, die keine API anbieten. Alles andere läuft durch Skills. Jede Aktion ist Policy-geprüft. Jedes Credential bleibt auf der Plattform. Jede Entscheidung wird geloggt.

Wenn ihr über „noch ein KI-Autocomplete" hinaus seid und einen KI-Teamkollegen ausprobieren wollt, den euer Security-Team absegnet, schaut, wie Zero geplante Workflows handhabt, Produktions-Incidents triagiert oder ein morgendliches Produkt-Briefing fährt.

Die Copilot-Ära endet nicht. Sie wird in etwas Größeres absorbiert. Die Teams, die den nächsten Zyklus gewinnen, sind die, die den Unterschied verstehen.

Vom Copilot zum Kollegen: Was es heißt, wenn KI autonom im Workflow agiert