Was KI Agenten bei uns nicht dürfen

Ein KI Agent sollte nichts tun dürfen, was sich nicht zurückholen lässt oder ohne Prüfung nach außen geht. Dazu zählen endgültiges Löschen, Veröffentlichen ohne Freigabe und der Umgang mit Zugangsdaten. Auch echte Kundendaten gehören nicht an externe Modelle. Welche Grenzen genau passen, hängt vom Risiko eurer Systeme ab.

Ja, beim Coding geht es gar nicht ohne. Wichtig ist, wo er schreiben darf und wie ein Fehler zurückgeholt wird. Eine kleine Schreibfläche, Regeln im Code, Git und menschliche Freigabe halten den Schaden klein. Bei einem Mail Postfach kann die richtige Antwort anders ausfallen, weil eine gesendete Mail nicht zurückkommt.

Human in the Loop heißt, dass Menschen an festgelegten Stellen eingebunden bleiben. Sie prüfen Ergebnisse, geben Aktionen frei oder treffen die Entscheidung selbst. Das muss nicht jeder einzelne Schritt sein. Sinnvoll sind Freigaben dort, wo ein Fehler teuer wird oder andere ihn sehen, zum Beispiel beim Veröffentlichen einer Seite.

Nein. Ein Prompt beeinflusst das Modell, er erzwingt aber nichts. Was nie passieren darf, gehört in Code, Berechtigungen oder Pipeline. Prompt und Rules Files sind trotzdem sinnvoll, weil sie dem Agenten Richtung geben und Fehlversuche sparen. Die harte Grenze muss aber auch dann halten, wenn das Modell falsch entscheidet.

In der opencode.json legt ihr unter permission für Tools wie edit, read und bash die Stufen allow, ask oder deny fest. Für einzelne Befehle und Pfade gibt es Muster, und bei mehreren Treffern gewinnt die letzte Regel. Deny bleibt laut Dokumentation auch im Auto Modus aktiv. Eine Sandbox ersetzt das aber nicht.

Legacy Code hat oft zu wenige Tests. Ein autonomer Agent würde dort schnell ändern, und niemand sähe, was dabei bricht. Darum richten wir zuerst Quality Gates ein, also statische Analyse, Unit Tests, Functional Tests und Cypress E2E. Danach räumen wir stark manuell mit KI Hilfe auf oder bauen parallel ein neues Projekt.

Am einfachsten liegen im Entwicklungssetup gar keine echten Daten. Bei uns arbeiten Coding Modelle außerhalb der eigenen Infrastruktur nur gegen lokale Umgebungen mit Fake Daten aus Faker oder mit anonymisierten Daten. Dann kann das Team passende Modelle frei wählen. KI Funktionen im Produkt, die echte Daten verarbeiten, plant ihr getrennt davon.

Setzt harte Budgets vor die Modelle, bevor ein Agent lange allein läuft. Ein Proxy wie LiteLLM zeigt Tokens und Kosten pro Nutzer und stoppt beim Limit. Zusätzlich hilft eine Obergrenze für Tool Aufrufe im Agenten. So bleibt ein festgefahrener Loop ein kleines Problem und wird nicht zu einer großen Rechnung.

Bei einer Prompt Injection stehen Anweisungen in einem Text, den der Agent verarbeitet, zum Beispiel in einer Mail oder auf einer Webseite. Das Modell kann sie mit Aufträgen verwechseln. Darum sollte fremder Inhalt als Daten gelten, und Agenten mit Zugriff auf fremde Texte brauchen besonders enge Rechte und Freigaben für Aktionen nach außen.

Im Gegenteil, wenige harte Grenzen machen Agenten schneller. Wer die gefährlichen Stellen gesichert hat, muss nicht jeden kleinen Schritt bestätigen. Zu viele Rückfragen führen oft dazu, dass Menschen blind zustimmen. Klärt deshalb einmal im Team, was erlaubt, was nachgefragt und was verboten ist, und lasst den Rest laufen.

Listet auf, welche Systeme ein Agent erreichen kann. Fragt dann bei jeder Aktion: Lässt sie sich zurückholen, sehen andere das Ergebnis und berührt sie Secrets oder echte Daten? Daraus ergeben sich die Stufen erlauben, nachfragen und verbieten. Prüft die Liste regelmäßig, denn mit neuen Tools wächst auch die Reichweite eines Agenten.

Es gibt keine festen Pakete. Wir starten mit einem kostenlosen Kennenlernen und schauen uns euer Setup an. Danach schätzen wir den Aufwand und rechnen transparent nach Minuten ab. So bezahlt ihr nur die Zeit, die wirklich an eurem Projekt anfällt, ob für ein einzelnes Setup oder für längere Begleitung.