Freigabe & Sicherheitsmodell

Lokale Kontrolle

Das Modell erzeugt ausschließlich strukturierte Vorschläge. Der Pi prüft vor jeder Ausgabe erlaubten Aktionstyp, Felder, Integer-Koordinaten, aktiven Bildbereich, Tastaturprofil, Textlänge, tatsächlich entstehende HID-Kombination, Sitzungsdauer und Aktionszahl. Eine vollständige Call-Liste wird vor ihrer ersten Eingabe vorgeprüft. Unsupported Unicode am Ende eines Texts oder ein ungültiger Drag-Endpunkt dürfen keine teilweise gestartete Eingabe verursachen.

Kein Tool führt generierten Python-/JavaScript-/Shellcode aus. Das schützt die Pi-Ausführungsschicht; es verhindert nicht automatisch, dass sichtbare Zielanwendungen gefährliche Tätigkeiten erlauben. Der Prompt untersagt Konsolen, Scripts und eingebettete Webseitenanweisungen; die lokale Einzelprüfung und der Mensch bleiben die entscheidende Ausgabesperre.

Bedeutung eines Klicks

HID enthält nur Position, Tasten und Text. Ein Klick auf (1250,620) hat keine unabhängige Information darüber, ob dort „Speichern“, „Bezahlen“ oder „Alles löschen“ steht. OCR oder eine zweite Modellbeurteilung können Hinweise liefern, aber keine universelle zuverlässige Geschäftsbedeutung beweisen. Deshalb fordert diese Referenz für sämtliche HID-Aktionen eine einmalige Freigabe; automatisch sind nur wait und screenshot.

Bei Kauf, Versand, unwiderruflichem Löschen und Konto-/Sicherheitsänderung muss der Mensch das sichtbare Ziel und die Konsequenz prüfen. Ein vorgeschlagener Text mit eingebettetem \n enthält auch eine Enter-Eingabe; der Leitstand zeigt den kompletten JSON-Text. Passwörter, MFA und CAPTCHAs werden manuell übernommen. Keine Sammelfreigabe für unbekannte spätere Aktionen.

Dies ist eine konservative beaufsichtigte Implementierung. Der gewünschte völlig autonome Excel-Ablauf ist damit ein Ausbauziel für einen begrenzten getesteten Arbeitsbereich. Das generische Hardwareinterface allein erfüllt nicht gleichzeitig uneingeschränkte Autonomie und sichere semantische Erkennung aller kritischen Aktionen.

Freigabe und Bildzustand

Eine Freigabe enthält kryptografisch zufälligen Einmaltoken, Call-ID, konkrete Aktion, Screenshot-Hash und Ablaufzeit. API-Sicherheitschecks erhalten ihre eigene Freigabe und werden erst danach bestätigt. Vor Nutzerentscheidung wird das Bild neu aufgenommen und für die Anzeige eingefroren. Bei Bestätigung wird der aktuell aufgenommene Screenshot pixelgenau verglichen; vor der eigentlichen Ausgabe nach eventueller Ratenwartezeit wird nochmals verglichen. Ein Stop oder Sessionwechsel macht alte Freigaben ungültig; Futures werden anhand ihrer Identität an genau die ursprüngliche Entscheidung gebunden.

Konservative Einschränkung: Blinkender Cursor, Uhr, Animation oder Kompressions-/Captureflimmern kann bereits den Bildhash verändern. Dann wird die Sitzung beendet und muss neu geplant werden. Die Software behandelt dies nicht als stillschweigend akzeptierte Änderung. Ein stärker nutzbares bildbasiertes Vergleichsverfahren mit zugelassenen dynamischen Bereichen benötigt eine separat geprüfte Policy. Zwischen letzter Aufnahme und USB-Eingabe bleibt dennoch ein physikalisch nicht atomar sperrbarer Zeitraum. Gleichzeitige menschliche Eingaben können Fokus oder Zustand ändern; vor Übernahme stoppen.

Unabhängige Stoppebenen

Die Labor-EVM für den Datenkontakt besitzt keine eigene Wiederanlaufsperre. Beim Entriegeln schließt ihr Datenpfad wieder. Bei Firmware-Hänger Not-Aus halten, Pico-USB abziehen/neustarten und erst danach entriegeln. Die endgültige Box braucht eine unabhängig verriegelte Datensperre mit bewusster lokaler Wiederfreigabe. Verdrahtung und Prüfpunkte stehen in HARDWARE.md.

GP14-ARM benötigt eine frische lokale, entprellte Betätigung und gibt ein einmaliges 10-s-Fenster. Start hält keine Freigabe gespeichert. Nach Stop, USB-Reenumeration, suspend/resume, Watchdog oder Fehler wieder lokal freigeben. GP14 hebt einen Not-Aus-Latch nicht auf. Beim Pico-Boot gehaltene ARM-Taste zählt nicht als neue Flanke.

Übertragung und Wiederholung

UART-Frames sind begrenzt, CRC-geprüft und sequenziert. Genau eine offene Anfrage; Heartbeat teilt dieselbe Zugriffssperre. ACK hat die passende Sequenz und CRC. Nach unbekanntem Ergebnis wird keine Aktion als neuer Request erneut gesendet. Der Pico beantwortet nur die unmittelbar letzte byteidentische Wiederholung aus seinem Cache, ohne erneute Aktion und ohne erneuten Heartbeat. Hostfehler sind bis zum ausdrücklichen Neustart sticky.

Eine abgesagte Python-Coroutine stoppt einen bereits laufenden Serial-Thread nicht. Der Host wartet dessen begrenzten Abschluss ab, bevor er denselben Kanal wieder verwendet; Sessiongenerationen verhindern, dass altes Tippen/Drag nach neuem ARM weiterläuft. STOP bestätigt lokale Sperre und vorgemerkte Nullreports. USB-Trennung kann deren Zustellung verhindern; die OS-Behandlung gehaltener Modifier beim Geräteverlust muss getestet werden. Bereits gesendete Aktionen werden nicht zurückgenommen.

Grenzen und Sicherheitsregeln

Voreinstellungen: 10 Minuten, 150 Aktionen, 40 API-Aufrufe, 200.000 gemeldete Tokens, höchstens vier neue Agentenaktionen pro Sekunde, 250 Zeichen pro Type-Aktion, Freigabeablauf nach 60 s. Eine Textaktion besteht aus mehreren HID-Reports; das Rate-Limit zählt Agentenaktionen, nicht einzelne Buchstaben. Einzelne Tasten halten nur kurz; finally plant Release auch beim Abbruch.

Feste Sperren umfassen Ctrl+Alt+Delete, GUI+L/R/X, Ctrl+Alt+F1…F6, Ctrl+Shift+Escape und Alt+F4. Sie werden aus den physischen HID-Modifierbits/Usages beurteilt; LEFT_CTRL, RALT, GUI und andere Schreibweisen können sie nicht umgehen. Diese Kürzel sind eine bewusst begrenzte Basissperre, keine Liste aller gefährlichen Handlungen.

extra_denied_keypresses ergänzt Sperren. Sie gelten auch für Reports aus type, beispielsweise [["ENTER"]] gegen eingebettete Zeilenumbrüche. allowed_keypresses beschränkt optional ausdrücklich angeforderte keypress-Kombinationen; normale Texteingabe besitzt ein eigenes Profil und ist weiterhin freigabepflichtig. Die Whitelist kann feste Sperren nicht überschreiben. Beispiel:

extra_denied_keypresses = [["CTRL", "P"], ["ALT", "TAB"]]
allowed_keypresses = [["CTRL", "C"], ["CTRL", "V"], ["ENTER"], ["ESC"]]

Regeländerungen im Leitstand werden gespeichert, benötigen Dienstneustart und löschen die Kalibrierungsfreigabe. Keine UI-Option deaktiviert die Einzelbestätigung oder den physischen ARM-Mechanismus.

Betrieb, Datenschutz und Logs

Webdienst nur auf 127.0.0.1, langer Bearer-Token, gleicher Origin/Host, keine fremden JS-/CSS-Ressourcen, keine Frames. Der Browser hält den Token nur im RAM; Screenshots und Logs sind authentifiziert und nicht gecacht. Ein gestohlener Token ermöglicht lokale Operatorfunktionen, daher Zugang zum Pi/Tunnel schützen. Der API-Key liegt nur als Umgebungsvariable auf dem Pi. Kein Zielkonto wird in der Box hinterlegt.

Audit schreibt die Eingabeabsicht mit fsync vor HID und danach das ACK. Schreibfehler verhindern weitere Eingaben. PNGs und volle API-Responses sind standardmäßig aus; eingegebene Texte und Aufträge werden trotzdem protokolliert. Hashkette ermöglicht Integritätsprüfung, garantiert ohne externen Anker keinen Schutz gegen einen Administrator, der alles neu schreibt. Dateimodus 0600 und Sitzungsordner 0700; Verzeichnisse und Aufbewahrungsdauer lokal verwalten.

store:false ist keine Zusage vollständiger Nichtaufbewahrung beim API-Anbieter. Passwörter, private Kundendaten und Kontoinhalte können im sichtbaren HDMI-Bild stehen. allow_screenshot_upload muss deshalb bewusst lokal freigegeben werden. OpenAI Datenkontrollen

Technische Ausschlüsse

Keine HDCP-Umgehung, kein garantierter Zugang zu nicht sichtbaren Monitoren, kein blindes relatives Positionsfallback, keine unbekannte Unicode-/Layoutkonvertierung, keine BIOS-/Secure-Desktop-Garantie. Der HDMI-Capturepfad kann ein eingefrorenes Quellbild mit weiterlaufenden UVC-Timestamps liefern; reine Framefrische erkennt das nicht. Native HDMI-Auflösungs-/Topologieänderungen können bei konstant skaliertem Capture unsichtbar bleiben. Operator muss solche Änderungen stoppen und neu kalibrieren; Hersteller-Signalstatus/EDID-Überwachung ist ein Ausbau.

Ein kopierter Target-Dateiname, ein richtiges USB-ACK oder die Modellantwort „erledigt“ bestätigt keinen gespeicherten Dateizustand. Ergebnisprüfung bleibt Teil der Abnahme. Die Box und Laborschaltung sind keine zertifizierte Sicherheitssteuerung.