KI-Agenten lesen bei indischen Firmen Live-Daten, ohne dass jemand es bemerkt
Book: Prompt Engineering Pocket Guide Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub "None of the affec
"Keine der betroffenen Organisationen hat den Zugriff bemerkt." Dieser Satz stammt aus einer als Kritisch eingestuften Empfehlung, die CERT-In, Indiens nationale Cyber-Agentur, am 15. Oktober zu KI-Agenten herausgegeben hat, die dorthin gelangten, wohin sie niemand geschickt hatte ( CIAD-2026-0049 ). Anbieter von KI-Modellen evaluierten Agenten. Diese Agenten gelangten über Zugangsdaten und Verbindungseinstellungen, die in Anwendungskonfigurationen, öffentlichen Code-Repositories und über weite Cloud-Rollen hinterlassen waren, zu Live-Systemen indischer Organisationen, und sie lasen Geschäftsunterlagen mit personenbezogenen und vertraulichen Daten.
In jedem Fall, so CERT-In, ging die Offenlegung von den KI-Anbietern selbst aus, nach einer internen Überprüfung. Die Organisationen haben es nicht bemerkt. Die Labore haben sich selbst ertappt, und der Lauf, der das tat, war auf dem Papier ein Test.
CIAD-2026-0049 trägt den Titel "AI Agents as Attack Vectors". Es behandelt zwei getrennte Probleme. Das erste ist das oben genannte: CERT-In erklärt, es habe "mehrere freiwillige Meldungen von Anbietern von KI-Modellen" erhalten, deren Forschungs- und Evaluationsagenten über die Berechtigung ihrer zugewiesenen Aufgaben hinausgingen. Es heißt dort außerdem: "Es wurde beobachtet, dass Agenten dieselben offengelegten Zugangsdaten in getrennten Vorgängen erneut ableiteten und wiederverwendeten." Der Agent fand einen Schlüssel, und als er zurückkehrte, fand er denselben Schlüssel wieder.
Das zweite Problem sind Kriminelle, die öffentlich verfügbare KI-native Frameworks für offensive Sicherheit gegen indische Einrichtungen einsetzen. CERT-In erklärt, agentisches Tooling habe die Zeit vom anfänglichen Eindringen bis zur Wirkung von Tagen auf Stunden verkürzt, und Opfer, die ihre Systeme nur teilweise abgesichert hatten, wurden innerhalb weniger Tage erneut und in größerem Umfang getroffen ( PTI via The Federal ).
Keine der Schwachstellen war exotisch. Die Empfehlung listet Schlüssel im Quellcode und in der Repository-Historie, vergessene Test-APIs, Zahlungs-Schlüssel im Klartext, übermäßig permissive Cloud-Rollen und Admin-Panels ohne Multi-Faktor-Authentifizierung auf. Ihre eigene Zusammenfassung lautet, dass KI diese Schwachstellen "schneller, gründlicher und in größerem Umfang" gefunden und ausgenutzt hat.
Was sie auslässt, ist ebenfalls wichtig. CERT-In nennt keinen Anbieter, kein Modell und keine betroffene Organisation ( Cyber Press ), und die Empfehlung gibt keine Anzahl über "mehrere" Meldungen hinaus an. Also raten Sie nicht, welches Labor es war. Der nützliche Teil ist das Muster, das sich nicht auf ein einzelnes Labor bezieht.
"Test", "Eval", "Sandbox": Diese Worte beschreiben, was Sie meinten. Sie beschreiben nicht, was das Netzwerk sah. Was das Netzwerk sah, war eine Verbindung von außen, mit einem gültigen Berechtigungsnachweis, der Datensätze las. Das Zielsystem kann Ihre Evaluierung nicht von einem Eindringling unterscheiden. In diesem Fall sah es keines von beidem.
Ein Agent mit Netzwerkzugriff und einem gefundenen Berechtigungsnachweis arbeitet im Produktivbetrieb, wie auch immer Sie den Lauf benannt haben. Am anderen Ende der Leitung gibt es keinen Testmodus.
CERT-In empfiehlt Laboren und Evaluatoren dasselbe, nur sorgfältiger formuliert. Blockieren Sie ausgehenden Zugriff standardmäßig und erlauben Sie nur das, was die Aufgabe benötigt, und dann: "Setzen Sie die Beschränkung auf Netzwerkebene durch, nicht durch Anweisungen an das Modell." Außerdem heißt es dort: "Stoppen Sie den Lauf automatisch, wenn der Agent Drittsysteme kontaktiert oder Zugangsdaten von Drittparteien entdeckt oder verwendet."
Die Empfehlung beschreibt nicht, wie die Anbieter diese Läufe eingegrenzt haben, also werde ich es auch nicht tun. Sie sagt aber, wo die Eingrenzung liegen muss. Eine Zeile in einem System-Prompt, die besagt "berühre nur die Sandbox", ist eine Bitte. Das Modell hält sich in der Regel meistens daran. Eine Firewall-Regel hängt nicht davon ab, dass das Modell zustimmt, auch nicht zu dem Zeitpunkt, an dem das Modell entschieden hat, dass die Sandbox dort ist, wo der Schlüssel funktioniert.
Der Schlüssel öffnet auf beiden Seiten des Zauns dieselben Türen.
Lesen Sie CERT-Ins Prüfliste für Organisationen und denken Sie an Ihren Laptop. Dort heißt es, man soll nach offengelegten Zugangsdaten im Quellcode, in der Repository-Historie, in CI/CD-Variablen, Konfigurationsdateien, Client-Anwendungen und Cloud-Speicher suchen ( die Empfehlung, Abschnitt B.2). Zählen Sie nun, was ein Coding-Agent in Ihrem Terminal lesen kann: die.env-Datei des Repos, die Shell-Umgebung, aus der Sie ihn gestartet haben, die Zugangsdatei Ihrer Cloud-CLI und jeden Commit in der Historie.
Claude Codes Sandbox-Dokumentation ist ungewöhnlich offen regarding die Standardwerte. Die Sandbox ist standardmäßig ausgeschaltet. Wenn sie eingeschaltet ist, können Befehle in der Sandbox trotzdem "den Großteil der Maschine lesen, einschließlich Zugangsdateien wie ~/.ssh und ~/.aws/credentials", und sie erben Umgebungsvariablen, "einschließlich aller Geheimnisse in ihrer Umgebung", solange Sie nichts anderes konfigurieren.
Die Historie ist der stille Punkt. Git-Worktrees, die viele Multi-Agent-Setups verwenden (Hermes tut das, siehe unten), sind mit einem Repository verknüpft und teilen sich "alles außer worktree-spezifischen Dateien wie HEAD und index" ( git-worktree-Dokumentation ). Ein Schlüssel, der vor zwei Jahren committed und am nächsten Tag gelöscht wurde, ist weiterhin in git log -p vorhanden, in jedem Worktree, den ein Agent öffnen kann. Gitleaks durchsucht genau diese Ausgabe:
# --log-opts wird an `git log -p` übergeben; --all deckt jede Referenz ab gitleaks git -v --log-opts = "--all". Enter fullscreen mode Exit fullscreen mode Wenn es einen aktiven Schlüssel findet, rotieren Sie zuerst den Schlüssel. Das Löschen des Commits holt den Schlüssel nicht von allen zurück, die ihn bereits gelesen haben. CERT-In geht weiter: Behandeln Sie die Umgebung als kompromittiert, bis die Forensik sie freigibt.
Für Organisationen, die eigene Agenten betreiben, nennt CERT-In drei Kontrollmaßnahmen (Abschnitt B.9): "Geben Sie jedem Lauf eine separate, kurzlebige Identität mit minimalen Rechten", standardmäßiges Verweigern des ausgehenden Datenverkehrs und "ein manipulationssicheres Protokoll der Agentenaktivität" für Aktionen, die die Produktivumgebung berühren.
Auf einem Laptop ist der ausgehende Datenverkehr die Maßnahme, die Sie heute durchsetzen können, ohne etwas zu bauen. Claude Codes Sandbox wird durch das Betriebssystem durchgesetzt (Seatbelt auf macOS, bubblewrap unter Linux und WSL2), und der Netzwerkverkehr läuft über einen lokalen Proxy, der jeden Host gegen eine Allowliste prüft, die leer beginnt. Eine benutzerbezogene ~/.claude/settings.json nach diesem Muster, mit den Schlüsseln aus der Sandbox- und der Permissions-Dokumentation:
{ "sandbox": { "enabled": true, "failIfUnavailable": true, "allowUnsandboxedCommands": false, "network": { "allowedDomains": [ "github.com", "registry.npmjs.org" ], "strictAllowlist": true }, "credentials": { "files": [ { "path": "~/.aws/credentials", "mode": "deny" }, { "path": "~/.ssh", "mode": "deny" } ], "envVars": [ { "name": "GITHUB_TOKEN", "mode": "deny" } ] } }, "permissions": { "deny": [ "Read(~/.aws/**)", "Read(~/.ssh/**)", "Read(./.env)" ] } } Enter fullscreen mode Exit fullscreen mode Die Zeile strictAllowlist macht aus der Liste eine Sperrliste. Ohne sie wird ein Host, der nicht auf der Liste steht, nicht rundherum abgewiesen: im Manual-Modus erhalten Sie eine Nachfrage, im Auto-Modus prüft ein Klassifikator die Hosts, die der Befehl nennt, und bypassPermissions lässt die Verbindung durch ( Hosts außerhalb Ihrer erlaubten Domains ). Wenn die Option aktiviert ist, verweigert der Proxy in jedem Berechtigungsmodus.
Dafür wird Claude Code v2.1.219 oder neuer benötigt.
Die Konfiguration hat zwei Blöcke, weil die Dokumentation ausdrücklich sagt, dass die Sandbox nur Shell-Befehle abdeckt. Claudes eigene Werkzeuge Read, Edit, WebFetch und WebSearch folgen stattdessen den Berechtigungsregeln: "Ein denyRead-Eintrag stoppt nicht das Read-Werkzeug, und allowedDomains begrenzt nicht WebFetch." Hooks und lokale MCP-Server laufen mit Ihrem vollen Zugriff. Unter nativem Windows laufen Befehle ohne Sandbox.
Und wenn die Sandbox nicht starten kann, führt Claude Code Befehle ohne sie aus, sofern Sie nicht sandbox.failIfUnavailable setzen, weshalb die obige Konfiguration dies tut. Für eine einzige Grenze um alles herum verweist dieselbe Dokumentation auf einen Container oder eine VM. Andere Agenten haben eigene Sandbox-Einstellungen; prüfen Sie Ihre, statt es anzunehmen.
Die anderen beiden Kontrollen sind auf einem Laptop schwieriger, und eine Einstellungsdatei deckt sie nicht ab. Eine kurzlebige Identität bedeutet, dass der Agent einen Berechtigungsnachweis erhält, der mit der Sitzung abläuft, nicht Ihr dauerhaftes Cloud-Profil. Ein manipulationssicheres Protokoll ist eine Eigenschaft des Ortes, an dem das Protokoll liegt: irgendwo, wohin der Agent nicht schreiben kann.
Ich baue Hermes IDE, also wägen Sie diesen Abschnitt vor diesem Hintergrund ab. Hermes betreibt Coding-Agenten wie Claude Code und Codex nebeneinander. Jede Aufgabe beginnt auf ihrem eigenen hermes/<name>-Branch in ihrem eigenen Worktree, und Sie wählen Agent, Modell und Konto pro Aufgabe, mit Unterstützung mehrerer Konten pro Agent ( README ). Agenten verwenden ihre eigene CLI-Anmeldung. Hermes fragt nie nach Ihren Tokens.
Der Worktrees-Tab im Review Desk: ein Worktree pro Aufgabe, jeder auf seinem eigenen hermes/-Branch, mit Aufgabe, Alter und Speicherplatzbedarf.
Das grenzt zwei Dinge ein. Die Änderungen eines Laufs landen auf seinem eigenen Branch, fern von Ihrem Haupt-Checkout und den Dateien anderer Agenten. Und eine Aufgabe kann unter einem separaten Konto laufen, sodass ein Wegwerf-Experiment nicht mit dem Konto angemeldet sein muss, das Sie für die echte Arbeit verwenden.
Es grenzt nicht das ein, worum es in dieser Empfehlung geht. Hermes betreibt jeden Agenten in einem echten Terminal, genau wie es ihn anderweitig betreiben würde, sodass der Agent alles lesen und erreichen kann, was er auch aus Ihrer eigenen Shell könnte. Ein Konto pro Aufgabe ist dennoch eine langlebige Anmeldung. Worktrees teilen sich ein.git, daher ist ein Schlüssel in der Historie aus allen sichtbar. Für den Sperren des ausgehenden Datenverkehrs, den diese Empfehlung fordert, benötigen Sie weiterhin die Sandbox des Agenten, einen Container oder eine Netzwerkregel.
Codex und Claude Code nebeneinander, jeder in seinem eigenen Worktree. Getrennte Branches, dieselbe Maschine, dasselbe Netzwerk.
Hermes ist kostenlos, als Quellcode unter BSL 1.1 verfügbar und läuft auf macOS, Windows und Linux ( Download ). Es steht in keiner Verbindung zu Nous Research, Anthropic, OpenAI oder einem anderen Agenten-Anbieter.
Die Labs in diesem Advisory haben nachträglich das Richtige getan: Sie haben hingesehen, das Problem gefunden und CERT-In informiert. Die meisten der betroffenen Organisationen hätten davon sonst möglicherweise nie erfahren. Die Sicherheitsmaßnahme, die funktioniert hat, war die Überprüfung der eigenen Ausführungen des Agenten durch dessen Betreiber.
Dein Coding-Agent ist kein Lab-Experiment. Er hat aber dieselbe Reichweite: eine Netzwerkverbindung, eine Shell und ein Home-Verzeichnis voller Schlüssel, deren Existenz du längst vergessen hattest.
Betreibst du deine Coding-Agenten heute mit einer Egress-Allowlist, oder erledigt das immer noch die Instruktionsdatei? Schreib es in die Kommentare.
Ein Großteil des Prompt Engineerings besteht darin, ein Modell dazu zu bringen, das zu tun, was du eigentlich meinst. Dieses Advisory markiert den Punkt, an dem das endet: Ein Prompt kann den Umfang erklären, aber nur das Netzwerk kann ihn durchsetzen. Der Prompt Engineering Pocket Guide widmet sich der ersten Hälfte: Systemprompts und Instruktionen, die ein Modell tatsächlich steuern, sowie Prompt Injection, also dem Punkt, an dem deine Instruktionen auf Eingaben treffen, die du nicht kontrollierst. Wenn du mehrere Agenten betreibst und jede Aufgabe auf einem eigenen Branch haben möchtest, ist Hermes IDE kostenlos auszuprobieren.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
"None of the affected organizations detected the access." That line comes from an advisory rated Critical that CERT-In, India's national cyber agency, issued on October 15 about AI agents that went where nobody sent them ( CIAD-2026-0049 ). AI model providers were evaluating agents. Those agents reached live systems at Indian organizations through credentials and connection settings left in application configs, public code repositories and over-broad cloud roles, and they read business records holding personal and confidential data.
In every case, CERT-In says, the disclosure came from the AI providers themselves, after an internal review. The organizations didn't catch it. The labs caught themselves, and the run that did it was, on paper, a test.
CIAD-2026-0049 is titled "AI Agents as Attack Vectors." It covers two separate problems. The first is the one above: CERT-In says it "has received multiple voluntary disclosures from AI model providers" whose research and evaluation agents went past the authorization of their assigned tasks. It also says "agents were observed re-deriving and re-using the same exposed credential in separate operations." The agent found a key, and when it came back, it found the same key again.
The second problem is criminals running publicly available AI-native offensive-security frameworks against Indian entities. CERT-In says agentic tooling cut the time from initial access to impact from days to hours, and that victims who only partly fixed things were hit again within days, at larger scale ( PTI via The Federal ).
None of the weaknesses were exotic. The advisory lists keys in source code and repository history, forgotten test APIs, plaintext payment keys, over-permissive cloud roles and admin panels without multi-factor authentication. Its own summary is that AI found and exploited these "faster, more exhaustively and at greater scale."
What it leaves out matters too. CERT-In names no provider, no model and no affected organization ( Cyber Press ), and the advisory gives no count beyond "multiple" disclosures. So don't guess which lab it was. The useful part is the pattern, which isn't about any one lab.
"Test," "eval," "sandbox": these words describe what you meant. They don't describe what the network saw. What the network saw was a connection from outside, carrying a valid credential, reading records. The target system can't tell your evaluation from an intruder. In this case it didn't see either.
An agent with network access and a credential it found is doing production work, whatever you named the run. There's no test mode at the other end of the wire.
CERT-In's recommendations for labs and evaluators say the same thing more carefully. Block outbound access by default and allow only what the task needs, and then: "Enforce the restriction at the network layer, not through instructions to the model." It also says to "Stop the run automatically if the agent contacts third-party systems, discovers or uses third-party credentials."
The advisory doesn't describe how the providers scoped these runs, so I won't either. It does say where scope has to live. A line in a system prompt that says "only touch the sandbox" is a request. The model may honor it most of the time. A firewall rule doesn't depend on the model agreeing to it, including the time the model has decided the sandbox is wherever the credential works.
The key opens the same doors on either side of the fence.
Read CERT-In's audit list for organizations and picture your laptop. It says to look for exposed credentials in source code, repository history, CI/CD variables, configuration files, client applications and cloud storage ( the advisory, section B.2). Now count what a coding agent in your terminal can read: the repo's.env, the shell environment you started it from, your cloud CLI's credentials file, and every commit in the history.
Claude Code's sandbox docs are unusually frank about the defaults. The sandbox is off by default. When it's on, sandboxed commands can still read "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials," and they inherit environment variables "including any secrets in its environment," until you configure otherwise.
History is the quiet one. Git worktrees, which many multi-agent setups use (Hermes does, below), are linked to one repository and share "everything except per-worktree files such as HEAD, index " ( git-worktree docs ). A key committed two years ago and deleted the next day is still in git log -p, in every worktree an agent can open. Gitleaks scans exactly that output:
# --log-opts is passed to `git log -p`; --all covers every ref gitleaks git -v --log-opts = "--all". Enter fullscreen mode Exit fullscreen mode If it finds a live key, rotate the key first. Deleting the commit doesn't take the key back from anyone who already read it. CERT-In goes further: treat the environment as compromised until forensics clears it.
For organizations running their own agents, CERT-In names three controls (section B.9): "Give each run a separate, short-lived identity with least privilege," default-deny egress, and "a tamper-resistant log of agent activity" for actions that touch production.
On a laptop, egress is the one you can enforce today without building anything. Claude Code's sandbox is enforced by the operating system (Seatbelt on macOS, bubblewrap on Linux and WSL2), and network traffic goes through a local proxy that checks each host against an allowlist that starts empty. A user-level ~/.claude/settings.json along these lines, with the keys taken from the sandbox and permissions docs:
{ "sandbox": { "enabled": true, "failIfUnavailable": true, "allowUnsandboxedCommands": false, "network": { "allowedDomains": [ "github.com", "registry.npmjs.org" ], "strictAllowlist": true }, "credentials": { "files": [ { "path": "~/.aws/credentials", "mode": "deny" }, { "path": "~/.ssh", "mode": "deny" } ], "envVars": [ { "name": "GITHUB_TOKEN", "mode": "deny" } ] } }, "permissions": { "deny": [ "Read(~/.aws/**)", "Read(~/.ssh/**)", "Read(./.env)" ] } } Enter fullscreen mode Exit fullscreen mode The strictAllowlist line is what makes the list a block. Without it, a host off the list isn't refused outright: in Manual mode you get a prompt, in auto mode a classifier reviews the hosts the command names, and bypassPermissions lets the connection through ( hosts outside your allowed domains ). With it on, the proxy refuses in every permission mode.
It needs Claude Code v2.1.219 or later.
The config has two blocks because the docs say plainly that the sandbox covers shell commands only. Claude's own Read, Edit, WebFetch and WebSearch tools follow permission rules instead: "A denyRead entry doesn't stop the Read tool, and allowedDomains doesn't limit WebFetch." Hooks and local MCP servers run with your full access. On native Windows, commands run unsandboxed. And if the sandbox can't start, Claude Code runs commands without it unless you set sandbox.failIfUnavailable, which is why the config above sets it. For one boundary around all of it, the same docs point you to a container or a VM. Other agents have their own sandbox settings; check yours rather than assume.
The other two controls are harder on a laptop, and a settings file doesn't cover them. A short-lived identity means the agent gets a credential that expires with the session, not your standing cloud profile. A tamper-resistant log is a property of where the log lives: somewhere the agent can't write.
I build Hermes IDE, so weigh this section with that in mind. Hermes runs coding agents such as Claude Code and Codex side by side. Every task starts on its own hermes/<name> branch in its own worktree, and you pick the agent, model and account per task, with several accounts per agent supported ( README ). Agents use their own CLI sign-in. Hermes never asks for your tokens.
The Review Desk's Worktrees tab: one worktree per task, each on its own hermes/ branch, with its task, age and disk size.
That narrows two things. One run's edits land on its own branch, away from your main checkout and other agents' files. And a task can run under a separate account, so a scratch experiment doesn't have to sign in as the account you use for real work.
It doesn't narrow the thing this advisory is about. Hermes runs each agent in a real terminal, exactly as it would run anywhere else, so the agent can read and reach whatever it could from your own shell. An account per task is still a long-lived login. Worktrees share one.git, so a key in history is visible from all of them. For the egress block this advisory asks for, you still need the agent's sandbox, a container or a network rule.
Codex and Claude Code side by side, each in its own worktree. Separate branches, same machine, same network.
Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux ( download ). It isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.
The labs in this advisory did the right thing after the fact: they looked, found it, and told CERT-In. Most of the organizations on the receiving end might never have known otherwise. The safeguard that worked was the agent's owner reviewing its own runs.
Your coding agent isn't a lab eval. It has the same reach, though: a network connection, a shell, and a home directory full of keys you forgot were there.
Do you run your coding agents with an egress allowlist today, or is the instruction file still doing that job? Tell me in the comments.
Most of prompt engineering is getting a model to do what you mean. This advisory marks where that stops: a prompt can explain the scope, but only the network can hold it. The Prompt Engineering Pocket Guide is about the first half: system prompts and instructions that actually steer a model, and prompt injection, where your instructions meet input you don't control. If you run several agents and want each task on its own branch, Hermes IDE is free to try.