Für stationäre Mobilfunkrouter finden sich diverse Einsatzfelder. Zum Beispiel: Es gibt in Ihrem Ort weder Glasfaser noch DSL oder Kabel, aber guten Handyempfang. Sie wechseln den Arbeitsort öfter zwischen angemietetem Workspace, Ferienhaus und Wohnung des Partners. Ihr Team und Sie wollen auf Messen oder in Konferenzräumen ein gemeinsames WLAN haben.

Im Familienurlaub möchten Sie Ihr iPhone nicht ständig als Hotspot zweckentfremden, oder Ihr iPhone hat noch kein 5G. Sie sind auf eine zuverlässige Internetverbindung für Ihr Business angewiesen und wollen ein leistungsfähiges Backup-System als Ergänzung zum kabelgebundenen Router.

Auf der WLAN-Seite sind stationäre Mobilfunkrouter oft so leistungsfähig wie klassische Router, sie benötigen lediglich Strom aus dem Netz und keine aufwendige Verkabelung.

Das war die Leseprobe unseres heise-Plus-Artikels „WLAN to go: Fünf Mobilfunkrouter mit 5G im Test“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.

Es klingt nach dem nächsten großen Skandal: Über 500.000 Zeilen Quellcode von Anthropics CLI-Tool Claude Code tauchen öffentlich auf. Die Security-Community horcht auf, Wettbewerber reiben sich die Hände, Kommentatoren wittern den nächsten Beweis, dass KI eh an allem schuld ist. Doch wer genauer hinschaut, findet keine ausgeklügelte Attacke, keinen Zero-Day-Exploit, nicht einmal Social Engineering. Sondern schlicht eine Source Map im npm-Paket, die da nicht hingehörte. Also bloß ein vergessener Schalter in der Build-Pipeline. System scheint hier nur die Schludrigkeit zu haben.

Debug-Artefakte im Produktions-Build – ein Klassiker

Source Maps sind nützliche Helfer in der Entwicklung. Sie bilden kompilierten Code zurück auf den lesbaren Quelltext – unverzichtbar beim Debuggen, fatal in der Produktion. Dass sie im fertigen Paket landen, passiert nicht durch einen raffinierten Angriff oder eine ausgerastete KI. Es passiert, weil niemand den Build-Prozess sauber konfiguriert hat. Oder weil die Konfiguration irgendwann still und leise überschrieben wurde. Oder weil schlicht niemand nachgeschaut hat.

Entwickler kennen das Muster. Es ist die vergessene .env-Datei im Git-Repository. Das Docker-Image mit eingebetteten Credentials. Die Debug-API, die seit Monaten offensteht, weil sie ja „nur intern“ ist. Genau das ist Prozessversagen.

Niemand fühlt sich zuständig

Moderne Build-Pipelines sind überaus komplex. Bundler, Transpiler, Minifier, Packager – jeder Schritt erzeugt Artefakte, jeder Schritt kann Dinge durchreichen, die nicht nach draußen gehören. Die Verantwortung dafür verteilt sich auf ein Tohuwabohu an Tools, Konfigurationsdateien und Teams. Am Ende fühlt sich niemand zuständig. „Die Pipeline macht das schon“ ist aktuell einer der gefährlichsten Sätze in der Softwareentwicklung.

Bei klassischen Projekten geht das meistens noch gut. Die Artefakte sind langweilig, der Schaden überschaubar. Bei einem KI-Tool wie Claude Code sieht das anders aus. Hier stecken im Code nicht nur Implementierungsdetails, sondern Architekturentscheidungen, Feature-Flags für unveröffentlichte Funktionen und die komplette Orchestrierungslogik eines agentischen Systems. Wer das lesen kann – und das kann jeder mit npm und etwas Geduld –, bekommt eine Blaupause frei Haus.

Tempo schlägt Sorgfalt

KI-Unternehmen stehen unter enormem Innovationsdruck. Releases folgen in kurzen Zyklen, Features müssen raus, bevor der Wettbewerber sie zeigt. In diesem Tempo bleiben Sicherheits-Gates auf der Strecke. Nicht aus Schlampigkeit oder gar Böswilligkeit, sondern aus Pragmatismus. Die nächste Demo zählt mehr als das nächste Audit.

Das Ergebnis: Tools, die tief in lokale Entwicklungsumgebungen eingreifen, Code lesen, schreiben und ausführen, werden mit derselben Release-Disziplin behandelt wie ein Frontend-Widget. Dass das schiefgeht, ist keine Überraschung. Es ist nur eine Frage der Zeit.

Bekannte Fehler, neue Dimension

Der aktuelle Vorfall wirkt nicht wie ein völlig isolierter Ausrutscher: Medienberichten zufolge ist es bereits die zweite unbeabsichtigte Offenlegung rund um Claude Code in etwas mehr als einem Jahr. Ganz allgemein kennt die Branche das Problem schon lange. OWASP listet „Cryptographic Failures“ (vormals Sensitive Data Exposure) seit Ewigkeiten in den Top Ten. Trotzdem passiert es immer wieder – nur dass die Konsequenzen wachsen.

Denn ein geleakter Quellcode ist hier mehr als ein PR-Problem. Er zeigt Wettbewerbern, wie Anthropic agentische Workflows orchestriert. Er zeigt Angreifern, wo die Logik Annahmen macht, die man ausnutzen kann. Er zeigt der Öffentlichkeit, dass ein Unternehmen, das Milliarden für KI-Sicherheit einwirbt, bei grundlegender Softwarehygiene patzt.

Firewalls helfen nicht gegen Schlamperei

Der Reflex nach solchen Vorfällen ist vorhersehbar: mehr Security-Tools, mehr Monitoring, mehr Abwehr nach außen. Aber gegen was genau? Hier gab es keinen Angreifer, den man hätte aufhalten können. Keine Firewall der Welt schützt vor einem falsch konfigurierten Build-Skript.

Was helfen würde, ist weniger spektakulär: automatisierte Prüfungen, die vor jedem Release den Paketinhalt scannen. Klare Verantwortlichkeiten im Build-Prozess. Vier-Augen-Prinzip bei Releases sensibler Tools. Alles Dinge, die in der klassischen Softwareentwicklung längst Standard sein sollten – und die offenbar auch bei einem der bestfinanzierten KI-Unternehmen der Welt nicht zuverlässig greifen.

Der eigentliche Weckruf

Und genau weil der eigentlich etablierte Prozess das Problem ist, sollte dieser Vorfall mehr beunruhigen als ein aufsehenerregender KI-Hack. Gegen die in der IT-Branche an vielen Stellen vorherrschende Nachlässigkeit hilft nur Disziplin – und die lässt sich bekanntlich schlecht skalieren.

(fo)

OpenAI bietet mit Codex ein eigenes KI-Coding-Tool an. Die Agenten-Plattform unterstützt Entwicklerinnen und Entwickler dabei, ihre Entwicklungsprozesse zu beschleunigen und zu automatisieren. Unser KI-Coding-Experte Rainer Stropek zeigt, wie man Codex in VS Code, im Terminal, im Web, über SDKs und in der OpenAI Agent Platform produktiv nutzt. Unser Classroom OpenAI Codex für Entwickler – Coding-Agenten in VS Code, Terminal und CI/CD geht dabei auf die neuesten Entwicklungen ein. Erst kürzlich veröffentlichte OpenAI die Version 5.3, die wieder zahlreiche Neuerungen bringt und die unser Experte detailliert behandelt.

Zunächst steht der Unterschied zwischen ChatGPT und Codex im Vordergrund sowie welches Modell sich für welche Aufgabe am besten eignet. Darauf aufbauend lernen Teilnehmende typische Pair-Programming-Workflows und Spec-driven Development mit TypeScript-Projekten kennen. Anschließend geht es ins Terminal mit Slash-Commands, Terminal User Interface (TUI) vs. Headless-Modus, Konfiguration, AGENTS.md und Best Practices für sichere Änderungen an der Codebasis.

Codex Cloud und Multi-Agentensystem

Danach steht Codex im Web im Fokus. Teilnehmende delegieren Aufgaben an Codex Cloud, integrieren Codex in GitHub-Workflows und nutzen Codex für Code Reviews. Darüber hinaus bauen sie anhand eines praktischen Beispiels in TypeScript ein Multi-Agentensystem mit dem Open Source OpenAI Agent SDK und vertiefen ihr Wissen über die Programmierschnittstellen Codex SDK und Model Context Protocol (MCP). Rainer Stropek zeigt, wie man Entwicklungsprozesse automatisiert und Codex mit MCP-Servern sowie -Clients verbindet.

Abschließend ordnet unser Experte Codex in die OpenAI Agent Platform ein: AgentKit, ChatKit, Agents SDK und Apps SDK. Er zeigt, wie man aus einem Codex-basierten Coding-Agenten eine Multi-Agenten-Lösung macht, auf die man über Web-UIs (ChatKit) und ChatGPT-Apps zugreift. Alle Sessions bieten zahlreiche Beispiele, praxisnahe Workflows und setzen einen Fokus auf Teams, die Codex oft über ihre ChatGPT-Subscription zur Verfügung haben. Die Termine sind:

• 22.04.26: Programmieren mit OpenAI Codex in Visual Studio Code
• 29.04.26: Codex im Terminal – Codex CLI in der Praxis
• 06.05.26: Codex Cloud und GitHub-Integration – Aufbau von Multi-Agentensystemen
• 13.05.26: Codex SDK und Model Context Protocol – Automatisierung von Entwicklungsprozessen
• 20.05.26: Codex in der OpenAI Agent Platform – KI-Agenten mit Web-UI und ChatGPT-Integration erstellen

Praxis- und Expertenwissen – live und für später

Die Sessions haben eine Laufzeit von jeweils vier Stunden und finden von 9 bis 13 Uhr statt. Alle Teilnehmenden können sich nicht nur auf viel Praxis und Interaktion freuen, sondern haben auch die Möglichkeit, das Gelernte mit allen Aufzeichnungen und Materialien im Nachgang zu wiederholen und zu vertiefen. Fragen werden direkt im Live-Chat beantwortet und Teilnehmende können sich ebenfalls untereinander zum Thema austauschen. Der nachträgliche Zugang zu den Videos und Übungsmaterialien ist inklusive.

Weitere Informationen und Tickets finden Interessierte auf der Website des Classrooms.

(cbo)