Sandbox-Richtlinie, Gast-Sandbox und Kernel-Sentry

Jede Maschine läuft bereits hinter der Übertragungsgrenze: Der Agent hält immer nur Ersatz-Zugangsdaten, und alles, was er sendet, geht über Bromures Proxy und virtuellen Switch auf dem Mac (siehe Zugangsdaten & die Übertragungsgrenze). Die Sandbox-Richtlinie entscheidet, was eine Maschine sonst noch darf — wohin ihre VM sich verbinden darf und, wenn Sie wollen, was ihre Agenten in der VM anfassen dürfen. Eine Maschine (ein Arbeitsbereich, im Einstellungseditor) wählt in Einstellungen › Sandbox-Richtlinie eine von zwei Sandbox-Engines:

	Bromure Firewall	OpenShell + Sentry
Was Sie schreiben	Eine geordnete Tabelle aus Erlauben- und Verweigern-Regeln (pf-Stil), mit optionalem Standard-Verweigern	Eine Sandbox-Policy von NVIDIA OpenShell (YAML, Schema v1)
Voreinstellung für nicht zugeordneten Verkehr	Erlauben (oder Verweigern)	Verweigern
Prüfung von Anfragen	HTTP-Methoden je Host (`web`-Regeln)	REST, WebSocket, GraphQL, MCP und JSON-RPC, Anfrage für Anfrage, in `enforce` oder `audit`
In der VM	Nichts	Die Gast-Sandbox (Dateisystem, Prozesse, Binaries), der Kernel-Sentry, Pakete ohne root
Freigabe bekommen	Zeitlich begrenzte Regeln, Schnellaktionen der Sicherheits-Zeitleiste, die Sandbox-Schublade	Die Sandbox-Schublade, der Policy-Berater unter `http://policy.local`
Am besten für	Das Netz einer Maschine einengen, ohne zu ändern, wie sie arbeitet	Eine Maschine, die Sie von Anfang bis Ende eingeschränkt, beobachtet und prüfbar haben wollen

Neue Maschinen starten mit der Bromure-Firewall. Beide Engines werden auf dem Mac durchgesetzt, wo der Agent nicht hinkommt, und jede Entscheidung ist eine Zeile in der Sicherheits-Zeitleiste.

Fünf Schutzfunktionen wirken unter beiden Engines und stehen unter Schutzmechanismen › Schutzfunktionen:

den Agenten informieren, wenn die Richtlinie ihn blockiert;
der Agenten-Watchdog;
der strenge Zugangsdaten-Modus;
das transparente Abfangen;
die unsichere Umgehung je Anfrage.

Die Bromure-Firewall

Die Firewall ist eine Liste von Regeln über jede Verbindung, die die VM öffnet: Host, IP/CIDR, Protokoll, Port und bei Webverkehr die HTTP-Methode. Die Regeln werden von oben nach unten geprüft, die erste Übereinstimmung gewinnt, und Regeln lassen sich ausschalten oder für begrenzte Zeit einschalten. Geprüft wird am virtuellen Switch (nach Zieladresse und nach dem Namen, den die VM nachgeschlagen hat) und noch einmal im Proxy (nach TLS-Servername und bei web-Regeln nach Methode). Die Ports 80 und 443 der VM werden in den Proxy umgeleitet, sodass sich drinnen nichts entziehen kann. Regelsyntax und Editor sind unter Sandbox-Richtlinie › Bromure-Firewall beschrieben.

OpenShell-Policies

NVIDIA OpenShell ist ein offenes Format, um KI-Agenten in eine Sandbox zu stecken: eine einzige YAML-Policy, die sagt, welche Endpunkte ein Agent erreichen darf, wie seine Anfragen geprüft werden, welche Dateien er anfassen darf und welche Programme das dürfen. Bromure führt OpenShell-Policies nativ aus. Sie können eine für OpenShell geschriebene Policy mitbringen oder von der Start-Policy von Bromure ausgehen und bekommen dieselben Entscheidungen. Bromures Auswerter wurde über mehr als 125.000 differenzielle Fälle gegen den von OpenShell geprüft, ohne eine einzige Abweichung.

Wählen Sie in den Einstellungen einer Maschine OpenShell + Sentry, wird die Standard-Policy Ihrer Organisation oder die Start-Policy geladen (GitHub, npm und PyPI nur lesend, die Paketspiegel von Ubuntu) und der Kernel-Sentry eingeschaltet. Von da an gilt: Alles ist verweigert, solange keine Regel in network_policies es erlaubt.

Wo die Policy durchgesetzt wird

Wo	Was sie entscheidet
Der virtuelle Switch	Jede Verbindung nach Adresse und Port (alle Protokolle) und — mit Enforce binaries — nach dem Programm, das sie geöffnet hat.
TLS-Servername / HTTP-`Host`	Zu welchem Endpunkt eine Verbindung gehört, auch bei Verbindungen, die die Proxy-Einstellungen umgehen.
Der Proxy	Verbindungen über `HTTPS_PROXY`.
Jede Anfrage	Ein Endpunkt mit `protocol` (`rest`, `websocket`, `graphql`, `mcp`, `json-rpc`) wird Anfrage für Anfrage geprüft: Methoden und Pfade (`access: read-only`, `read-write`, `full`, oder ausdrückliche Regeln und `deny_rules`), Query-Parameter, GraphQL-Operationen, MCP-Tools und JSON-RPC-Methoden. `enforcement: enforce` blockiert; `audit` zeichnet auf und lässt durch.

Manche Ziele werden verweigert, egal was die Policy sagt:

Loopback-, Link-Local- und Cloud-Metadaten-Adressen;
Ports der Kubernetes-Control-Plane (2379, 2380, 6443, 10250, 10255).

Private Bereiche (10/8, 172.16/12, 192.168/16, 100.64/10) sind nur über einen exakten Hostnamen oder allowed_ips erreichbar. Netzwerkregeln gelten sofort für eine laufende Maschine. Die Einstellungen für Dateisystem, Prozesse und Sentry wirken ab dem nächsten VM-Start.

Eine verweigerte Anfrage bekommt HTTP 403 mit dem OpenShell-eigenen Body policy_denied, sodass Werkzeuge und Agenten, die OpenShell verstehen, genauso reagieren.

Regeln, die Bromure automatisch hinzufügt

Eine Maschine muss weiterhin die Modellanbieter ihrer Agenten erreichen, die Hosts, für die ihre Zugangsdaten bestimmt sind, ihre Kubernetes-Cluster, AWS und ihre lokalen Modelle. Wie die Anbieterregeln von OpenShell fügt Bromure dafür _provider_…-Regeln hinzu. Sie stehen unter Rules Bromure adds automatically in der Karte Governance und fehlen in einer exportierten Policy.

Zugangsdaten unter OpenShell

Bromures Schutz der Zugangsdaten bleibt unverändert: Die VM hält Ersatzwerte, und der echte Wert wird auf der Leitung eingesetzt, nur für die eigenen Hosts der Zugangsdaten. Zwei Ergänzungen im Bereich Zugangsdaten einer OpenShell-Maschine:

OpenShell-Anbieterprofile — importieren Sie ein Profil (openshell profile export), tippen Sie seine Werte ein, und jeder wird zu Zugangsdaten der Maschine, gebunden an die Hosts und Pfade des Profils, wobei die Endpunkte des Profils als Regel hinzugefügt werden.
Use OpenShell credential placeholders — der Agent sieht openshell:resolve:env:NAME statt Bromures echt aussehender Tokens, wie er es unter OpenShell täte.

Die eigenen Zugangsdaten-Felder der Policy (credential_binding, credential_signing und ähnliche) werden mit einer Warnung ignoriert: Bromure bindet alle Zugangsdaten an ihre Hosts und signiert AWS-Anfragen selbst.

Unterschiede zu OpenShell

Bromure folgt der Semantik von OpenShell, mit ein paar bewussten Unterschieden:

Keine filesystem_policy, keine Dateisystem-Sandbox. Eine Policy ohne diesen Abschnitt lässt die Dateien der VM uneingeschränkt; OpenShell würde den Agenten auf seinen Arbeitsordner beschränken.
binaries braucht Enforce binaries. Ohne das ist binaries nur ein Hinweis, und der Editor warnt davor: Der Agent hat root in der VM, also ist der Identität eines Prozesses nicht zu trauen.
Middlewares. Nur die eingebaute Middleware openshell/regex im Modus redact läuft. Eine externe Middleware wird je nach ihrem fail_open / fail_closed durchgereicht oder blockiert.
Anbieterprofile. Zugangsdaten, die sich per refresh erneuern oder einen token_grant nutzen, werden als statische Werte verwendet.
Seccomp. Der Filter ist so angepasst, dass Job Control in den Terminals der VM funktioniert.

Die Gast-Sandbox

Die Netzwerk-Policy begrenzt, wohin die VM sich verbinden kann. Die Gast-Sandbox begrenzt, was die Agenten darin tun können. Sie kommt aus drei Teilen der Policy:

Abschnitt der Policy	Was Bromure anwendet
`filesystem_policy` (+ `landlock`)	Der Agent kann nur die Pfade lesen und schreiben, die die Policy auflistet, durchgesetzt mit Linux Landlock — nicht einmal root in der VM kann es aufheben. `landlock.compatibility: best_effort` weicht aus, wenn ein Pfad nicht nutzbar ist; `hard_requirement` schlägt geschlossen fehl.
`process` (`run_as_user`, `run_as_group`)	Der Agent läuft unter diesem Konto, ohne sudo oder Docker. Er sieht weiterhin `/home/ubuntu` als sein Home, seine Konfiguration gilt also.
Enforce binaries (die strenge Sandbox)	Jede Verbindung wird von einem root gehörenden Attestor in der VM dem Programm zugeordnet, das sie aufgebaut hat, und die `binaries` einer Regel müssen es nennen. Der Hash jedes Programms wird beim ersten Gebrauch festgehalten, und ein verändertes Binary wird abgewiesen. Damit diese Meldung vertrauenswürdig ist, verliert der Agent jeden Weg zu root: kein sudo, kein Docker, und aller Verkehr geht durch das transparente Abfangen.

Jeder Teil gilt nur, wenn er vorhanden ist. Eine Policy ohne Abschnitt filesystem_policy oder process schränkt in der VM nichts ein. Ein Abschnitt process schaltet Enforce binaries von selbst ein.

Konfiguration	Was Sie bekommen
Nur Netzwerk-Policy	Das Netz ist eingeschränkt, die VM nicht.
`filesystem_policy`, Binaries nicht erzwungen	Die Dateien sind eingeschränkt, sogar gegenüber root. sudo funktioniert noch, also könnte der Agent Bromures Helfer in der VM stoppen — die Karte Sandbox warnt davor.
Enforce binaries, oder ein Abschnitt `process`	Dateien, Systemaufrufe und Rechte sind eingeschränkt. Der Agent kann weder root werden noch Bromures Prozesse stören.

Bromure fügt die wenigen Pfade hinzu, die seine eigene Infrastruktur braucht, nur lesend, sofern nicht geschrieben werden muss, und listet sie auf der Karte Sandbox (Added for Bromure: …):

die Terminal-Sockets;
die Meta-Freigabe;
/proc;
die DNS-Konfiguration;
die Installationsordner von Agenten außerhalb von /usr (Grok in /opt/grok, die Laufzeit von Oh My Pi in /opt/bun).

Sie werden nie in Ihre eigenen Listen eingemischt.

Im Zweifel geschlossen

Die Sandbox fällt nie stillschweigend auf einen uneingeschränkten Betrieb zurück:

Wird die strenge Sandbox nicht vollständig angewendet, startet keine Sitzung, Binary-Regeln verweigern alles, und die Karte Sandbox sagt es in Rot. Ein Neustart der VM versucht es erneut.
Befehle, die Bromure für Sie in der Maschine ausführt — Terminals, vm exec, Dateioperationen, git, der Planer — warten, bis die Sandbox steht (90 Sekunden bei einem einfachen Befehl). Steht sie nicht, scheitert der Befehl mit sandbox unavailable: ….
Bromures eigene git-Aufrufe in der Maschine laufen immer eingeschränkt, denn ein Repository kann git auf ein Programm seiner Wahl zeigen lassen.

Pakete ohne root

Ein eingeschränkter Agent hat kein root, systemweite Installationen können also nicht funktionieren. Zwei Schalter auf der Karte Sandbox, beide standardmäßig an, halten Installationen am Laufen:

Packages in the home folder — pip install landet in ~/.local (npm installiert global bereits nach ~/.npm-global). Bromures eigene Prozesse in der VM ignorieren Pakete im Home-Ordner, sodass der Agent ihnen keinen Code unterschieben kann.
System packages on request — führt der Agent apt-get install aus (mit oder ohne sudo), wartet die Anfrage auf Sie, statt zu scheitern. Der Agent sieht:
```
bromure: this sandbox has no root. Asked the user to approve installing: libpq-dev
bromure: waiting for their decision (Sandbox drawer › Proposals)…
```
Öffnen Sie den Tab Proposals der Sandbox-Schublade und wählen Sie Install oder Reject. Genehmigte Pakete installiert der root-Supervisor der VM aus den Ubuntu-Spiegeln, nur nach exaktem Namen: keine Optionen, Dateipfade, .deb-Dateien oder Namen, die apt als Muster oder Entfernung lesen würde. Eine abgelehnte Anfrage sagt dem Agenten, es nicht erneut zu versuchen. Jede Anfrage und ihr Ausgang ist eine Zeile Guest sandbox in der Sicherheits-Zeitleiste.

Der Kernel-Sentry

Der Kernel-Sentry ist ein kleines Linux-Kernelmodul, das aus dem Kernel der VM heraus meldet, was dort geschieht. Er meldet an den Mac über einen privaten Kanal, den der Agent nicht durch das Beenden eines Prozesses zum Schweigen bringen kann:

Programmstarts;
Verbindungen, mit der Prozesskette hinter jeder einzelnen;
Rechteänderungen;
Modul- und BPF-Ladevorgänge;
alles, was die Gast-Sandbox verweigert hat.

Sobald er gestartet ist, wird der Kernel gesperrt, sodass nicht einmal root in der VM Code laden kann, um einzugreifen.

Der Sentry macht Folgendes möglich:

Netzwerk-Abstammung — welcher Prompt, welcher Tool-Aufruf und welcher Prozess jede Verbindung aufgebaut hat.
Sandbox-Verweigerungen in der Zeitleiste und im Tab Files der Sandbox-Schublade.
Manipulationserkennung — eine Lücke im nummerierten Strom des Sentry, eine entschärfte Sonde, eine gefälschte Neuverbindung, das Laden eines unsignierten Moduls oder ein herabgesetzter Lockdown wird in Rot als tampering suspected markiert und speist den Agenten-Watchdog.
Die Identität der Binaries für Enforce binaries.

Er hat zwei Modi, auf der Karte Kernel sentry:

Modus	Beim Booten	Wenn der Sentry nicht laden kann
Best effort	Der Sentry lädt im Hintergrund; Sitzungen warten nicht auf ihn.	Die Maschine läuft ohne ihn, und die Karte sagt, warum.
Required	In der VM läuft nichts, bis der Sentry feststeht. Der Kernel wird weiter gesperrt, was auch Kernel-Tracing-Werkzeuge wie `bpftrace` und `perf` ausschließt.	Erklärt die VM, warum (etwa weil kein Modul für ihren Kernel existiert), startet die Maschine ohne ihn, mit einer Warnung. Ein Sentry, der sich ohne Erklärung nie verbindet, wird als Manipulation behandelt.

Ihre Organisation kann einen Mindestmodus vorschreiben. Die Maschine läuft dann mit dem strengeren von beiden.

Module auf Abruf

Ein Kernelmodul lädt nur in genau den Kernel, für den es gebaut wurde, und eine Maschine kann per apt upgrade jederzeit auf einen neuen Ubuntu-Kernel wechseln. Deshalb liegen die Module nicht in der App. Bromure baut sie jeden Tag für jeden Ubuntu-Kernel und veröffentlicht sie unter dl.bromure.io. Der Katalog und jedes Modul sind signiert, und Bromure prüft die Signatur, die Prüfsumme und dass der Katalog nicht älter ist als einer, den es schon hat.

Beim Start holt Bromure die Module für die Kernel, von denen bekannt ist, dass Ihre Maschinen sie benutzen, und stellt sie vor jedem Booten bereit.
Bootet eine VM einen Kernel, den Bromure noch nicht gesehen hat, fragt die VM nach, und Bromure holt das Modul und übergibt es binnen Sekunden.
Gibt es für diesen Kernel noch kein Modul, erfährt die VM das sofort, und die Karte zeigt Couldn't start: no module published for Kernel yet. Versuchen Sie es einen Tag später erneut, oder booten Sie den vorherigen Kernel.

Heruntergeladene Module werden in ~/Library/Application Support/BromureAC/sentry-modules/ aufbewahrt.

Die Sandbox-Schublade

Das Fenster jeder Maschine hat in seiner Symbolleiste eine Schild-Schaltfläche („Sandbox: what it blocked, ready to allow"). Sie öffnet die Sandbox-Schublade über der Bühne. Sie können auch ⌃⌘N drücken oder Darstellung › Toggle Sandbox Drawer wählen. Ein rotes Abzeichen auf der Schaltfläche zählt die Ziele, die seit Ihrem letzten Blick blockiert wurden. Die Schublade zeigt, was die Sandbox der Maschine in den letzten zwei Stunden verweigert hat, bereit zum Erlauben:

Tab	Engine	Was darin steht
Network (Blocked unter der Firewall)	Beide	Jedes blockierte Ziel, mit dem Programm, das es versucht hat (wenn bekannt), wie oft und wann. Allow fügt eine Regel für diesen Host und Port hinzu. Unter der Firewall bietet es Immer, 15 Minuten lang, 1 Stunde lang oder Bis der Workspace stoppt. Unter OpenShell mit Enforce binaries nennt die Regel das Programm, das es versucht hat.
Files	OpenShell, mit einer `filesystem_policy`	Was die Dateisystem-Sandbox verweigert hat, nach Ordner gruppiert, mit Operation und Datei. Allow fügt den Ordner nur lesend hinzu, oder mit Read and write, oder nur diese eine Datei. Der Dateizugriff ändert sich beim nächsten Start: Eine Karte Neu starten erscheint.
Proposals	OpenShell	Paketanfragen (Install / Reject) und Regeln, für die der Policy-Berater auf Ihre Entscheidung wartet (Approve / Reject).
Temporary	Firewall	Regeln, die für begrenzte Zeit an sind, mit ihrem Ende, und End.

Regeln, die Sie aus der Schublade hinzufügen, werden in der Maschine gesichert und gelten sofort. Sie werden wie jede andere Bearbeitung gegen Ihre Organisationsgrenze geprüft. Sandbox Policy… unten öffnet die Einstellungen der Maschine.

Der Policy-Berater

Ein Agent, der an eine Wand stößt, weiß meist genau, was er gebraucht hätte. Unter OpenShell kann er darum bitten: Wird eine Anfrage blockiert, kann der Agent bei http://policy.local, der Berater-API von OpenShell, die engste Regel vorschlagen, die sie erlauben würde, und auf Ihre Entscheidung warten. Das 403, das er bekommen hat, erklärt ihm, wie. Wie viel er darf, wählen Sie unter Sandbox-Richtlinie › Policy advisor › Agent proposals:

Modus	Was geschieht
Off (Voreinstellung)	Der Agent kann keine Regeln vorschlagen. Blockierte Verbindungen werden weiterhin als Vorschläge für Sie entworfen.
Ask me	Jeder Vorschlag wartet in der Sandbox-Schublade und auf der Karte Policy advisor, bis Sie ihn genehmigen (Approve) oder ablehnen (Reject). Der Grund einer Ablehnung geht an den Agenten zurück.
Approve if risk-free	Ein Vorschlag ohne Risikobefund wird sofort genehmigt. Ein Vorschlag, der einen Host erreicht, für den die Maschine Zugangsdaten hat, dort eine Methode hinzufügt oder einen Platzhalter, eine private Adresse, einen Datenbank-Port oder einen hohen Port benutzt, wartet immer auf Sie. Ebenso einer, der die Grenze Ihrer Organisation überschreiten würde.

Agenten dürfen nur rest- oder websocket-Regeln vorschlagen, und nie tls: skip. Eine genehmigte Regel wird der Policy hinzugefügt, gilt sofort und bleibt im Revisionsverlauf der Policy erhalten. Jeder Vorschlag und jede Entscheidung ist eine Zeile Firewall in der Sicherheits-Zeitleiste.

Den Agenten informieren: Policy-Steuerung

Ein Agent, der nur „connection refused" oder „permission denied" sieht, versucht es gern erneut und sucht dann einen anderen Weg. Von außen sieht das aus wie ein Agent, der aus dem Ruder läuft. Mit Tell the agent when policy blocks it (unter Schutzmechanismen › Schutzfunktionen, für OpenShell-Maschinen standardmäßig an) erfährt der Agent in seiner Unterhaltung, was blockiert wurde und warum, zum Beispiel:

[Bromure policy] This workspace's network policy blocked connecting to api.stripe.com:443 — no network policy allows api.stripe.com:443. … This is a deliberate restriction, not a fault: don't retry it or reach the same thing another way … If your task needs it, stop and tell the user what you need and why so they can decide.

Claude Code bekommt den Hinweis direkt nach dem Befehl, der auf die Blockade gestoßen ist, mitten im Zug.
Codex, Grok, Kimi und Oh My Pi bekommen ihn eingetippt, sobald ihr Zug vorbei ist.
Der Hinweis geht an den Agenten, dessen Prozess die blockierte Verbindung oder den Dateizugriff ausgelöst hat, anhand der Prozessketten des Kernel-Sentry.
Kann Bromure nicht erkennen, welcher Agent es war, geht eine Netzwerkblockade an alle Agenten der Maschine und eine Dateiblockade nur an einen einzigen Agenten.
Dieselbe Blockade wird nur einmal alle fünf Minuten gemeldet, und ein Agent bekommt höchstens fünf Hinweise pro Minute. Der eigene Hintergrundverkehr eines Agenten und gängige Telemetrie-Hosts werden nie gemeldet.

Werte im Hinweis, die aus der VM stammen (ein Host, ein Pfad), werden als Daten zitiert, sodass ein Programm eine Blockade nicht nutzen kann, um dem Agenten Worte in den Mund zu legen.

Der Agenten-Watchdog

Der Watchdog betrachtet eine Sitzung als Ganzes, von außerhalb der VM:

Häufungen von Blockaden;
Zugangsdaten, die nicht dazugehören;
Anzeichen von Manipulation am Sentry;
eine gescheiterte Sandbox;
Prompt-Injection;
neue Ziele, nachdem sich die Sitzung eingependelt hat;
ausgehendes Volumen weit über dem Grundniveau.

Über einer Schwelle innerhalb einer Minute zeichnet er einen Befund auf (Alert), oder er kappt das Netz der VM, pausiert sie und fragt Sie, was zu tun ist (Quarantine). Siehe Schutzmechanismen › Agenten-Watchdog. Er ist standardmäßig aus; ohne ihn werden Manipulationsalarme weiterhin in der Sicherheits-Zeitleiste und in OCSF-Logs aufgezeichnet.

Die Organisationsgrenze

Eine Organisation kann eine Grenze setzen: das Höchste, was die OpenShell-Policy irgendeiner Maschine erlauben darf. Sie kommt auf einem registrierten Mac von bromure.io (alle zehn Minuten aktualisiert und für den Offline-Betrieb zwischengespeichert) oder aus einer Datei auf diesem Mac (Sandbox-Richtlinie › Governance › Organization boundary). Jedes Sichern, das eine Policy ändert, wird gegen sie geprüft, ob aus den Einstellungen, der Sandbox-Schublade, dem Policy-Berater oder der API. Bromure benutzt NVIDIAs openshell-prover, wenn er installiert ist, sonst seine eigene Prüfung.

Im Editor erscheint beim Tippen ein grünes oder rotes Urteil („within boundary", oder „exceeds boundary: …" mit einem Beispiel dessen, was sie erlauben würde), und Sichern wartet, bis die Policy passt.
An anderer Stelle wird ein Sichern außerhalb der Grenze mit „outside the organization boundary — …" abgewiesen.
Eine früher gesicherte Policy, die nicht mehr passt, schlägt geschlossen fehl: Nur die Regeln, die Bromure selbst hinzufügt, bleiben erreichbar.

Über denselben Kanal kann eine Organisation außerdem:

die Standard-Policy für neue OpenShell-Maschinen festlegen;
Enforce binaries oder strenge Zugangsdaten vorschreiben;
einen Mindestmodus für den Kernel-Sentry festlegen;
den Modus des Policy-Beraters deckeln;
verlangen, dass die Überlegungen der Agenten mit der Netzwerk-Abstammung hochgeladen werden.

Siehe Enterprise.

Jedes Sichern, das eine Policy ändert, wird außerdem in ihrem Revision history aufbewahrt, mit der Herkunft der Änderung; Wiederherstellen holt jede Version zurück.