Zum Inhalt springen

Bestätigungen und Sicherheit

Wenn ein Agent ein Cloud-Konto steuert, ist der gefährliche Fehlermodus nicht der Tippfehler — es ist ein selbstsicherer Agent, der die falsche richtige Sache tut: das Produktionsmodell statt des Testmodells löscht, einen Entwurf veröffentlicht, den niemand geprüft hat, oder auf ein Gerät deployt, dessen Besitz du vergessen hattest. Die Antwort von SenseCraft CLI ist ein Bestätigungsprotokoll, dem Agenten folgen müssen.

Deine erste Nachricht ist Absicht, keine Zustimmung.

Plain Text
du: Modell 63760 löschen
Agent: Dadurch wird Modell 63760 in der Umgebung Global gelöscht. Gelöschte
Modelle lassen sich nicht wiederherstellen. Bestätigen?
du: bestätigen
Agent: erledigt — gelöscht.

Jeder L2-Schreibvorgang folgt diesem Muster: Der Agent stellt eine Frage, die die Operation, die Umgebung und das Objekt (mit Kennung) benennt — plus die Konsequenz. Nur eine neue Antwort von dir — „confirm“, „yes“, „bestätigen“ — schaltet den eigentlichen Befehl mit --yes frei. Die vollständige Liste der abgesicherten Befehle steht in Ausgabe und Sicherheit.

Was ausdrücklich keine Bestätigung ist:

  • „Modell 63760 löschen“ (die erste Anfrage selbst)
  • „Ja, ich habe doch schon gesagt, dass du es löschen sollst“ in derselben Nachricht
  • Alles, was der Agent aus Tonfall oder Kontext ableiten könnte

Das wird doppelt durchgesetzt — in den Skills, die der Agent liest, und in der CLI selbst: Ein nicht-interaktiver (Agent-)Lauf eines L2-Befehls ohne --yes scheitert mit confirmation required, sodass nicht einmal ein manipulierter Prompt das Tor überspringen kann.

Zwei Konsolen-Dialoge haben rechtliche Bedeutung, daher bekommen sie eigene Flags:

FlagErscheint beiKonsolen-Äquivalent
--agree-declarationapp publishdas Kontrollkästchen „Declaration for Publishing“

Ein guter Agent zeigt dir die Erklärung (Declaration / Disclaimer) und wartet auf ein separates „Ich stimme zu“, bevor er eines der Flags verwendet.

  • Agenten maskieren Tokens, Zugangsschlüssel und die Werte von device_key / token der Dev-Kits — du siehst Muster wie sk-****, nie den vollständigen Wert.
  • Füge keine Keys in den Chat ein. Wenn der Agent eingerichtete Zugangsdaten braucht, ist der korrekte Ablauf, dass du den Zugangsschlüssel im Account-Center erstellst und auth add lokal ausführst.
  • Öffentliche file_urls von Modellen werden nie angezeigt, weil die Plattform sie nicht offenlegt — wer einen Agenten nach einem „öffentlichen Modell-Download-Link“ fragt, fragt nach etwas, das nicht existiert.

Ein Agent, der den Skills folgt, wird Folgendes verweigern:

  1. auth add oder auth init in deinem Namen ausführen — sie verarbeiten rohe Secrets bzw. die Browser-Anmeldung, also führst du sie lokal aus.
  2. Veröffentlichen, Löschen, Zurückziehen, Deployen, Installieren, Entbinden, Stoppen, Klonen, erneutes Binden ohne eine separate Bestätigungsrunde.
  3. Die Konsole scrapen oder HTTP-Aufrufe mit geratenen Tokens erfinden — nur echte CLI-Befehle.
  4. Öffentliche Modell-Artefakte abrufen oder die Deploy-only-Richtlinie „umgehen“.
  5. Auf L4-Operationen zugreifen (Admin-Prüfzustände, privacy=1).
  6. Vortäuschen, Geräte zu flashen — Web-Serial- / USB-Flashing ist L3: Der Agent darf dir einen Link geben, aber niemals behaupten, dass er geflasht hat.
  7. Befehle erfinden — wenn der CLI eine Funktion fehlt (z. B. Datensatz-Export), sagt der Agent das, statt zu improvisieren.

Das Protokoll steckt in den Skills, daher kennt ein Agent, der sie nicht geladen hat, die Konvention „erst fragen“ nicht — aber das --yes-Tor der CLI schützt dich weiterhin: Unbestätigte Schreibvorgänge schlagen einfach fehl. Für das vollständige Verhalten stelle sicher, dass die Skills eingebunden sind (siehe Skills), und bevorzuge Agenten, die projektlokale Skill-Dateien lesen können.

Wenn ein Agent dich jemals bittet, --yes für eine zerstörerische Aktion auf Produktion „um einen Schritt zu sparen“ selbst einzugeben — das ist der Moment, langsamer zu werden, nicht schneller.