AYVI

Sicherheitsmodell

Sicherer Umgang. Keine falsche Garantie.

Schutzmechanismen reduzieren Risiken, garantieren aber weder korrekte KI-Ausgaben noch identisches Verhalten aller Ziel-Apps.

Schutzmaßnahmen im Code

  • Öffentliche Accessibility-APIs; keine privaten macOS-APIs.
  • Ausgewählte Texte werden in Prompts als nicht vertrauenswürdiger Inhalt markiert. Das ist eine Risikominderung, keine zuverlässige Prompt-Injection-Abwehr.
  • API-Schlüssel liegen im macOS-Schlüsselbund statt in Preferences.
  • Keine stillen Providerwechsel: lokale Beschränkung blockiert Cloud-Provider; Cloud-Anbieter werden vor der ersten Anfrage offengelegt. Apple Foundation Models und Mock sind lokal; Ollama ist nur bei Loopback-Adressen lokal.
  • Bildschirm-OCR ist standardmäßig ausgeschaltet und nur nach Erklärung und ausdrücklicher Auswahl möglich. ScreenCaptureKit erfasst den gezogenen Bereich einmal; AYVI-Fenster werden ausgeschlossen, Vision läuft lokal, das Bild wird verworfen und OCR-Text bleibt schreibgeschützt. Die OS-Berechtigung kann weiter reichen als diese konkrete AYVI-Funktion.
  • Spracheingabe ist standardmäßig aus, fragt Mikrofon- und Speech-Rechte erst nach Aktivierung und Nutzung an, setzt `requiresOnDeviceRecognition` und verwirft nicht unterstützte lokale Erkennung. Audio wird nicht gespeichert; Transkripte werden nicht ohne separate Sendeaktion übertragen.
  • Lens-Marker bleiben default-off, nutzen ausschließlich aktuelle öffentliche AX-Zeilenbounds und werden bei ungültiger Auswahl/fehlender Geometrie nicht gezeigt. Provider-Antworten müssen einem engen JSON-Schema folgen und sind dennoch inhaltlich nicht verlässlich.
  • Der Java-Lernpfad ist default-off und speichert nur geprüfte Konzept-IDs, Status, Zeitstempel und Zähler. Heuristische Erkennung ist begrenzt und ändert den Status nicht automatisch. Der getrennte Prompt-Opt-in zeigt die übermittelten Konzeptnamen vor jeder Cloud-Anfrage.
  • AYVI führt weder KI-generierten noch ausgewählten Code aus. Optionaler Compiler-Check statt Ausführung: Ist „Kompilieren prüfen“ in den Einstellungen aktiviert (Standard: aus), ruft AYVI erst nach deinem Klick javac -proc:none, swiftc -typecheck oder python3 -I -S -m py_compile ohne Shell, mit bereinigter Umgebung, Zeitlimit, Ausgabegrenze und einem eigenen temporären Ordner auf, der danach gelöscht wird. Geprüft werden nur Syntax und Typen; der Code selbst wird nicht ausgeführt. Kompiliert heißt nicht korrekt. Eine echte Ausführung bleibt blockiert, bis es eine unterstützte Isolation gibt. Die Flags beruhen auf Fallen-Experimenten: Annotation-Prozessoren (Java) werden mit -proc:none und leerem Klassenpfad blockiert, Modul-Überschattung (Python, z. B. eine lokale py_compile.py) mit -I -S. sandbox-exec ist deprecated und wird nicht genutzt.
  • Auswahl und vollständige Prompts werden nicht in Diagnoselogs geschrieben. Gespräche einschließlich Auswahltext werden nach einer Erststart-Information standardmäßig lokal gespeichert; Dateirechte begrenzen den Zugriff, und das Archiv ist mit ChaCha20-Poly1305 verschlüsselt; das schützt nicht vor Schadsoftware unter demselben Benutzer bei entsperrtem Mac.
  • Der Dienste-Menü-Eintrag sendet nur (keine Rückgabetypen) und erzeugt eine nur lesbare Auswahl; er kann die andere App nie verändern.
  • Keine Telemetrie- oder Analytics-Integration in der App und Website.

Jede Ersetzung braucht aktuelle Zielprüfung

Vor dem Schreiben prüft AYVI, ob die ursprüngliche Ziel-App und das Accessibility-Element noch passen und ob ausgewählter Text, Fingerprint und vorhandener Bereich unverändert sind. Ein App-Wechsel oder veraltete Auswahl führt zum Abbruch. Ergebnis bleibt kopierbar und erneutes Erfassen kann angeboten werden.

Normale Aktionen zeigen ein sichtbares Diff und warten auf ausdrückliche Bestätigung. Direkt verbessern ist die einzelne Ausnahme, die du durch eine speziell beschriftete Aktion bewusst auslöst; ihre automatische Bestätigung ist per Einstellung abschaltbar. Im ausgeschalteten Zustand bleibt die Diff-Bestätigung nötig. Auch bei Direkt verbessern bleibt die Revalidierung zwingend.

Wenn eine App nicht direkt durch Accessibility geändert werden kann, nutzt AYVI Clipboard nur nach einer separaten sichtbaren Zustimmung. Es vergleicht die Auswahl vor dem Einfügen erneut und versucht, den vorherigen Clipboard-Inhalt wiederherzustellen. Undo für Clipboard prüft die neue Auswahl nochmals. Ist die Prüfung nicht möglich, wird das Schreiben verweigert.

KI-Ausgaben sind Vorschläge

Apple Foundation Models verarbeitet Anfragen lokal und erfordert keine Cloud-Bestätigung, aber die kleinere Systemmodell-Klasse ist möglicherweise weniger leistungsfähig bei komplexem Debugging. Ein Diff zeigt Unterschiede; er beweist nicht, dass der Code korrekt, sicher oder für dein Projekt geeignet ist. Prüfe Auswirkungen, Tests und Annahmen selbst, besonders bei Shell-Befehlen, Datenbankänderungen, Authentifizierung, Verschlüsselung und produktiven Systemen. AYVI führt vorgeschlagene Befehle nicht aus.

Bekannte Grenzen

  • Apps stellen unterschiedliche Accessibility-Daten bereit. Auswahlbereiche oder Editierbarkeit können fehlen; Modelle haben endliche Kontextfenster.
  • Tokenabschätzungen sind Näherungen. Teilverarbeitung kann Beziehungen zwischen Teilen verlieren und verlangt weiterhin Diff-Prüfung.
  • Clipboard-Paste kann sich je nach Ziel-App anders verhalten; deshalb ist reales App-Testen wichtig.
  • Undo ist eine sitzungsbezogene LIFO-Historie im Arbeitsspeicher; ein veralteter Eintrag wird nicht übersprungen. Das ist keine dauerhafte oder appübergreifend garantierte Wiederherstellung.
  • Der lokale Secret Scanner ist heuristisch; es gab keine externe Sicherheitsprüfung.
  • Mock-/Fake-Editor-Tests und kompilierter Code belegen nicht das Verhalten eines echten Editors oder Providers.
  • Der Entwicklungsbuild ist ad-hoc oder lokal signiert, nicht notariell beglaubigt und kein Distributionsrelease. scripts/release.sh (Developer ID, Hardened Runtime, Notarisierung) ist vorbereitet, aber noch nicht ausgeführt.

Den detaillierten Quellcodekontext findest du in SECURITY_MODEL.md (im Repository).