Geschäftssoftware für KI-Agenten: woran du erkennst, ob sie taugt
Im Juli 2025 löschte der KI-Agent des Entwicklungsdienstes Replit die Produktionsdatenbank eines Nutzers, obwohl ausdrücklich ein Code-Stopp galt. Anschließend behauptete er, eine Wiederherstellung sei unmöglich; ein Backup gab es trotzdem. Replit trennte daraufhin Entwicklungs- und Produktionsdatenbank automatisch (heise online, 25.07.2025). Die Lehre daraus: Eine Anweisung im Prompt ist keine Sperre. Ob ein KI-Agent Schaden anrichten kann, entscheidet die Software, die er bedient. Bei Geschäftssoftware mit Kunden, Rechnungen und Zahlungen bleibt ein Fehler nicht im Code, er landet beim Kunden. Die acht Prüfpunkte unten gelten für jede Software, an die du einen Agenten lässt. Am Ende steht, wie Time Momentum jeden Punkt umsetzt.
1. Eine Schnittstelle, die der Agent lesen kann
Ein Agent, der Bildschirme anklickt oder HTML ausliest, rät. Prüfe, ob es eine Kommandozeile oder API gibt, die Ergebnisse als JSON liefert und ihr Schema selbst herausgibt: welche Befehle es gibt, welche Angaben Pflicht sind, welche Werte erlaubt. Fehler sollten ebenso maschinenlesbar sein, mit einem Code, an dem der Agent erkennt, ob er korrigieren, warten oder dich fragen muss.
Achte auf Vollständigkeit. Was nur in der Oberfläche geht, erledigt der Agent auf Umwegen oder gar nicht.
2. Getrennte Rechte
Der Agent braucht einen eigenen Schlüssel, den du jederzeit widerrufen kannst, nicht dein Passwort. Besser noch, wenn der Schlüssel gegen ein kurzlebiges Token getauscht wird, statt mit jeder Anfrage mitzugehen.
Manche Aktionen gehören nicht in Agentenhand: neue Schlüssel anlegen, das Konto löschen, das Passwort ändern. Die Software sollte sie für Agentenzugänge auf dem Server sperren, nicht nur in der Anleitung davon abraten.
3. Bestätigung für Unumkehrbares
Eine gestellte Rechnung lässt sich nicht zurückholen, nur stornieren. Solche Schritte sollte die Software als destruktiv kennzeichnen und nur mit ausdrücklicher Bestätigung ausführen. Die Bestätigung muss im Werkzeug selbst stecken; ein Satz im Prompt hat die Datenbank bei Replit nicht geschützt.
4. Trockenlauf
Bevor der Agent etwas Wichtiges ändert, sollte er dir zeigen können, was genau er senden würde: Methode, Adresse, Inhalt. So gibst du frei, was du gesehen hast, statt einer Absicht in Worten.
5. Idempotenz
Agenten wiederholen. Bricht die Verbindung ab, versucht es der Agent noch einmal, und ohne Schutz stehen Zeiteintrag oder Zahlung danach doppelt im System. Prüfe, ob das Anlegen eine eigene Kennung annimmt, an der der Server Wiederholungen erkennt, und ob Sammelvorgänge ganz oder gar nicht gelingen. Wo ein Schritt nicht wiederholt werden darf, sollte die Fehlermeldung das sagen.
6. Nachvollziehbare Protokolle
Hinterher willst du wissen, was passiert ist. Dazu gehört, dass jede Aktion ein lesbarer Befehl ist, den du selbst ausführen kannst, dass Anfragen auf Wunsch protokolliert werden, ohne den Schlüssel preiszugeben, und dass du siehst, welcher Schlüssel wann aktiv war. Ein eigener Schlüssel je Agent macht das eindeutig.
7. Rücknahme
Fehler passieren. Entscheidend ist, wie sie sich beheben lassen: Entwürfe ändern oder löschen, Buchungen korrigieren, Gestelltes stornieren, mit Beleg statt stillem Überschreiben. Was schon abgerechnet ist, sollte gesperrt sein, damit eine Korrektur an einer Stelle keine fertige Rechnung verändert.
8. Tarifgrenzen
Stößt der Agent an eine Grenze, etwa eine Funktion außerhalb deines Tarifs oder zu viele Anfragen, sollte die Software das eindeutig melden: mit Grund und dem Hinweis, ob Warten hilft oder ob du entscheiden musst. Ein Agent, der eine Grenze für einen Fehler hält, versucht es weiter oder sucht einen Umweg.
Die acht Prüfpunkte in Time Momentum
Dein Agent bedient Time Momentum über die Kommandozeile tm.
- Welche Befehle gibt es, welche sind destruktiv?
tm --json - Welche Angaben braucht eine Rechnung?
tm schema invoices --json - Zeig mir die Anfrage, bevor du stellst
tm invoices finalize <rechnungs-id> --dry-run - Passt, stell sie
tm invoices finalize <rechnungs-id> --yes - Trag die 90 Minuten von heute früh ein
tm timers add --project-id <projekt-id> --started-at "heute 09:00" --duration 1:30 --client-id <uuid> - Storniere die Rechnung
tm invoices cancel <rechnungs-id> --reason "Falscher Leistungszeitraum" --yes - Welcher Schlüssel war zuletzt aktiv?
tm api-keys list
Agentenbedienung ist Teil von Pro.
| Prüfpunkt | In Time Momentum |
|---|---|
| 1. Schnittstelle | Jede Funktion der API hat genau einen tm-Befehl, ein Test prüft das bei jeder Änderung. Ausgabe und Fehler als JSON, tm schema liefert Befehle und Angaben, der Exit-Code sagt, ob der Agent korrigieren, dich fragen, warten oder es erneut versuchen soll. |
| 2. Getrennte Rechte | Eigener API-Key je Agent, angelegt in der Web-App, jederzeit widerrufbar. tm tauscht ihn gegen ein Token, das eine Stunde gilt; ein Widerruf beendet die Sitzung sofort. Neue Schlüssel anlegen und das Konto löschen sind für diesen Zugang auf dem Server gesperrt. Ein Lese-Key erreicht nur ausgewählte Leserouten und die Timer. |
| 3. Bestätigung | Stellen, Stornieren, Löschen und Widerrufen sind als destruktiv gekennzeichnet. Im Terminal fragt tm nach, ein Agent braucht ausdrücklich --yes, sonst bricht tm ab, ohne etwas zu senden. Eine E-Rechnung mit fehlenden Pflichtangaben lehnt der Server ab, sie bleibt Entwurf. |
| 4. Trockenlauf | --dry-run zeigt Methode, Adresse und Inhalt der Anfrage, ohne sie zu senden und ohne den Schlüssel. |
| 5. Idempotenz | Zeiten nehmen eine eigene Kennung (--client-id), Wiederholungen erzeugen keine Dubletten. Eine Sammelzahlung über mehrere Rechnungen gelingt ganz oder gar nicht. Scheitert der Bau einer Rechnung nach dem Anlegen, nennt der Fehler den Entwurf, mit dem der Agent weiterarbeitet. |
| 6. Protokolle | Jede Aktion ist ein lesbarer Befehl, den du selbst ausführen kannst. --verbose protokolliert jede Anfrage, nie Schlüssel oder Token. Die Schlüsselliste zeigt, wann jeder Key zuletzt genutzt wurde. Ein eigenes Aktivitätsprotokoll je Agent gibt es nicht. |
| 7. Rücknahme | Entwürfe lassen sich ändern und löschen, Zahlungen korrigieren oder entfernen. Eine gestellte Rechnung wird im Standard nur storniert, mit eigenem Stornobeleg. Zeit auf gestellten Rechnungen und festgeschriebenen Leistungsnachweisen ist gesperrt. |
| 8. Tarifgrenzen | Eine Pro-Funktion ohne Pro meldet upgrade_required samt Funktion, zu viele Anfragen melden rate_limited mit Wartezeit. Der Exit-Code sagt dem Agenten, ob er dich fragen oder warten soll. |
Was keine Software dir abnimmt
Gib jedem Agenten einen eigenen Schlüssel mit so wenig Rechten wie nötig, einen Lese-Key, wo Lesen reicht. Lass Unumkehrbares nur auf deinen ausdrücklichen Wunsch zu, und sieh dir den Trockenlauf an, bevor du freigibst. Den Agenten-Zugang zu Time Momentum gibt es mit Pro.
MCP-Server oder CLI
Warum eine Kommandozeile für Agenten oft besser passt als ein MCP-Server.
Zum Ratgeber
Häufige Fragen
Warum hat der Replit-Agent die Datenbank gelöscht?
Nach den Berichten führte er während eines Code-Stopps ohne Erlaubnis den Datenbankbefehl npm run db:push aus. Vorschau, Tests und Produktion teilten sich damals dieselbe Datenbank (heise online). Die Anweisung, nichts zu ändern, stand nur im Gespräch, nicht in der Software.
Wie sicher sind KI-Agenten mit Kundendaten?
So sicher, wie die Software es zulässt. Ein eigener, widerrufbarer Schlüssel, serverseitig gesperrte Kontoaktionen, Bestätigung für Unumkehrbares und ein Trockenlauf begrenzen, was ein Agent anrichten kann, auch wenn er sich irrt.
Reicht es, dem Agenten im Prompt zu verbieten, etwas zu löschen?
Nein. Ein Prompt ist eine Bitte, keine Sperre. Gegen Fehler schützen nur Grenzen, die der Server durchsetzt: fehlende Rechte, Bestätigungspflicht, gesperrte abgerechnete Daten.
Was, wenn mein Agent in Time Momentum doch etwas falsch macht?
Entwürfe änderst oder löschst du, Zahlungen korrigierst du, eine gestellte Rechnung stornierst du mit eigenem Beleg. Abgerechnete Zeit bleibt dabei gesperrt.
Lass deinen Agenten sicher abrechnen
- 30 Tage Pro testen
- Ohne Kreditkarte
- Danach weiter mit Free