# Agent NAS: vollständige Dokumentation > Agent NAS ist Netzwerkspeicher, der um die Ausführung (Run) herum gebaut ist: Jede Ausführung eines Agenten arbeitet in einem isolierten Branch und greift über eine kurzlebige, enge Lease auf Daten zu; jede Änderung lässt sich nachverfolgen und rückgängig machen; und das Gedächtnis sind gewöhnliche Dateien mit Provenienz. Bedient wird es über das, was Agenten ohnehin sprechen: Dateien, Git, S3 und MCP. Stand: Konzept und Spezifikationsentwurf v0.2, November 2026. Noch keine Referenzimplementierung. Inhalte unter CC BY 4.0 lizenziert. --- # Agent NAS: Netzwerkspeicher für KI-Agenten > Agent NAS ist Netzwerkspeicher, der um die Ausführung (Run) herum gebaut ist: Jede Ausführung eines Agenten arbeitet in einem isolierten Branch und greift über eine kurzlebige, enge Lease auf Daten zu; jede Änderung lässt sich nachverfolgen und rückgängig machen; und das Gedächtnis sind gewöhnliche Dateien mit Provenienz. Bedient wird es über das, was Agenten ohnehin sprechen: Dateien, Git, S3 und MCP. **Wo Agenten arbeiten und Sie die Kontrolle behalten.** Ein NAS, das die Ausführung zur Grundeinheit macht: Jede Ausführung bekommt einen eigenen Branch und eine eigene Lease, jede Änderung lässt sich nachverfolgen und rückgängig machen, und das Gedächtnis sind Notizen, die Sie lesen, bearbeiten und mitnehmen können. ## Auf einen Blick - **Kategorie**: Netzwerkspeicher für KI-Agenten, auch agentennativer Speicher (agent-native storage) genannt. - **Kernidee**: Die Einheit des Zugriffs ist die **Ausführung** (Run), nicht das Konto: Eine Ausführung arbeitet auf einem Branch, greift über eine Lease auf Daten zu und hinterlässt einen Eintrag im Protokoll. - **Vier Versprechen**: Begrenzt, wiederherstellbar, zurechenbar und einsehbar. - **Kernbegriffe**: Tree, Commit, Principal, Run, Lease und Record. - **Konzepte**: Neun benannte Konzepte in drei Gruppen: Arbeit, Befugnis und Wissen. - **Schnittstellen**: Datenebene: Mount, Git, S3, WebDAV. Steuerungsebene: MCP, HTTP, CLI. - **Spezifikation**: Entwurf v0.2 mit Konformitätsstufen von L0 Files bis L4 Sync, jede mit ausführbaren Abnahmetests. - **Stand**: Konzept- und Spezifikationsphase, noch keine Referenzimplementierung. L0 und L1 lassen sich schon heute aus vorhandenen Bausteinen bauen. - **Lizenz**: Inhalte unter CC BY 4.0. ## Warum jetzt Vier Dinge sind im vergangenen Jahr bereits passiert. - **Agenten arbeiten in Dateien.** [AGENTS.md](https://agents.md), [Agent Skills](https://agentskills.io/specification), Git-basiertes Gedächtnis ([Letta Context Repositories](https://www.letta.com/blog/context-repositories/)) und [dynamische Kontextentdeckung](https://cursor.com/blog/dynamic-context-discovery), die lange Ausgaben in Dateien schreibt, haben Dateien zum Arbeitsmedium von Agenten gemacht. - **Fehler sind schnell und teuer.** Im April 2026 nutzte ein Coding-Agent ein zu weit gefasstes Token aus einer unbeteiligten Datei und [löschte in 9 Sekunden die Produktionsdatenbank eines Unternehmens samt der Backups auf demselben Volume](https://www.theregister.com/software/2026/04/27/cursor-opus-agent-snuffs-out-startups-production-database/5224442). - **Menschen können nicht jeden Schritt prüfen.** Anthropic berichtet, dass Nutzer [93 % bis 97 % der Berechtigungsabfragen](https://claude.com/resources/articles/auto-mode-default-in-claude-code) freigeben; in seinem kontrollierten Experiment erkannten Menschen nur 13,6 % der eingeschleusten gefährlichen Befehle. - **Gedächtnis ist zur Angriffsfläche geworden.** [Mehrere Studien aus 2026](https://arxiv.org/abs/2606.04329) zeigen, dass eine bösartige Anweisung im persistenten Gedächtnis über Sitzungen hinweg überlebt und dass Verteidigung allein bei Eingabe oder Abruf wenig hilft. Auch Speicherhersteller haben sich bewegt: [QNAP QuAgent](https://www.qnap.com/en/software/quagent), [Synology DSM Agent](https://www.synology.com/en-us/beta/2026_DSM_Agent_1_0_Beta/release_note) und [TrueNAS MCP](https://truenas.github.io/truenas-research-labs/) lassen alle einen Agenten die Box verwalten. Soweit wir sehen, gibt es aber weiterhin keinen selbst gehosteten, offenen, überprüfbaren Vertrag dafür, wie andere Agenten sicher mit den Daten darin arbeiten. Siehe [Agent NAS im Vergleich zu bestehenden Ansätzen](https://agentnas.com/de/compare/). ## Vier Versprechen | Versprechen | Bedeutung | Geliefert von | | --- | --- | --- | | Begrenzt | Eine Ausführung kann nur anfassen, was ihre Lease benennt, und die Lease hört pünktlich auf zu wirken; eine Sitzung, die nicht vertrauenswürdige Inhalte gelesen hat, kann nicht zugleich sensible Daten und einen ausgehenden Kanal halten. | [Capability Lease](https://agentnas.com/de/concepts/capability-lease/), [Trust Labels](https://agentnas.com/de/concepts/trust-labels/) | | Wiederherstellbar | Schreibzugriffe landen zuerst auf einem Branch; geschützte Daten ändern sich nur durch geprüfte Merges; Löschen ist ein Soft Delete; Snapshots liegen außerhalb jeder Lease. | [Agent Branch](https://agentnas.com/de/concepts/agent-branch/), [Human Gate](https://agentnas.com/de/concepts/human-gate/) | | Zurechenbar | Jede Änderung kann beantworten: wer sie vorgenommen hat, in wessen Auftrag, unter welcher Lease und was gelesen wurde. | [Flight Recorder](https://agentnas.com/de/concepts/flight-recorder/) | | Einsehbar | Gedächtnis sind gewöhnliche Notizen mit Provenienz, Indizes lassen sich verwerfen und neu aufbauen, und alle Daten lassen sich exportieren. | [Agent Home](https://agentnas.com/de/concepts/agent-home/), [Agent Memory](https://agentnas.com/de/concepts/agent-memory/), [Budgeted Reads](https://agentnas.com/de/concepts/budgeted-reads/), [Cascade Forget](https://agentnas.com/de/concepts/cascade-forget/) | ## Neun Konzepte, drei Fragen Agent NAS schlägt neun benannte Konzepte vor. Jedes hat eine eigene Seite: eine zitierbare Definition, einen Mechanismus, einen Weg, klein anzufangen, eine Schnittstellenskizze, was die Spezifikation verlangt, und ehrliche Grenzen. ### Arbeit Wo findet die Arbeit statt, und was ist passiert? - AN-01 [Agent Home (Home-Verzeichnis)](https://agentnas.com/de/concepts/agent-home/): Ein Verzeichnis pro Rolle, mit Verlauf. Gewöhnliche Dateien, die Sie mitnehmen können. - AN-02 [Agent Branch (Agentenzweig)](https://agentnas.com/de/concepts/agent-branch/): Jede Ausführung arbeitet auf einem Copy-on-Write-Branch. Nur ein geprüfter Merge erreicht die Hauptlinie. - AN-03 [Flight Recorder (Flugschreiber)](https://agentnas.com/de/concepts/flight-recorder/): Ein Protokoll pro Ausführung, per Hash verkettet, das auch festhält, was gelesen wurde. ### Befugnis Wer darf was, und auf wessen Anweisung? - AN-04 [Capability Lease (befristete Berechtigung)](https://agentnas.com/de/concepts/capability-lease/): Eine enge Autorisierung für eine Ausführung, mit Ablauf und Budgets. Kind-Leases können nur enger sein. - AN-05 [Human Gate (menschliche Freigabe)](https://agentnas.com/de/concepts/human-gate/): Erscheint nur vor unumkehrbaren, nach außen gerichteten oder rechteerweiternden Aktionen und zeigt den echten Diff. - AN-06 [Trust Labels (Vertrauenslabels)](https://agentnas.com/de/concepts/trust-labels/): Zwei kleine Labels plus Sitzungskontamination setzen die Zweierregel durch. ### Wissen Was weiß der Agent, wie liest er, und wie vergisst er? - AN-07 [Agent Memory (Agentengedächtnis)](https://agentnas.com/de/concepts/agent-memory/): Notizen, die Sie lesen und bearbeiten können, sind die Wahrheit. Indizes sind ein Cache, den Sie wegwerfen können. - AN-08 [Budgeted Reads (budgetiertes Lesen)](https://agentnas.com/de/concepts/budgeted-reads/): Eine Datei als Gliederung, Abschnitt, Zeilenbereich oder vollständig lesen, abgestuft, damit sie ins Budget passt. - AN-09 [Cascade Forget (kaskadierendes Vergessen)](https://agentnas.com/de/concepts/cascade-forget/): Ableitungen entlang der Lineage löschen, den Verlauf nach Aufbewahrungsklasse behandeln und melden, was nicht möglich war. ## Vier Schichten, sechs Kernbegriffe Die Store-Schicht nutzt bewährten Speicher, wie er ist. Jede Schicht darüber lässt sich aus ihr neu aufbauen, und der Kern besteht nur aus sechs Begriffen: Tree, Commit, Principal, Run, Lease und Record. Wir erfinden keine Speicher-Engine; die Innovation liegt im Vertrag. - **Interface**: Projiziert Fähigkeiten in Schnittstellen, die Agenten, Menschen und Werkzeuge bereits nutzen. Gateways sind zustandslos und entscheiden nie, wer was darf. (Mount (POSIX), Git, S3, WebDAV/SMB, MCP, HTTP, CLI, A2A (optional)) - **Trust (Vertrauen)**: Die einzige Autorisierungsstelle. Deterministische Richtlinien, kein Modell in der Entscheidung. (Principals und Ausführungen, Capability Lease, Richtlinien-Engine, Human Gate, Trust Labels, Credential Broker, Flight Recorder) - **Memory (Gedächtnis)**: Macht aus Notizen durchsuchbares Wissen. Alles lässt sich aus der Schicht darunter neu aufbauen. (Agent Memory, Budgeted Reads, Cascade Forget, Indizes, Wartungsjobs, Lineage) - **Store (Speicher)**: Ein Tree mit Verlauf, auf bewährten Dateisystem-Snapshots, Git oder versioniertem Objektspeicher. (Tree, Commit, Agent Branch, Dateisystem-Snapshots, Git, Objektspeicher) - **Sync (Synchronisierung, optional)**: Replikation und Teilen zwischen Knoten. Absichtlich zuletzt: Bringen Sie zuerst einen einzelnen Knoten in Ordnung. (Git-Remotes, Snapshot-Transfer, Lease-Links, Übergabepakete) [Die Architektur lesen](https://agentnas.com/de/architecture/). ## Die Reise einer Ausführung 1. **Eine Lease anfordern.** Der Orchestrator des Recherche-Agenten Cleo fordert für diese Ausführung eine [Capability Lease](https://agentnas.com/de/concepts/capability-lease/) an: `/shared/launch` lesen, Änderungen vorschlagen, vier Stunden gültig. Der vom Eigentümer vorab festgelegte Richtlinienrahmen genehmigt sie automatisch. 2. **Die Arbeit beginnen.** Das NAS legt die Ausführung und ihren Branch `cleo/run_91ab` an; die Sandbox bindet den Branch wie ein gewöhnliches Verzeichnis ein. Cleo liest `AGENTS.md` und das geprüfte Gedächtnis aus dem eigenen [Agent Home](https://agentnas.com/de/concepts/agent-home/). 3. **Im Budget lesen.** Cleo liest einen langen Bericht mit [Budgeted Reads](https://agentnas.com/de/concepts/budgeted-reads/): zuerst eine Gliederung mit 400 Token, danach nach Bedarf bestimmte Zeilenbereiche. Jeder Lesezugriff wird dem Lesemanifest der Ausführung hinzugefügt. 4. **Auf einem Branch arbeiten.** Änderungen landen auf einem [Agent Branch](https://agentnas.com/de/concepts/agent-branch/). Der gemeinsame `main` ändert sich vorerst überhaupt nicht. 5. **Ein Gate treffen.** Cleo hat eine Webseite gelesen, daher geben die [Trust Labels](https://agentnas.com/de/concepts/trust-labels/) der Sitzung die Kontamination `external`. Wenn Cleo einen Merge in `main` vorschlägt, verlangt die Richtlinie ein [Human Gate](https://agentnas.com/de/concepts/human-gate/): Der Eigentümer sieht auf dem Smartphone den echten, vom NAS berechneten Diff und die nicht vertrauenswürdige Quelle und gibt frei. 6. **Eine Spur hinterlassen.** Der Merge erzeugt einen Commit mit Provenienz. Was gelesen, was geschrieben und wer was freigegeben hat, geht in den [Flight Recorder](https://agentnas.com/de/concepts/flight-recorder/), per Hash verkettet. 7. **Das Gedächtnis festigen.** Cleo hält ein paar neue Fakten fest. Weil diese Sitzung externe Inhalte gelesen hat, kommen diese Notizen von [Agent Memory](https://agentnas.com/de/concepts/agent-memory/) zunächst in Quarantäne: Sie lassen sich abrufen, werden aber nicht automatisch geladen, bis ein Mensch sie geprüft hat. 8. **Vergessen.** Wochen später bittet ein Kunde darum, vergessen zu werden. [Cascade Forget](https://agentnas.com/de/concepts/cascade-forget/) löscht entlang der Lineage die zugehörigen Zusammenfassungen und Indizes und stellt einen Bericht aus, der festhält, was nicht abgedeckt werden konnte. ## Es spricht, was Agenten schon sprechen Für den Einstieg ist kein neues SDK nötig. Jeder Agent, der Dateien lesen und schreiben, Git oder S3 nutzen oder MCP-Tools aufrufen kann, kann Agent NAS verwenden. Die Sitzung unten veranschaulicht nur die geplante Kommandozeile. *Beispielsitzung* ```bash $ nas lease create --role cleo --paths "/shared/launch/**" --actions read,write,propose --ttl 4h lease lse_7Qk3 · run run_91ab · branch cleo/run_91ab · expires 16:00 $ nas mount --lease lse_7Qk3 ~/work # plain files, on a branch $ ./draft-release-notes.sh # the agent works with ordinary tools $ nas propose --into main gate gt_2Mx4 waiting for approval: merge cleo/run_91ab into main (4 files) $ nas gate approve gt_2Mx4 # the owner, from another terminal or a phone merged · commit 91ce3a7 · record 18211 ``` [Alle Schnittstellen ansehen](https://agentnas.com/de/interfaces/). ## Worauf wir setzen Ein Entwurf, der jahrelang halten soll, muss sagen, worauf er setzt und was passiert, wenn er falsch liegt. - **Agenten werden Dateisysteme und Git weiter als wichtigstes Arbeitsmedium nutzen.** Falls nicht, wird Agent Home zu einem Exportformat, und die anderen Konzepte gelten weiter. - **Die „Ausführung“ bleibt die natürliche Einheit für Autorisierung und Zurechenbarkeit.** Falls langlebige autonome Prozesse aufkommen, werden Leases zu fortlaufenden Verlängerungen mit Budgets. - **Prompt Injection wird auf absehbare Zeit auf Modellebene nicht beseitigt.** Falls doch, werden Trust Labels zu einer billigen zusätzlichen Verteidigungsschicht. - **Menschliche Aufmerksamkeit bleibt knapp.** Falls Vollautomatisierung verlässlich genug wird, weicht ein Human Gate einer vorab autorisierenden Richtlinie, und der Prüfpfad bleibt. Alle sieben Wetten stehen in den [Entwurfsprinzipien](https://agentnas.com/de/principles/). ## Diese Website ist auch für Agenten lesbar Jede Seite hat einen Markdown-Zwilling, die Website veröffentlicht `llms.txt` und betreibt einen kleinen schreibgeschützten MCP-Server. Probieren Sie es im Terminal aus: *Terminal* ```bash curl -H "Accept: text/markdown" https://agentnas.com/what-is-agent-nas/ curl https://agentnas.com/llms.txt curl -X POST https://agentnas.com/api/search \ -H "content-type: application/json" \ -d '{"query": "capability lease", "limit": 5}' ``` So fügen Sie den Dokumentationsserver einem MCP-Client hinzu: *mcp.json* ```json { "mcpServers": { "agentnas-docs": { "url": "https://agentnas.com/mcp" } } } ``` ## Die Fragen, die zuerst gestellt werden ### Was ist Agent NAS in einem Satz? Netzwerkspeicher, der um die Ausführung herum gebaut ist: Jede Ausführung eines Agenten arbeitet in einem isolierten Branch und greift über eine kurzlebige, enge Lease auf Daten zu; jede Änderung lässt sich nachverfolgen und rückgängig machen; und das Gedächtnis sind gewöhnliche Dateien mit Provenienz. ### Gibt es Software zum Herunterladen? Noch nicht. Agent NAS ist derzeit ein Konzept mit einem Spezifikationsentwurf (v0.2). L0 und L1 lassen sich schon heute aus Git, Dateisystem-Snapshots und einem kleinen Gateway bauen; Ziel für die Referenzimplementierung v0 ist die erste Hälfte 2027. Siehe die [Roadmap](https://agentnas.com/de/roadmap/). ### Wie unterscheidet es sich von den KI-Agenten, die NAS-Hersteller ausliefern? Diese Agenten verwalten die Box. Agent NAS legt fest, wie andere Agenten mit den Daten in der Box arbeiten: Branches, Leases, Gedächtnis und Vergessen. Beides ergänzt sich, und die Box eines Herstellers kann die Grundlage eines Overlay-Einsatzes sein. ### Ersetzt es meinen bestehenden Speicher? Nein. Die Einsatzform Overlay sitzt vor einem vorhandenen NAS, Objektspeicher oder Git-Host und verwaltet darin nur ein einziges Verzeichnis oder einen Bucket. ### Kann es Prompt Injection stoppen? Nein. Es begrenzt, was nach einer Injection passiert, und macht die Folgen sichtbar und umkehrbar. Die ehrlichen Grenzen stehen auf der Seite [Sicherheit](https://agentnas.com/de/security/). ### Kann ich jederzeit gehen? Ja. Alles lässt sich als gewöhnliche Dateien und Git-Verlauf exportieren. Das ist eine Entwurfsgarantie, keine optionale Funktion. [Alle Fragen](https://agentnas.com/de/faq/). ## Wo wir stehen > **Stand.** Agent NAS befindet sich in der Konzept- und Entwurfsphase der Spezifikation (v0.2, November 2026). v0.2 ist eine Überarbeitung auf den Boden der Tatsachen: Dreizehn Konzepte wurden auf neun reduziert, und jedes sagt, wie man klein anfängt und wo seine ehrlichen Grenzen liegen. Es gibt noch keine Referenzimplementierung. - [Spezifikationsentwurf](https://agentnas.com/de/spec/): Konformitätsstufen und ausführbare Abnahmetests. - [Roadmap](https://agentnas.com/de/roadmap/): Jetzt, als Nächstes, später und was wir nicht tun werden. - [Über dieses Projekt](https://agentnas.com/de/about/): Lizenz, Zitieren und Mitmachen. --- Kanonische URL: https://agentnas.com/de/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Was ist Agent NAS? > Agent NAS ist Netzwerkspeicher, der um die Ausführung (Run) herum gebaut ist: Jede Ausführung eines Agenten arbeitet in einem isolierten Branch und greift über eine kurzlebige, enge Lease auf Daten zu; jede Änderung lässt sich nachverfolgen und rückgängig machen; und das Gedächtnis sind gewöhnliche Dateien mit Provenienz. Bedient wird es über das, was Agenten ohnehin sprechen: Dateien, Git, S3 und MCP. ## In einem Absatz Agent NAS bewahrt alles auf, was ein Agent braucht, um über längere Zeit zu arbeiten: Anweisungen, Skills, Gedächtnis, laufende Arbeit und Verlauf. Es beantwortet Fragen, die ein klassisches NAS nicht interessieren: Was darf diese Ausführung anfassen, lässt sich ein Fehler rückgängig machen, wer hat was freigegeben und woher stammt eine Erinnerung? Es ist keine neue Speicher-Engine, sondern ein **Vertrag** auf bewährtem Speicher (Dateisysteme, Git, Objektspeicher), der festlegt, wie Befugnis, Isolation, Nachvollziehbarkeit und Gedächtnis zwischen Agenten und Daten funktionieren sollen und wie man das überprüft. ## Den Namen auseinandernehmen - **Agent**: Ein KI-System, das im Auftrag von jemandem handelt: Es liest, entscheidet und nutzt über viele Schritte hinweg Werkzeuge. In Agent NAS gehört ein Agent zu einer **Rolle**, und jede Arbeit ist eine **Ausführung**. - **Netzwerkangebunden (network-attached)**: Über ein Netzwerk von vielen Clients gleichzeitig erreichbar, sei es ein Heimnetz, ein Teamserver oder eine Cloud-Region. Nicht an eine einzelne Sandbox oder Maschine gebunden. - **Speicher (storage)**: Dauerhaft, versioniert und exportierbar. Der Speicher ist die Quelle der Wahrheit; alles „Intelligente“ wird daraus abgeleitet und lässt sich verwerfen und neu aufbauen. ## Was etwas zu einem Agent NAS macht 1. **Die Einheit des Zugriffs ist die Ausführung.** Jede Ausführung hat ihre eigene [Lease](https://agentnas.com/de/concepts/capability-lease/), keinen gemeinsamen Schlüssel und kein Konto eines Menschen. 2. **Standardmäßig isoliert und umkehrbar.** Schreibzugriffe landen zuerst auf einem [Branch](https://agentnas.com/de/concepts/agent-branch/); geschützte Daten ändern sich nur durch Merges; Löschen ist ein Soft Delete. 3. **Jede Änderung ist nachvollziehbar.** Wer sie vorgenommen hat, in wessen Auftrag, unter welcher Lease und was gelesen wurde ([Flight Recorder](https://agentnas.com/de/concepts/flight-recorder/)). 4. **Gedächtnis sind Dateien mit Provenienz, und Indizes sind verwerfbar** ([Agent Memory](https://agentnas.com/de/concepts/agent-memory/)). 5. **Es wird über vorhandene Schnittstellen bereitgestellt:** Mounts, Git, S3 und MCP, kein neues Protokoll. 6. **Ohne die KI-Schicht bleibt es ein solides Allzweck-NAS,** und alle Daten lassen sich vollständig exportieren. ## Was es nicht ist - **Keine neue Speicher-Engine, kein neues Dateisystem und keine neue Vektordatenbank.** Alle werden als vorhandene Bausteine verwendet. - **Keine Sandbox.** Es isoliert keine Rechenleistung, sondern begrenzt das Verhältnis zwischen Agenten und Daten und sollte zusammen mit einer Sandbox genutzt werden. - **Kein Heilmittel gegen Prompt Injection.** Es begrenzt die Folgen und verhindert nicht, dass eine Injection geschieht. Siehe [Sicherheit](https://agentnas.com/de/security/). - **Kein Agenten-Framework.** Es sagt nicht, wie Agenten denken, planen oder Modelle aufrufen. ## Für wen es gedacht ist, und wer es nicht braucht - **Entwickler, die bereits `AGENTS.md` und Git nutzen:** Sie wollen eine geschützte Hauptlinie, umkehrbare Ausführungen und ein nachvollziehbares Protokoll. - **Teams, die mehrere Agenten betreiben:** Sie brauchen einen gemeinsamen Tree, Review der Änderungen von Agenten und eine Antwort auf „Was hat er tatsächlich gelesen?“. - **Privatpersonen mit einem persönlichen Agenten:** Sie wollen, dass das Gedächtnis in den eigenen Händen bleibt, les- und bearbeitbar und portabel. - **Organisationen, die Kundendaten verarbeiten:** Sie brauchen Aufbewahrung und Vergessen als ausdrückliche Entscheidungen beim Schreiben und einen ehrlichen Bericht über das Vergessen. > **Wer es nicht braucht.** Wenn Sie einen Agenten haben und Daten, die Sie problemlos neu erzeugen können, brauchen Sie Agent NAS **nicht**: Ein Git-Repository mit einer `AGENTS.md` genügt. Es lohnt sich, wenn Daten wichtig werden, Agenten sich vermehren und Sie wissen wollen: „Was hat er tatsächlich gelesen und geändert?“. Weitere Fälle stehen unter [Anwendungsfälle](https://agentnas.com/de/use-cases/). ## Agent NAS und die Verwaltungsagenten der Hersteller | Frage | Verwaltungsagenten der NAS-Hersteller | Agent NAS | | --- | --- | --- | | Was tut der Agent? | Verwaltet dieses NAS in natürlicher Sprache und macht aus Gesprächen Operationen. | Arbeitet mit den Daten in der Box: lesen, schreiben, merken und ein Protokoll hinterlassen. | | Wie wird Zugriff gewährt? | Nutzt die Berechtigungen des Nutzers mit, mit einer zweiten Bestätigung für gefährliche Operationen. | Eine kurzlebige Lease, gebunden an eine Ausführung: Pfade, Aktionen, Ablauf, Budgets. | | Was, wenn etwas schiefgeht? | Verlässt sich auf Bestätigungen und Logs. | Schreibzugriffe landen auf einem Branch; Löschen ist ein Soft Delete; Snapshots liegen außerhalb jeder Lease. | | Wo lebt das Gedächtnis? | Auf den Servern des Assistenten oder des Herstellers. | Als Notizen mit Provenienz im Home des Agenten; Indizes sind verwerfbar. | | Nicht vertrauenswürdige Inhalte? | Gelangen wie jeder andere Text in das Modell. | Tragen das Label `external`; nach dem Lesen laufen folgenreiche Aktionen über ein Gate. | | Wie komme ich wieder heraus? | Hängt vom Hersteller ab. | Alles lässt sich als gewöhnliche Dateien und Git-Verlauf exportieren. | ## Was Sie als Nächstes lesen sollten - [Die neun Konzepte](https://agentnas.com/de/concepts/): Je eine Seite, mit dem Weg, klein anzufangen. - [Architektur](https://agentnas.com/de/architecture/): Vier Schichten, sechs Kernbegriffe und die Reise einer Ausführung. - [Sicherheit](https://agentnas.com/de/security/): Bedrohungsmodell, Schutzmaßnahmen und ehrliche Grenzen. - [FAQ](https://agentnas.com/de/faq/): Kurze Antworten auf häufige Fragen. --- Kanonische URL: https://agentnas.com/de/what-is-agent-nas/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Die neun Konzepte > Agent NAS baut auf neun benannten Konzepten auf. Sie beantworten drei Fragen: Wo findet die Arbeit statt, und was ist passiert? Wer darf was, und auf wessen Anweisung? Und was weiß der Agent, wie liest er und wie vergisst er? Die Namen der Konzepte sind geprägte Begriffe und bleiben in jeder Sprache englisch, mit einer Erläuterung in der jeweiligen Sprache. Jede Seite beginnt mit einer zitierbaren Definition und behandelt dann das Problem, den Mechanismus, den Weg, klein anzufangen, eine Schnittstellenskizze, was die Spezifikation verlangt und was übernommen ist, samt ehrlichen Grenzen. Die Konformitätsstufe sagt, ab wann eine Implementierung das Konzept unterstützen sollte; siehe die [Spezifikation](https://agentnas.com/de/spec/). > **Zum Wort „neu“.** Die meisten der neun Konzepte kombinieren bewährte Bausteine. Jede Konzeptseite sagt, was sie übernimmt und was wirklich neu ist. Die Übersicht steht auf der Seite [Vergleich](https://agentnas.com/de/compare/). ## Drei Gruppen ### Arbeit Wo findet die Arbeit statt, und was ist passiert? - AN-01 [Agent Home (Home-Verzeichnis)](https://agentnas.com/de/concepts/agent-home/): Ein Verzeichnis pro Rolle, mit Verlauf. Gewöhnliche Dateien, die Sie mitnehmen können. - AN-02 [Agent Branch (Agentenzweig)](https://agentnas.com/de/concepts/agent-branch/): Jede Ausführung arbeitet auf einem Copy-on-Write-Branch. Nur ein geprüfter Merge erreicht die Hauptlinie. - AN-03 [Flight Recorder (Flugschreiber)](https://agentnas.com/de/concepts/flight-recorder/): Ein Protokoll pro Ausführung, per Hash verkettet, das auch festhält, was gelesen wurde. ### Befugnis Wer darf was, und auf wessen Anweisung? - AN-04 [Capability Lease (befristete Berechtigung)](https://agentnas.com/de/concepts/capability-lease/): Eine enge Autorisierung für eine Ausführung, mit Ablauf und Budgets. Kind-Leases können nur enger sein. - AN-05 [Human Gate (menschliche Freigabe)](https://agentnas.com/de/concepts/human-gate/): Erscheint nur vor unumkehrbaren, nach außen gerichteten oder rechteerweiternden Aktionen und zeigt den echten Diff. - AN-06 [Trust Labels (Vertrauenslabels)](https://agentnas.com/de/concepts/trust-labels/): Zwei kleine Labels plus Sitzungskontamination setzen die Zweierregel durch. ### Wissen Was weiß der Agent, wie liest er, und wie vergisst er? - AN-07 [Agent Memory (Agentengedächtnis)](https://agentnas.com/de/concepts/agent-memory/): Notizen, die Sie lesen und bearbeiten können, sind die Wahrheit. Indizes sind ein Cache, den Sie wegwerfen können. - AN-08 [Budgeted Reads (budgetiertes Lesen)](https://agentnas.com/de/concepts/budgeted-reads/): Eine Datei als Gliederung, Abschnitt, Zeilenbereich oder vollständig lesen, abgestuft, damit sie ins Budget passt. - AN-09 [Cascade Forget (kaskadierendes Vergessen)](https://agentnas.com/de/concepts/cascade-forget/): Ableitungen entlang der Lineage löschen, den Verlauf nach Aufbewahrungsklasse behandeln und melden, was nicht möglich war. --- Kanonische URL: https://agentnas.com/de/concepts/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Architektur > Agent NAS hat vier Schichten und eine optionale Synchronisierungsschicht: Interface projiziert Fähigkeiten in vorhandene Schnittstellen, Trust ist die einzige Autorisierungsstelle, Memory macht aus Notizen durchsuchbares Wissen, und Store hält einen Tree mit Verlauf. Die Memory-Schicht lässt sich als Ganzes löschen und neu aufbauen, und Store nutzt schlicht bewährten Speicher. ## Vier Schichten und optionale Synchronisierung - **Interface**: Projiziert Fähigkeiten in Schnittstellen, die Agenten, Menschen und Werkzeuge bereits nutzen. Gateways sind zustandslos und entscheiden nie, wer was darf. (Mount (FUSE, NFS, SMB), Git, S3-kompatibel, WebDAV, MCP, HTTP-API, CLI, A2A (optional)) - **Trust (Vertrauen)**: Die einzige Autorisierungsstelle. Eine deterministische Richtlinien-Engine ohne Modell in der Entscheidung; erst protokollieren, dann handeln. (Principals und Ausführungen, Capability Lease, Richtlinien-Engine, Human Gate, Trust Labels, Credential Broker, Flight Recorder) - **Memory (Gedächtnis)**: Macht aus Notizen durchsuchbares, budgetiert lesbares Wissen. Alles lässt sich aus der Schicht darunter neu aufbauen. (Notizkonventionen, Indizes (Volltext, Vektor, Graph), Budgeted Reads, Wartungsjobs, Lineage, Cascade Forget) - **Store (Speicher)**: Ein Tree mit Verlauf, auf bewährten Dateisystem-Snapshots, Git oder versioniertem Objektspeicher. Er versteht weder Gedächtnis noch Labels. (Tree, Commit, Agent Branch, Dateisystem-Snapshots, Git, Objektspeicher) - **Sync (Synchronisierung, optional)**: Replikation und Teilen zwischen Knoten. Absichtlich zuletzt: Bringen Sie zuerst einen einzelnen Knoten in Ordnung. (Git-Remotes, Snapshot-Transfer, Lease-Links, Übergabepakete) - **Die Memory-Schicht ist wiederaufbaubar.** Löschen Sie alle Indizes und bauen Sie neu auf: Die Notizen im Store bleiben vollständig lesbar. - **Gateways sind zustandslos.** Aller persistente Zustand liegt im Store und in den Protokollen von Trust; ein Gateway darf jederzeit neu starten und lässt sich horizontal skalieren. - **Trust ist die einzige Autorisierungsstelle.** Dazu zählen auch die Hintergrundjobs des NAS (Indexierung, Wartung): Auch sie laufen als `svc:*`-Principals mit Leases. - **Store versteht weder Gedächtnis noch die Semantik von Labels.** Er hält nur einen Tree mit Metadaten. - **Erst protokollieren, dann handeln.** Eine folgenreiche Operation muss zuerst einen Absichtseintrag schreiben. ## Die schmale Taille: sechs Kernbegriffe Der gesamte Entwurf hängt an sechs Kernbegriffen; Labels, Gates, Gedächtnis und Lesemanifeste sind Konventionen, die darauf aufbauen. | Begriff | Bedeutung | Zentrale Invariante | | --- | --- | --- | | Tree | Ein Verzeichnisbaum mit Verlauf. | Jeder Commit lässt sich reproduzieren; es gibt einen Inhalts-Hash oder eine gleichwertige Änderungserkennung. | | Commit | Eine unveränderliche Änderung. | Trägt Provenienz-Metadaten: `principal`, `on_behalf_of`, `run`, `lease`. | | Principal | Eine Entität, die authentifiziert und zur Verantwortung gezogen werden kann. | Typ ist `human`, `agent`, `service` oder `node`; ein `agent` gehört zu einer Rolle, nicht zu einer einzelnen Ausführung. | | Run | Eine Ausführung mit Anfang, Ende, Zweck und einem Verantwortlichen. | Hält genau eine Wurzel-Lease; besitzt genau einen Branch. | | Lease | Die Autorisierung einer Ausführung. | Hat ein Ablaufdatum; kann nur enger werden; widerrufbar; trägt Budgets. | | Record | Ein Append-only-Eintrag. | Per Hash verkettet; erst protokollieren, dann handeln. | ## Die Store-Schicht: Vertrag und mögliche Engines Der Store-Vertrag wird von einer Engine bereitgestellt oder vom Gateway nachgebildet. Eine Implementierung darf Engines kombinieren, zum Beispiel Git für Text und Snapshots für große Dateien; der Vertrag schreibt weder die Engine noch die Hash-Funktion noch das On-Disk-Format vor. 1. Atomare Commits. 2. Günstige Forks: idealerweise nahe an O(1); schlimmstenfalls als Kopie, dann sind Kontingente und eine TTL Pflicht. 3. Unveränderliche Snapshots. 4. Änderungserkennung: ein Inhalts-Hash oder Gleichwertiges. 5. Die Differenz zwischen zwei Commits. 6. Vollständiger Export in einem Standardformat: ein Verzeichnis, Git-Verlauf und die Klartext-Metadaten in `.nas/`. | Engine | Geeignet für | Fork-Kosten | Hinweis | | --- | --- | --- | --- | | Git (mit Worktrees) | Text, Gedächtnis, Skills, kleine Codebasen | Gering | Große Dateien brauchen LFS oder externen Speicher; Binär-Merges sind schlecht. | | Dateisystem-Snapshots und -Clones (ZFS, btrfs, APFS) | Große Verzeichnisse, gemischte Dateien | Etwa O(1) | Hängt vom Dateisystem ab; Kopieren zwischen Maschinen braucht send/receive. | | Versionierter Objektspeicher (Tigris-Forks, lakeFS, S3 plus Manifest) | Datensätze, große Dateien | Etwa O(1) | Das Gateway muss eine Dateiansicht bereitstellen. | | Einfaches Verzeichnis plus Kopie | Einstieg mit Lite | O(n) | Nur für kleine Datenmengen; Kontingente und eine TTL sind Pflicht. | > **Der Wiederherstellungspfad liegt außerhalb des Schadensradius.** Snapshots und Backups gehören dem Eigentümer-Principal, und keine Lease darf „einen Snapshot löschen“ oder „ein Backup löschen“ enthalten. Das ist die direkteste Lehre aus dem Vorfall vom April 2026: Der Wiederherstellungspfad muss außerhalb des Schadensradius dessen liegen, was er schützt. - Verschlüsselung im Ruhezustand kommt von der darunterliegenden Schicht; die Aufbewahrungsklasse `sensitive` hat eine eigene Schlüsseldomäne und lässt sich daher durch Zerstören des Schlüssels vernichten. - Deduplizierung und Vernichtung stehen im Konflikt: Die Klasse `sensitive` wird nicht über Schlüsseldomänen hinweg dedupliziert. ## Die Reise einer Ausführung 1. **Anfordern.** Der Orchestrator (oder der Eigentümer) fordert für eine Ausführung eine Lease an: Pfade, Aktionen, Ablauf, Zweck. Innerhalb des **Richtlinienrahmens** wird sie automatisch ausgestellt; außerhalb geht sie an ein Human Gate. 2. **Starten.** Das NAS legt den `run` und den Branch `/` an und übergibt die Lease an die Ausführung; die Sandbox bindet den Branch ein (oder führt ein `git clone` aus). 3. **Arbeiten.** Der Agent liest und schreibt mit gewöhnlichen Dateiwerkzeugen. Lesezugriffe sammeln sich im **Lesemanifest**, und die Sitzungskontamination wird entsprechend aktualisiert; Zugriffe außerhalb der Grenzen werden abgelehnt und protokolliert. 4. **Committen.** Änderungen werden automatisch (entprellt) oder ausdrücklich committet, und jeder Commit trägt Provenienz-Metadaten. 5. **Vorschlagen.** `propose` erzeugt einen **Agent PR**: den Diff, die Absicht, eine Zusammenfassung des Lesemanifests, Prüfergebnisse und eine Zusammenfassung der Labels. 6. **Entscheiden.** Die Richtlinien-Engine entscheidet: Bestehen die Prüfungen und ist das Risiko gering, wird automatisch gemergt; geht es um geschützte Daten, eine nach außen gerichtete Aktion oder einen Verstoß gegen die Zweierregel, geht es an ein Human Gate; ist etwas eindeutig verboten, wird abgelehnt. 7. **Mergen und protokollieren.** Der Merge erzeugt einen Commit mit Provenienz und schreibt einen Record. 8. **Abschließen.** Die Lease läuft ab; der Branch wird nach seiner TTL in den Papierkorb verschoben; Lesemanifeste und Records werden nach der Aufbewahrungsrichtlinie vorgehalten. **Der Lesepfad:** Anfrage, Lease-Prüfung, Label-Prüfung (erlaubt die aktuelle Sitzungskontamination dieses Lesen?), Budgetzählung, Lesen aus dem Store, Eintrag im Lesemanifest, Inhalt und Belegzeiger zurückgeben. > **Erst protokollieren, dann handeln.** Eine folgenreiche Operation (Merge, Löschen, Teilen, Egress, Lease-Änderung) muss zuerst einen Absichtseintrag schreiben; lässt er sich nicht schreiben, schlägt die Operation fehl (fail closed). Lesezugriffe gehen in das Lesemanifest, das stapelweise geschrieben wird und nicht pro Lesezugriff synchron sein muss. ## Einsatzformen | Form | Beschreibung | Geeignet für | | --- | --- | --- | | Lite | Einzelner Rechner, einzelner Nutzer: ein Gateway-Prozess plus lokaler Speicher (Git oder Dateisystem-Snapshots); L0 bis L1. | Privatpersonen und Entwickler beim Ausprobieren. | | Overlay | Lässt das vorhandene NAS oder den Objektspeicher unangetastet: Ein Gateway sitzt davor und verwaltet nur ein einziges Verzeichnis oder einen Bucket; Mounts und die S3-Ansicht laufen über das Gateway. | **Der realistischste Einstieg:** Wer schon eine Box hat. | | Team | Mehrere Nutzer und Agenten, ein Server oder ein kleiner Cluster; L0 bis L3; Gate-Benachrichtigungen und ein Leitstand. | Kleine Teams. | | Cloud | Ein gehosteter mandantenfähiger Dienst mit starker Isolation; L0 bis L3. | Wer keine eigene Hardware hat. | Das Prinzip: Spezielle Hardware ist nicht nötig, jeder dauerhaft laufende Rechner genügt; Beschleuniger sind optional, denn für Embeddings und Zusammenfassungen reichen kleine Modelle, und externe Dienste lassen sich ebenfalls aufrufen. ## Ein v0 aus vorhandenen Bausteinen bauen | Fähigkeit | Bausteine, die es heute schon gibt | | --- | --- | | Store und Branches | Git und Worktrees; btrfs- oder ZFS-Snapshots; oder Tigris und lakeFS (Objektspeicher). | | Geschützte Hauptlinie | Branch-Schutz in Forgejo, Gitea oder GitHub; oder geschützte Branches in lakeFS. | | Leases | Ein OAuth-Autorisierungsserver (zum Beispiel Keycloak) mit Token Exchange und ein Resource Server, der Pfadpräfix und Aktion prüft; oder ein Signaturdienst von ein paar hundert Zeilen. | | Records | Eine Append-only-SQLite-Tabelle plus ein täglicher Hash; Git-Trailer in Commits; OpenTelemetry-Export. | | Gates | PR-Review plus eine Push-Benachrichtigung; die CLI `nas gate approve`. | | Gedächtnis | Markdown unter `memory/` plus SQLite FTS5; einen Vektorspeicher können Sie später ergänzen. | | Labels | Das Importverzeichnis als `external` markieren; die Sitzungskontamination pro Ausführung im Gateway halten. | | Schnittstellen | NFS-, SMB- oder FUSE-Mount; Git über SSH oder HTTPS; ein S3-Gateway; ein kleiner MCP-Server. | Was diese Tabelle sagt: **L0 und L1 brauchen keine neue Erfindung.** Neu ist der Vertrag, der sie verbindet, und die Tests, die ihn überprüfen; siehe die [Spezifikation](https://agentnas.com/de/spec/). ## Betrieb - **Backups:** 3-2-1; Snapshots und Backups gehören dem Eigentümer-Principal, und keine Lease darf sie berühren; üben Sie jedes Quartal eine Wiederherstellung und halten Sie sie im Protokoll fest. - **Upgrades:** Gateways sind zustandslos und lassen sich schrittweise aktualisieren; jede Änderung des Store-Formats muss mit einem Migrations- und Rollback-Plan kommen; die Memory-Schicht lässt sich als Ganzes neu aufbauen. - **Überwachung:** Raten der Lease-Ausstellung und -Ablehnung; Länge der Gate-Warteschlange und Freigabequote (bleibt die Freigabequote über 95 %, sind Gates zu häufig und sollten zusammengelegt oder die Richtlinie verschärft werden); Anzahl und Alter der Branches; Aktualität der Indizes; Prüfung der Record-Kette; Kontingente. - **Kapazität:** Branches haben eine TTL und Kontingente; der Papierkorb hat eine Aufbewahrungsfrist; abgeleitete Daten haben ein Budget. ## Der Leitstand Die Oberfläche für Menschen kann eine Webseite, eine CLI oder ein Chatbot sein. Sie ist nicht zwingend: L0 bis L1 können vollständig mit einer CLI und einer vorhandenen Git-Plattform laufen. - **Aktivitätsverlauf:** nach Ausführung aggregiert: wer was getan hat und was gelesen wurde. - **Gate-Posteingang:** Aktionen, die auf Freigabe warten, als Gate Cards dargestellt. - **Rollenverzeichnis:** Home, Leases, Budgets und letzte Ausführungen jeder Rolle. - **Gedächtnis-Browser:** Notizen und Quellen, die Quarantäne ungeprüfter Notizen, Wartungsvorschläge. - **Branches und PRs:** nicht gemergte Branches und der Papierkorb. - **Vergessen-Konsole:** Anfragen, eine Lineage-Vorschau und Berichte. Menschen können auch direkt über SMB oder WebDAV nachsehen: `/humans//Agent Activity/` ist eine schreibgeschützte Aktivitätsansicht aus gewöhnlichen Dateien. --- Kanonische URL: https://agentnas.com/de/architecture/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Schnittstellen > Agent NAS nutzt Dateien für die Datenebene und Tools für die Steuerungsebene: Bytes laufen über Mounts, Git und S3; Autorisierung, Freigabe, Gedächtnis, Suche und Erklärung laufen über MCP, HTTP und eine CLI. Jede Schnittstelle ist eine Projektion derselben Daten, und Unterschiede in der Semantik werden als ausdrückliche Fehler ausgedrückt, statt sie zu verschleiern. ## Prinzipien 1. **Dateien für die Datenebene, Tools für die Steuerungsebene.** Bytes laufen über Mounts, Git und S3; Autorisierung, Freigabe, Gedächtnis, Suche und Erklärung laufen über MCP, HTTP und eine CLI. 2. **Gateways sind zustandslos.** Autorisiert wird an genau einer Stelle in der Trust-Schicht. 3. **Jede Schnittstelle ist eine Projektion.** Unterschiede in der Semantik werden durch ausdrückliche Fehlerabbildungen ausgedrückt (zum Beispiel wird „Gate ausstehend“ auf ein `EACCES` mit einer erklärenden Datei abgebildet), und bei S3 wird nicht so getan, als gäbe es Branches. 4. **Eine schmale Tool-Oberfläche.** Höchstens 10 MCP-Tools richten sich an Agenten; Aktionen für Menschen und Betreiber liegen in einer eigenen Betreiberschnittstelle. 5. **Adapter isolieren Protokolländerungen.** Versionswechsel bei MCP und A2A betreffen nur die Adapter. ## Schnittstellenmatrix | Schnittstelle | Ebene | Zielgruppe | Abbildung | Stufe | | --- | --- | --- | --- | --- | | Mount (FUSE, NFS, SMB) | Daten | Agenten, Menschen, beliebige Programme | Eine Branch-Ansicht; Fehlerabbildung siehe unten | L0 | | Git (SSH, HTTPS) | Daten | Agenten, Menschen, CI | Ein Run-Branch ist ein Git-Branch; ein Agent PR ist ein Merge Request | L0 | | S3-kompatibel | Daten | Datenpipelines, Batch-Jobs | Ein Bucket entspricht einer Branch-Ansicht eines Trees; eine Versions-ID ist ein Commit | L0 (optional) | | WebDAV | Daten | Menschen (Finder, Explorer) | Eine schreibgeschützte Aktivitätsansicht | L0 (optional) | | CLI `nas` | Steuerung | Menschen, Skripte | Eins zu eins zur HTTP-API | L0 | | HTTP-API | Steuerung | Orchestratoren, der Leitstand | Alles `POST` mit JSON; Felder in `snake_case` | L1 | | MCP | Steuerung | Agenten | Neun Tools (siehe unten) | L1, L2 | | A2A | Steuerung | Andere Agenten | Eine Aufgabe entspricht `inbox/` und `outbox/` | L4 (optional) | ## Die MCP-Tool-Oberfläche Nur neun Tools richten sich an Agenten: | Tool | Was es tut | Benötigte Lease-Aktion | Hinweis | | --- | --- | --- | --- | | `nas_list` | Ein Verzeichnis auflisten, mit Labels und Review-Status | `list` | Pfade außerhalb der Lease sind unsichtbar. | | `nas_read` | Budgetiertes Lesen: Ansicht, Bereich, Budget | `read` | [Budgeted Reads](https://agentnas.com/de/concepts/budgeted-reads/) | | `nas_search` | Suchen (Volltext, optional Vektor), liefert Ausschnitte und Zeiger | `read` | Quarantäne ist standardmäßig ausgeschlossen. | | `nas_write` | Eine Datei im Branch schreiben, mit optionalem `intent` | `write` | Die meisten Laufzeitumgebungen nutzen direkt den Mount und brauchen es nicht. | | `nas_branch` | Branches anlegen, Checkpoints setzen, wiederherstellen und auflisten | `write` | [Agent Branch](https://agentnas.com/de/concepts/agent-branch/) | | `nas_propose` | Einen Agent PR erstellen | `propose` | Kann ein Gate auslösen. | | `nas_lease` | Eine engere Kind-Lease anfordern; aktuelle Lease und Budgets abfragen; weitergehende Befugnis anfordern (über ein Gate) | Keine | [Capability Lease](https://agentnas.com/de/concepts/capability-lease/) | | `nas_remember` | Eine Notiz schreiben, mit Quellen und Art | `write` | [Agent Memory](https://agentnas.com/de/concepts/agent-memory/) | | `nas_recall` | Notizen abrufen: budgetiert, mit Quellen und Review-Status | `read` | [Agent Memory](https://agentnas.com/de/concepts/agent-memory/) | > **Aktionen nur für Menschen und Betreiber.** `explain`, `gate approve/deny`, `forget`, `trash restore`, `label admin`, `lease revoke` und `policy edit` werden Agenten **nicht angeboten**. Diese Aktionen verändern die Garantien selbst und sollten nicht von der Partei aufrufbar sein, die eingeschränkt wird. Ein Agent darf einige davon **anfordern** (weitergehende Befugnis, Vergessen), aber nicht ausführen. ## Mount-Semantik - Ein Mount bindet **einen Branch und eine Lease**; läuft die Lease ab, wird der Mount schreibgeschützt und danach ausgehängt. - Automatische Commits (entprellt, zum Beispiel nach 5 ruhigen Sekunden); `fsync` löst einen Commit aus. - Pfade außerhalb der Lease **erscheinen nicht in Verzeichnislisten:** Das verringert das Durchsickern von Informationen und verkleinert die Angriffsfläche für Prompt Injection. - Sandbox-freundlich: kein Root nötig; FUSE oder NFS, eines von beiden, ohne Kernelmodul; schreibgeschützte Mounts sind möglich. | Situation | POSIX-Fehler | Hinweis | | --- | --- | --- | | Ein Pfad außerhalb der Lease | `ENOENT` (`EACCES`, wenn sichtbar, aber verweigert) | Die Ablehnung wird protokolliert. | | Kontingent oder Budget erschöpft | `EDQUOT` | Lässt die Ausführung sich selbst drosseln. | | Gate ausstehend | `EACCES`, mit einer Erklärung in `/.nas/pending` | Verhindert, dass der Agent endlos wiederholt. | | Lease abgelaufen | `ESTALE`, danach schreibgeschützt | Der Branch bleibt, bis seine eigene TTL abläuft. | ## Git - Run-Branches heißen `/`; `main` ist geschützt, und ein serverseitiger `pre-receive`-Hook lehnt direkte Pushes ab. - `nas propose` erstellt einen Agent PR. - Commits tragen automatisch Trailer wie `Run:`, `Lease:` und `Principal:`. ## S3 - Ein Bucket entspricht einer Branch-Ansicht eines Trees; die Versions-ID eines Objekts ist ein Commit. - Semantik, die S3 fehlt, etwa Branches, wird über ein Bucket-Präfix oder einen Request-Header (`x-nas-branch`) ausgedrückt. Das ist eine **abgeschwächte Projektion:** Datenpipelines können lesen und schreiben, bekommen aber nicht die volle Branch-Erfahrung. - Leases werden als temporäre Zugangsdaten im STS-Stil übergeben. ## A2A (optional) - Eingehende Aufgaben landen als Aufgabendateien in `inbox/`; Ergebnisse kommen nach `outbox/`. - Die Agent Card erklärt die Skills der Rolle und die Leases, die sie braucht. - **Das NAS ist kein A2A-Teilnehmer;** teilnehmen tut die Laufzeitumgebung, die für die Rolle handelt. Das NAS speichert nur Aufgaben und Ergebnisse, Übergabepakete und Leases. ## Konventionen der HTTP-API - **Jeder Endpunkt nutzt `POST`, mit Parametern in einem JSON-Body;** Antwortfelder sind immer `snake_case`. - Pfade sind versioniert: `/v1/...`. - Idempotenz: Schreiboperationen akzeptieren einen `idempotency_key`. - Paginierung: `cursor` plus `limit`. - Budgets und Ratenlimits werden in Antwort-Headern zurückgemeldet (verbleibende Bytes, verbleibende Anfragen), damit sich Laufzeitumgebungen selbst drosseln können. Eine budgetierte Leseanfrage und ihre Antwort sehen ungefähr so aus: *Budgetiertes Lesen* ```http POST /v1/files/read { "path": "/agents/cleo/memory/notes/customer-acme.md", "view": "outline", "budget_tokens": 400 } 200 OK { "view": "outline", "tokens": 212, "generated": false, "truncated": false, "content": "# Acme\n## Renewal (L12-L18)\n## Contacts (L19-L31)\n## Open issues (L32-L40)", "evidence": [ { "pointer": "nas://home-box/agents/cleo/memory/notes/customer-acme.md@9f2c1de#L1-L40" } ] } ``` Fehler haben eine einheitliche Struktur: *Fehlerantwort* ```json { "error": { "code": "gate_required", "message": "This merge requires human approval.", "retryable": false, "request_id": "req_01JB7W2X4N", "details": { "gate_id": "gt_2Mx4" } } } ``` ## Auffindbarkeit - Die maschinenlesbaren Einstiegspunkte entsprechen denen dieser Website: `/.well-known/ai-catalog.json`, die MCP Server Card und `llms.txt`. - Ein Endpunkt, der `nas://`-Belegzeiger auflöst und prüft. - MCP `server/discover`. --- Kanonische URL: https://agentnas.com/de/interfaces/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Sicherheit > Agent NAS verhindert keine Prompt Injection; es begrenzt, was danach passiert. Eine enge Lease begrenzt, was eine Ausführung anfassen darf, Branches machen Fehler umkehrbar, die Zweierregel verhindert, dass eine Sitzung, die nicht vertrauenswürdige Inhalte gelesen hat, zugleich sensible Daten und einen ausgehenden Kanal hält, und ein nachvollziehbares Protokoll bleibt zurück. ## Geltungsbereich und Vertrauensannahmen - **Was wir schützen:** die Daten und den Verlauf im NAS; die Grenze der Befugnis; die Integrität des Protokolls; die Nachvollziehbarkeit des Gedächtnisses. - **Was wir nicht schützen:** was ein Agent außerhalb des NAS tut; die Isolation der Rechenumgebung selbst (das ist Aufgabe der Sandbox); alles, was auf der Seite des Modellanbieters geschieht. - **Vertrauensannahmen:** Die vertrauenswürdige Basis (TCB) sind das NAS-Gateway, die Richtlinien-Engine und der Protokolldienst; der Host ist nicht kompromittiert; die Sandbox isoliert die Rechenumgebung. Ist die TCB kompromittiert, gelten die Garantien auf dieser Seite nicht mehr. ## Die Zweierregel (Rule of Two): eine Sitzungs-Invariante Drei Eigenschaften: **[A]** die Sitzung hat nicht vertrauenswürdige Inhalte gelesen, **[B]** die Lease erlaubt, sensible Daten zu lesen, **[C]** die Lease erlaubt, geschützten Zustand zu ändern oder nach außen zu kommunizieren. Gelten alle drei in einer Sitzung, wird der Aufruf, der C auslöst, nicht automatisch durchgelassen. | Szenario | A | B | C | Ergebnis | | --- | --- | --- | --- | --- | | Eine Webseite in einer Notiz auf dem Branch zusammenfassen | Ja | Ja | Nein (nur Branch) | Automatisch: Ein Schreibzugriff innerhalb des Branches zählt nicht als C. | | Nach dem Lesen einer Webseite einen Merge in `main` vorschlagen | Ja | Ja | Ja | Human Gate. | | Nur öffentliche Daten lesen, in einen Scratch-Bereich schreiben | Ja | Nein | Nein | Automatisch. | | Nach dem Lesen einer externen E-Mail eine E-Mail senden (Egress) | Ja | Ja | Ja | Gate; abgelehnt, wenn `secret` beteiligt ist. | Das ist die [Agents Rule of Two](https://ai.meta.com/blog/practical-ai-agent-security/) von Meta, umgesetzt an der **Speichergrenze**. Meta betont selbst, dass sie eine Heuristik zur Risikominderung ist, kein Endpunkt und kein Ersatz für das Prinzip der geringsten Rechte; wir verwenden sie genauso. Der Mechanismus steht unter [Trust Labels](https://agentnas.com/de/concepts/trust-labels/). ## Bedrohungsmodell | Bedrohung | Was das NAS durchsetzen kann | Was das NAS nicht kann | Restrisiko | | --- | --- | --- | --- | | T1 Indirekte Prompt Injection (über Dateien, Webseiten, E-Mail) | Die Zweierregel; Eingrenzung von Leases; Branches; Gates. | Verhindern, dass eine Injection geschieht, oder bösartiges Verhalten innerhalb der Lease danach stoppen. | Missbrauch innerhalb der Lease. | | T2 Preisgabe von Zugangsdaten (ein Agent liest einen langlebigen Schlüssel) | Langlebige Zugangsdaten gelangen nie in die Hände einer Ausführung; ein Secret-Scanner markiert `secret`; kurze TTLs. | Verhindern, dass ein Agent Daten innerhalb seiner Lease an einen genehmigten Egress sendet. | Daten, die innerhalb der Lease abfließen. | | T3 Zu weit gefasste Berechtigungen und Fehler | Enge Leases; Branches; Soft Delete; Snapshots außerhalb jeder Lease. | Nebenwirkungen außerhalb des NAS rückgängig machen. | Folgen jenseits des NAS. | | T4 Gedächtnisvergiftung (auch über Rollen hinweg) | Provenienz und Kontamination; Quarantäne; Autoload nur nach Prüfung; Rollback. | Fakten erkennen, die falsch sind, aber plausibel aussehen. | Gift, das ein Prüfer durchlässt. | | T5 Gestohlene oder wiedereingespielte Leases | Kurze TTL; widerrufbar; optionale Bindung an den Inhaber (DPoP, mTLS). | Missbrauch innerhalb der TTL verhindern. | Das TTL-Fenster. | | T6 Freigabemüdigkeit und Durchwinken | Seltene Gates; das NAS stellt den Diff selbst dar; Freigaben sind an einen Digest gebunden; die Freigabequote wird überwacht. | Menschen zum genauen Hinsehen bringen. | Menschliches Versagen. | | T7 Manipulation des Protokolls | Hash-Kette; optionale externe Verankerung. | Ohne Verankerung verhindern, dass root das Protokoll zerstört. | Ein böswilliger Administrator. | | T8 Datenabfluss (Egress, Teilen, Suchergebnisse) | Egress braucht eine Lease-Aktion und ein Gate; `secret` darf nicht hinaus; Ableitungen erben Labels. | Lecks nach der Freigabe durch einen Menschen verhindern; verdeckte Kanäle. | Lecks nach der Freigabe. | | T9 Lieferkette (Skills, MCP-Server, Plugins, Modelle) | Der Inhalt von Skills und externen MCP-Servern gilt als `external`; ein Skill-Verzeichnis lässt sich an einen Commit anheften; das Laufzeit-Manifest wird ins Protokoll geschrieben. | Garantieren, dass Fremdcode harmlos ist. | Eine angeheftete bösartige Version. | | T10 Ressourcenerschöpfung (Branch-Bomben, aufgebrauchte Budgets, Leseschleifen) | Kontingente; TTLs; Budgets; Sicherungen (Circuit Breaker). | Eine legitime große Aufgabe von einer außer Kontrolle geratenen unterscheiden. | Lokale Dienstverweigerung. | ## Schutzmaßnahmen - **Richtlinien-Engine:** deterministisch (im Stil von Cedar oder Rego), standardmäßig verweigernd, und bei Ablehnung nennt sie einen lesbaren Grund und die zutreffende Regel; sie **ruft kein LLM auf**. - **Credential Broker:** Langlebige Schlüssel bleiben beim Broker; er stellt einer Ausführung nur innerhalb einer genehmigten Egress-Aktion kurzlebige nachgelagerte Tokens aus. - **Isolation und Schlüssel:** ein Home und ein Pfadraum pro Rolle; die Aufbewahrungsklasse `sensitive` nutzt eine eigene Schlüsseldomäne. - **Lieferkette:** Der Inhalt von Skills, MCP-Servern und Plugins gilt als `external`; zu Beginn einer Ausführung werden die verwendeten Skills und Versionen ins Protokoll geschrieben. ## Ehrliche Grenzen 1. Das ist **keine** Abwehr gegen Prompt Injection. Es begrenzt die Folgen und macht sie sichtbar. 2. Legitime Berechtigungen innerhalb einer Lease können weiterhin missbraucht werden. 3. Gegen Nebenwirkungen außerhalb des NAS kann es nichts tun: eine bereits gesendete E-Mail, eine bereits aufgerufene API. 4. Verdeckte Kanäle und Seitenkanäle liegen außerhalb des Umfangs. 5. Ist die TCB kompromittiert, versagen die Garantien. 6. Menschen machen Fehler: Gates senken dieses Risiko, können es aber nicht beseitigen. 7. Die Kontamination ist konservativ und bringt Reibung und Fehlalarme; sie braucht Feinabstimmung und sichtbare Ablehnungsgründe. 8. Kryptografisches Löschen schützt nur die Kopien, die wir kontrollieren. ## Reaktion auf Vorfälle - **Sicherung (Circuit Breaker):** `revoke_run` und `revoke_role` widerrufen Leases sofort und frieren den Branch ein. - **Rollback:** den betroffenen Tree auf einen früheren Commit zurücksetzen. - **Spurensuche:** Mit dem Lesemanifest und der Record-Kette lässt sich herausfinden, was eine Ausführung gelesen und geschrieben hat und welche Notizen sie berührt hat. - **Aufräumen:** Mit [Cascade Forget](https://agentnas.com/de/concepts/cascade-forget/) lassen sich die betroffenen Ableitungen löschen, und es wird ein Bericht ausgestellt. ## Beobachtbarkeit und Prüfpfad - **Drei Arten von Daten:** das Protokoll (Ereignisse), das Lesemanifest (die Menge der Eingaben) sowie Metriken und Traces. - **`explain(commit)`:** liefert, welche Ausführung und welche Lease einen Commit erzeugt haben, welche Gates er passiert hat, was gelesen wurde und von welchen Eingaben er abhängt. - **Einbindung in vorhandene Observability:** Eine Ausführung entspricht einem OpenTelemetry-GenAI-Span, Leases und Gates hängen als Ereignisse daran; Records lassen sich als JSON Lines exportieren oder an ein SIEM leiten. - **Metriken:** Raten der Lease-Ausstellung und -Ablehnung; Länge der Gate-Warteschlange, Freigabequote und Freigabelatenz; Anzahl und Alter der Branches; Aktualität der Indizes; Budgetverbrauch; Ergebnisse der Prüfung der Record-Kette. - **Datenschutz und Aufbewahrung:** Standardmäßig werden nur Metadaten aufgezeichnet, nie Inhalte; die Aufbewahrung von Records und das Löschen von Inhalten sind voneinander unabhängig; schon das Lesen des Protokolls selbst braucht eine Lease. --- Kanonische URL: https://agentnas.com/de/security/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Anwendungsfälle > Jedes Szenario geht von etwas aus, das Menschen schon tun, und zeigt, welchen Schritt Agent NAS verändert, welche Konformitätsstufe es braucht und was sich heute schon bauen lässt. ## Ein Agent, der über Nacht läuft Vor dem Schlafengehen geben Sie einem Agenten eine Aufgabe: die Release Notes aufräumen. Er arbeitet auf einem eigenen Branch; am Morgen sehen Sie auf dem Smartphone eine Gate Card: 4 Dateien, den echten Diff und die Quellen, die er gelesen hat. Geben Sie frei, wird gemergt; lehnen Sie ab, wird der Branch verworfen, und die Hauptlinie bleibt unberührt. - **Verwendete Konzepte:** [Agent Branch](https://agentnas.com/de/concepts/agent-branch/), [Capability Lease](https://agentnas.com/de/concepts/capability-lease/), [Human Gate](https://agentnas.com/de/concepts/human-gate/). - **Konformität:** L0 bis L1. - **Heute baubar:** ein Git-Worktree, ein geschützter `main` und eine Push-Benachrichtigung. ## Das Framework wechseln, das Gedächtnis behalten Sie ziehen einen Agenten von einer Laufzeitumgebung in eine andere um. Sein Home ist ein Verzeichnis nach offenen Konventionen: `AGENTS.md`, `skills/`, `memory/notes/`. Die neue Laufzeitumgebung liest dasselbe Verzeichnis; was sich nur verlustbehaftet abbilden lässt, wird beim Import als ungeprüft markiert. - **Verwendete Konzepte:** [Agent Home](https://agentnas.com/de/concepts/agent-home/), [Agent Memory](https://agentnas.com/de/concepts/agent-memory/). - **Konformität:** L0 bis L2. - **Heute baubar:** ein Git-Verzeichnis mit einer `AGENTS.md`. ## Ein Team, mehrere Agenten, ein gemeinsamer Wissensbestand Drei Agenten schreiben in dieselbe Wissensbasis. Jeder arbeitet auf einem eigenen Branch, und Merges werden geprüft; Notizen aus einer Ausführung, die eine externe Webseite gelesen hat, kommen in Quarantäne und werden von anderen Agenten nicht automatisch geladen. Geteilt werden Notizen, keine Indizes. - **Verwendete Konzepte:** [Trust Labels](https://agentnas.com/de/concepts/trust-labels/), [Agent Memory](https://agentnas.com/de/concepts/agent-memory/), [Agent Branch](https://agentnas.com/de/concepts/agent-branch/). - **Konformität:** L0 bis L3. - **Heute baubar:** eine geschützte Hauptlinie, eine Markierung `external` auf dem Importverzeichnis und eine Regel, die nur geprüfte Notizen automatisch lädt. ## Vorfallanalyse Nach einem Merge entdecken Sie eine Seite, die falsch aussieht. `explain(commit)` sagt Ihnen, welche Ausführung, welche Lease und welches Gate entschieden haben; das Lesemanifest zeigt, dass diese Ausführung eine externe Webseite gelesen hat. Sie folgen der Provenienz zu den betroffenen Notizen, setzen zurück und stellen sie unter Quarantäne. - **Verwendete Konzepte:** [Flight Recorder](https://agentnas.com/de/concepts/flight-recorder/), [Agent Branch](https://agentnas.com/de/concepts/agent-branch/). - **Konformität:** L1. - **Heute baubar:** Git-Trailer in Commits plus eine Append-only-SQLite-Tabelle. ## Ein Kunde bittet darum, vergessen zu werden Die Daten des Kunden wurden beim Schreiben mit der Aufbewahrungsklasse `sensitive` markiert. Wenn die Anfrage eintrifft, folgt Cascade Forget der Lineage zu den Zusammenfassungen, Embeddings und Notizen, die darauf verweisen, vernichtet diese Schlüsseldomäne und stellt einen Bericht aus: was getan wurde und was nicht möglich war (Kopien außerhalb des NAS, die Logs des Modellanbieters, Modellgewichte). - **Verwendete Konzepte:** [Cascade Forget](https://agentnas.com/de/concepts/cascade-forget/), [Agent Memory](https://agentnas.com/de/concepts/agent-memory/). - **Konformität:** L3. - **Heute baubar:** Aufbewahrungsklassen, Soft Delete und das Festhalten der Eingaben jeder Ableitung. ## Eine Tür zu einer Box ergänzen, die Sie schon besitzen Sie haben bereits ein NAS. Die Einsatzform Overlay setzt ein Gateway davor und verwaltet nur ein einziges Verzeichnis. Agenten gehen über einen Mount oder die S3-Ansicht ein und aus; die Backups und Snapshots des Eigentümers bleiben außerhalb der Reichweite der Agenten. - **Verwendete Konzepte:** [Capability Lease](https://agentnas.com/de/concepts/capability-lease/), [Agent Branch](https://agentnas.com/de/concepts/agent-branch/). - **Konformität:** L0 bis L1. - **Heute baubar:** NFS oder SMB plus ein kleines Gateway, das Tokens gegen ein Pfadpräfix und eine Aktion prüft. ## Wann Sie Agent NAS nicht brauchen | Ihre Situation | Ein einfacherer Weg | | --- | --- | | Ein Agent und Daten, die Sie problemlos neu erzeugen können | Ein Git-Repository mit einer `AGENTS.md`. | | Sie wollen nur, dass ein Agent Ihr NAS verwalten hilft | Der eigene Verwaltungsagent des Herstellers. | | Sie brauchen nur forkbare Datensätze | lakeFS oder Tigris. | | Sie brauchen nur Gedächtnis-Retrieval | Irgendeine Gedächtnis-Bibliothek. | | Sie brauchen isolierte Rechenumgebungen | Eine Sandbox. | --- Kanonische URL: https://agentnas.com/de/use-cases/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Vergleich > Agent NAS soll diese Ansätze nicht ersetzen. Die meisten benachbarten Arbeiten sind gut in dem, was sie tun, und können ein Teil davon werden. Wir versuchen, ehrlich zu sagen, was übernommen ist und was wirklich neu ist. ## Die Landschaft | Kategorie | Beispiele | Was es schon leistet | Wo es aufhört | | --- | --- | --- | --- | | Verwaltungsagenten der NAS-Hersteller | QNAP QuAgent, Synology DSM Agent, TrueNAS MCP | Verwalten die Box in natürlicher Sprache; nutzen die Berechtigungen des Nutzers mit; bestätigen gefährliche Operationen doppelt; Logs. | Zielen auf „verwalten“, nicht auf „in den Daten arbeiten“; keine Leases pro Ausführung, keine Branches, kein Gedächtnisvertrag. | | Agenten-Dateisysteme und Git | Turso AgentFS, Letta Context Repositories, Cloudflare Artifacts, Redis Agent Filesystem | Legen Dateien, Zustand und Audit von Tool-Aufrufen in portablen Speicher; Git-versioniertes Gedächtnis; Git für Agenten. | Jedes ist an eine Laufzeitumgebung oder Plattform gebunden; Autorisierung, Freigabe, Kontamination und Vergessen liegen meist außerhalb. | | Forkbarer Objektspeicher und Datenversionierung | Tigris Agent Kit, lakeFS | Copy-on-Write-Forks, Checkpoints, geschützte Branches, eingegrenzte Zugangsdaten, Hooks vor dem Merge. | Zielt auf Data Lakes und Cloud-Objektspeicher; keine Gedächtnis- oder Lease-Semantik und keine Freigabe-Erfahrung für Menschen. | | Gedächtnis-Frameworks | Letta, Mem0, Zep/Graphiti, OpenClaw-Gedächtnisarchitektur | Retrieval, Konsolidierung, zeitliche Graphen; OpenClaw hat bereits Provenienz-Labels und Quarantäne. | Meist an ein Framework gebunden; Index und Wahrheit sind nicht getrennt; Migration und Löschen sind schwer. | | Sandboxes und Laufzeitumgebungen | E2B, Daytona, Vercel Sandbox | Isolierte Rechenumgebung und Snapshots. | Speicher ist nicht der Schwerpunkt; der Zustand verschwindet mit der Sandbox. | | Allzweck-Speicher | S3 und S3 Files, NFS, SMB, Git | Dauerhaft, ausgereift, mit vollständigem Ökosystem. | Kennt weder „Ausführung“ noch „Lease“ noch „Kontamination“. | **Die Lücke.** Jeder Baustein ist schon von jemandem gebaut worden. Was wir nicht sehen, ist ein **selbst gehosteter, offener, testbarer** Vertrag, der sie verbindet, mit der Ausführung als Einheit, der Branch, Lease, Freigabe, Protokoll, Gedächtnis und Vergessen zusammenbindet und dem Konformitätstests beiliegen. Wir behaupten nicht, dass niemand eines davon getan hätte; genau deshalb übernehmen wir so viel. ## Wie es sich zu benachbarten Ansätzen verhält | Ansatz | Stärke | Verhältnis zu Agent NAS | | --- | --- | --- | | QNAP QuAgent, Synology DSM Agent, TrueNAS MCP | Ein NAS in natürlicher Sprache verwalten | Ergänzend; ihre Boxen können die Grundlage eines Overlays sein. | | Turso AgentFS, Redis Agent Filesystem, LayerFS | Agenten-Dateisysteme | Können als Store-Engines dienen; Agent NAS ergänzt darüber den Vertrag. | | Letta Context Repositories | Git-gestütztes Gedächtnis | Agent Home übernimmt seine Ideen zum Aufbau; Letta kann eine Laufzeitumgebung für Agent Memory sein. | | Cloudflare Artifacts, Tigris, lakeFS | Forkbarer, versionierter Speicher | Können direkt als Store-Engines genutzt werden. | | Mem0, Zep/Graphiti | Gedächtnis-Retrieval und Konsolidierung | Können Indexer sein, also Erzeuger von Ableitungen. | | OpenClaw-Gedächtnisarchitektur | Provenienz-Labels und Quarantäne | Ein Vorläufer; wir legen dieselben Ideen in die gemeinsame Speicherschicht. | | S3, S3 Files, NFS, SMB | Allzweck-Speicher | Können als Store dienen; sie kennen weder Ausführungen noch Leases noch Kontamination. | | E2B, Daytona, Vercel Sandbox | Isolierte Rechenumgebung | Ergänzend; sie sollten zusammen genutzt werden. | ## Was wir übernommen haben - Von **Git und lakeFS:** Branches, geschützte Branches, Hooks vor dem Merge. - Von **Letta und Cursor:** Dateien sind die Schnittstelle, die Agenten am besten kennen, und Kontext sollte schrittweise offengelegt werden. - Von **OpenClaw und der Forschung zur Gedächtnissicherheit:** Provenienz darf sich nicht fälschen lassen, und nicht vertrauenswürdiges Gedächtnis kommt in Quarantäne. - Von **Metas Zweierregel, CaMeL und Fides:** Folgen außerhalb des Modells begrenzen. - Von **OAuth (RFC 8693, RFC 9396), Biscuit und UCAN:** Token Exchange und einschränkbare Autorisierung. - Von **OpenTelemetry und Certificate Transparency:** exportierbare Traces und auffindbare Manipulation. - Von **Anthropics Auto-Mode-Forschung:** Freigaben selten halten und auf Pläne und Merges legen. ## Was wirklich neu ist Wir versuchen, ehrlich zu sein. Die Liste ist kurz: 1. Die **Ausführung** als Einheit nutzen und Branch, Lease, Budget und Protokoll zusammenbinden. 2. Das **Lesemanifest** und die Sitzungskontamination: die Zweierregel an der Speichergrenze durchsetzen. 3. Gedächtnis-Schreibzugriffe, die **Provenienz und Kontamination** tragen, und die Vertrauensgrenze „nur nach Prüfung automatisch laden“. 4. **Aufbewahrungsklassen:** „wiederherstellbar“ gegenüber „vergessbar“ zu einer ausdrücklichen Entscheidung machen. 5. **Eine Konformitätsleiter mit ausführbaren Abnahmetests.** > **Ein Urteil, das sich noch bewähren muss.** Alles andere, darunter Branches, Tokens, Logs und Retrieval, ist eine Kombination vorhandener Techniken. Wir glauben, dass es einen eigenen Wert hat, sie zu einem offenen, testbaren Vertrag zu verbinden, aber das ist ein **Urteil, das sich noch bewähren muss**, keine gesicherte Tatsache. --- Kanonische URL: https://agentnas.com/de/compare/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Spezifikation > Der Spezifikationsentwurf v0.2 definiert fünf aufeinander aufbauende Konformitätsstufen, von L0 Files bis L4 Sync. Jede Stufe entspricht einer Menge von Konzepten und einer Menge ausführbarer Abnahmetests; die Behauptung „kompatibel“ ohne `conformance.json` wird nicht akzeptiert. > **Entwurf.** Es gibt noch keine Referenzimplementierung und keine lauffähige Konformitäts-Suite. Die Abnahmetests unten sind Teil der Spezifikation: Ihre Aufgabe ist es, das Wort „kompatibel“ überprüfbar zu machen. ## Bestandteile der Spezifikation | Bestandteil | Inhalt | Zielversion | | --- | --- | --- | | Core | Die sechs Kernbegriffe, der Store-Vertrag, Branches und geschützte Trees, Merges, Soft Delete. | Entwurf v0.3 | | Lease & Record | Das Lease-Format (ein Profil für `authorization_details`), das Format von Records und Lesemanifesten, `explain`. | Entwurf v0.3 | | Interfaces | Mount-Semantik, die Projektionen für Git und S3, die HTTP-API, die MCP-Tool-Oberfläche. | Entwurf v0.4 | | Memory | Notizkonventionen, Ableitungen und Rezepte, budgetiertes Lesen, Belegzeiger. | Entwurf v0.4 | | Guard | Labels, Sitzungskontamination, das Richtlinienprofil, Gate Cards, der Vergessensbericht. | Entwurf v0.5 | | Sync | Übergabepakete, Label-Schwellen, Löschmarker (Tombstones). | Später | | Conformance Suite | Ausführbare Abnahmetests für jede Stufe. | Im Gleichschritt mit jeder Version | ## Konformitätsstufen Die Stufen bauen aufeinander auf: Wer L2 beansprucht, muss auch L0 und L1 erfüllen. | Stufe | Name | Abgedeckte Konzepte | In einer Zeile | | --- | --- | --- | --- | | L0 | Files | Agent Home, Agent Branch | Ein Verzeichnis mit Verlauf. | | L1 | Authority | Flight Recorder, Capability Lease, Human Gate | Wer hat auf welcher Befugnis was getan. | | L2 | Memory | Agent Memory, Budgeted Reads | Gedächtnis, das Sie lesen und mitnehmen können. | | L3 | Guard | Trust Labels, Cascade Forget | Folgen begrenzen. | | L4 | Sync | Keine (optional) | Mehrere Knoten. | ## L0 Files: ein Verzeichnis mit Verlauf 1. Dateien in einem Run-Branch zu ändern, lässt die geschützte Hauptlinie unverändert. 2. Ein direkter Schreibzugriff auf einen geschützten Tree wird abgelehnt, auch mit gültigen Zugangsdaten. 3. Nachdem eine Datei in einem geschützten Tree gelöscht wurde, lässt sie sich aus dem Papierkorb wiederherstellen. 4. Export und anschließender Import ergeben einen byteidentischen Tree samt Verlauf. 5. Mindestens zwei Standardansichten werden angeboten: Mount und Git, oder eine davon plus S3. ## L1 Authority: wer hat auf welcher Befugnis was getan 1. Eine Anfrage ohne Lease wird abgelehnt, und die Ablehnung wird protokolliert. 2. Die Anfrage nach einer Kind-Lease, die weiter reicht als ihre Eltern-Lease, wird abgelehnt. 3. Nach Ablauf einer Lease wird der Mount schreibgeschützt; ein Widerruf wirkt innerhalb der Frist, die die Implementierung angibt. 4. Keine Lease kann einen Snapshot löschen. 5. Jeder Commit lässt sich mit `explain` auf eine Ausführung, eine Lease und ein Lesemanifest zurückführen. 6. Die Prüfung der Record-Kette gelingt; wurde ein Record manipuliert, schlägt sie fehl. 7. Beim Merge in einen geschützten Tree zeigt die Gate Card einen vom NAS berechneten Diff, und die Freigabe ist an einen Digest gebunden: Ändert sich der Diff, ist die Freigabe ungültig. ## L2 Memory: Gedächtnis, das Sie lesen und mitnehmen können 1. Nachdem alle Indizes gelöscht und neu aufgebaut wurden, bestehen die Golden-Recall-Tests. 2. Notizen lassen sich ohne die Memory-Schicht lesen. 3. Jede Ableitung trägt ein Rezept und ihre Eingaben. 4. Ein budgetiertes Lesen liefert bei zu kleinem Budget eine gröbere Ansicht und gibt an, welche Ansicht es tatsächlich geliefert hat. 5. Belegzeiger lassen sich überprüfen: Auch nachdem sich Commits geändert haben, zeigt ein Zeiger noch auf den ursprünglichen Inhalt. ## L3 Guard: Folgen begrenzen 1. Unter einer Lease mit B und C wird eine Aktion der Klasse C, die eine Sitzung auslöst, die `external`-Inhalte gelesen hat, abgelehnt oder an ein Gate übergeben. 2. Eine Ableitung erbt die Vereinigung der Labels ihrer Eingaben. 3. Notizen aus einer kontaminierten Sitzung werden nicht automatisch geladen. 4. Eine Vergessensanfrage erzeugt einen Bericht, der „was nicht abgedeckt ist“ enthält; eine Löschsperre (Legal Hold) kann das Vergessen blockieren. 5. Die Richtlinienauswertung ruft kein LLM auf: Die Richtlinien-Engine macht keine ausgehenden Aufrufe an ein Modell, sodass sie sich prüfen lässt. ## L4 Sync: mehrere Knoten 1. Nachdem zwei Knoten synchronisiert haben, sind die Trees identisch. 2. Hochsensible Objekte werden nicht an einen Knoten mit niedrigerer Vertrauensstufe gesendet. 3. Löschmarker (Tombstones) für das Vergessen werden an die Gegenstelle weitergegeben. 4. Ein Übergabepaket lässt sich auf der Gegenstelle ausführen, und Leases werden dabei nur enger. ## Das Format der Erklärung Eine Implementierung muss eine `conformance.json` veröffentlichen, die die Stufe nennt, der sie entspricht, das Ergebnis jedes Tests und alle bekannten Abweichungen. Die Behauptung „kompatibel“ ohne diese Datei wird nicht akzeptiert. *conformance.json* ```json { "implementation": "example-nas", "version": "0.1.0", "spec": "0.2", "level": "L1", "tests": { "L0.1": "pass", "L0.2": "pass", "L0.3": "pass", "L0.4": "pass", "L0.5": "pass", "L1.1": "pass", "L1.2": "pass", "L1.3": "pass", "L1.4": "pass", "L1.5": "pass", "L1.6": "pass", "L1.7": "pass" }, "deviations": ["L1.3: revocation takes effect within 60 seconds"] } ``` ## Versionen und Kompatibilität - Semantische Versionierung. Während 0.x wird keine Kompatibilität garantiert. - Neue Felder sind abwärtskompatibel. - Ein veraltetes Feld behält eine Warnfrist von mindestens einer Version. ## Was die Spezifikation noch nicht abdeckt Versionsdetails von Transportprotokollen, eine bestimmte Richtliniensprache, der Signaturalgorithmus für Tokens, bestimmte Speicher-Engines und Benutzeroberflächen. --- Kanonische URL: https://agentnas.com/de/spec/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Roadmap > Die Roadmap ist nach „jetzt“, „als Nächstes“, „später“ und „nicht geplant“ geordnet, ohne Jahresversprechen: Ein 2026 geschriebener Dreijahresplan würde schon im ersten Jahr sehr wahrscheinlich von den Tatsachen umgeschrieben. ## Jetzt, als Nächstes, später - **Jetzt (Q4 2026)** · In Arbeit · **Konzept, Spezifikationsentwurf und Website**: Das Konzept und der Spezifikationsentwurf v0.2 sowie die Website in 8 Sprachen. Feedback sammeln: 3 bis 5 echte Nutzer befragen, die `AGENTS.md` bereits mit Git kombinieren, um die Wetten B1 bis B7 zu prüfen. - **Als Nächstes (Ziel: erste Hälfte 2027)** · Als Nächstes · **Referenzimplementierung v0 und Spezifikation v0.3**: Referenzimplementierung v0 (Lite und Overlay): Backends für Git und Dateisystem-Snapshots, Lease-Ausstellung, Records und Lesemanifeste, eine CLI und eine Konformitäts-Suite für L0 bis L1; Spezifikation v0.3 (Core, Lease & Record). Ein vorführbares Szenario: Ein Agent arbeitet über Nacht auf einem Branch, und am Morgen geben Sie den Merge auf einer Gate Card frei. - **Später (abhängig vom Feedback)** · Später · **Memory, Guard, der Leitstand und Sync**: Die Memory-Schicht und die MCP-Tool-Oberfläche (L2); Guard: Labels, Kontamination und kaskadierendes Vergessen (L3); der Leitstand; die Formen Team und Cloud; Sync (L4). > **Unverbindlich.** Das ist eine Absicht, kein Versprechen. Was „kompatibel“ definiert, sind die Konformitätsstufen, nicht der Kalender. ## Das Stage Gate (was uns widerlegen würde) Die Messlatte für den Abschluss von „als Nächstes“ ist **keine** Funktionsliste. Sie lautet: eine Woche Betrieb in mindestens drei echten Arbeitsabläufen; eine Gate-Freigabequote unter 95 %; und mindestens ein echtes Problem, das abgefangen wurde. Erreichen wir sie nicht, gehen wir zurück und ändern die Konzepte, statt Funktionen anzuhäufen. ## Nicht geplant - Eine eigene Speicher-Engine. - Eine eigene Vektordatenbank. - Modell-Hosting. - Ein Skill-Marktplatz. - Tokens und Blockchains. - Eigene Hardware. ## Absichtlich offene Fragen - Wie entwickelt sich der Freitext `purpose` einer Lease zu einer strukturierten Absicht, die Maschinen prüfen können? - Wie werden semantische Merger registriert und als vertrauenswürdig eingestuft? - Soll die Granularität von Labels die Datei oder der Absatz sein? - Wie wird in mandantenfähigen Umgebungen das Label-Vokabular verwaltet? - Wie sollte die Verzögerung, mit der sich ein Widerruf zwischen Knoten ausbreitet, nach außen beschrieben werden? - Wie messen wir die Qualität des Gedächtnisses? Was ist der Regressionsmaßstab, wenn sich Modell oder Embeddings ändern? - Wie definiert Cascade Forget bei einem Fakt, der aus mehreren Quellen abgeleitet wurde, den betroffenen Bereich? - Wie werden bei hohem Durchsatz Speicherkosten und Granularität von Lesemanifesten gegeneinander abgewogen? - Was ist die beste Oberfläche für Stapel- und gestufte Reviews? Wie werden die Schwellen für automatisches Mergen gemessen und abgestimmt? - Wie werden organisationsübergreifende Vertrauensanker verteilt und widerrufen? --- Kanonische URL: https://agentnas.com/de/roadmap/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Entwurfsprinzipien > Acht Thesen leiten jede Abwägung in Agent NAS; sieben Wetten sagen, worauf es setzt und was passiert, wenn die Wette falsch ist. Ein Entwurf, der jahrelang halten soll, sollte sagen, wann er falsch liegen wird. ## 1. Die Einheit des Zugriffs ist die Ausführung, nicht das Konto Heute gibt man einem Agenten üblicherweise ein langlebiges Token oder ein Konto eines Menschen: Das Token im Vorfall vom April 2026 war „zum Verwalten von Domains gemacht, konnte aber alles“. Eine Ausführung hat einen Anfang, ein Ende, einen Zweck und einen Verantwortlichen und ist damit eine natürliche Einheit für Autorisierung und Zurechenbarkeit. *Schließt aus:* gemeinsame Schlüssel, langlebige Tokens und geliehene Konten von Menschen. ## 2. Rückgängigmachen ist billiger als Verhindern Verhinderung (Freigaben, Klassifikatoren, Regeln in Prompts) wird immer Lücken haben: Klassifikatoren übersehen etwas, Menschen sind schlechter, und Modelle brechen Grundsätze, die in ihren Prompts stehen. Fehler **umkehrbar** zu machen (Branches, Soft Delete, Snapshots) ist viel einfacher, als jede Aktion richtig zu machen, und leichter zu überprüfen. Eine Folgerung: **Der Wiederherstellungspfad muss außerhalb des Schadensradius dessen liegen, was er schützt**; deshalb liegen Snapshots beim Eigentümer und außerhalb der Macht jeder Lease. *Schließt aus:* „eine Zeile im Prompt, die um Bestätigung bittet“ als Schutzmaßnahme zu behandeln. ## 3. Befugnis wird pro Aufgabe geliehen, nicht pro Identität gewährt Eine Ausführung erhält eine enge, befristete Lease mit Budgets; langlebige Schlüssel bleiben beim Orchestrator oder beim Eigentümer, und das Modell sieht sie nie. *Schließt aus:* langlebige, weit gefasste, dauerhafte Berechtigungen. ## 4. Notizen sind die Wahrheit, Intelligenz ist Cache Gedächtnis sollten Dateien sein, die Menschen lesen und bearbeiten können; Indizes, Embeddings und Zusammenfassungen sind verwerfbare, wiederaufbaubare Ableitungen. So kann sich der Retrieval-Algorithmus ändern, ohne Gedächtnis zu verlieren, und Vergiftung und Löschen werden beherrschbar. *Schließt aus:* undurchsichtige Gedächtnisspeicher, die sich nicht einsehen oder mitnehmen lassen. ## 5. Provenienz ist das Rückgrat Jede Erinnerung, jede Ableitung und jeder Merge kann beantworten: „Woher kommt das, und was hat es beeinflusst?“. Provenienz ist die Grundlage des Prüfpfads und ebenso der Kontrolle von Vergiftung, der Vertrauenslabels und des Vergessens. *Schließt aus:* Gedächtnis ohne Provenienz. ## 6. Richtlinien sind deterministisch, und Modelle können sie nur verschärfen Autorisierungsentscheidungen trifft Code, nicht die „Meinung“ eines Modells. Ein Klassifikator oder ein LLM darf vorschlagen, dass „dieser Schritt eine Freigabe braucht“, aber nie freigeben. *Schließt aus:* ein Modell selbst entscheiden zu lassen, ob etwas durchgeht. ## 7. Speicher langweilig halten, Innovation in den Vertrag legen Keine neue Engine; zuerst Dateien, denn die Schnittstelle, die Modelle am besten kennen, ist die Datei; Protokolle werden sich ändern, die sechs Kernbegriffe nicht. *Schließt aus:* im Namen der KI eine neue Speicher-Engine zu erfinden. ## 8. Knapp sind Tokens und menschliche Aufmerksamkeit Lesen bekommt ein Budget; Freigaben sind selten und konkret und sitzen dort, wo ein Mensch wirklich urteilen kann: bei Plänen und Merges, nicht bei jeder Aktion. *Schließt aus:* standardmäßig ganze Dateien zurückzugeben; ein Pop-up für jede Aktion. ## Sieben Wetten und was sie widerlegen würde Ein Entwurf, der jahrelang halten soll, sollte sagen, worauf er setzt und wann er falsch läge. | Wette | Grundlage | Falls falsch | | --- | --- | --- | | B1 Agenten werden Dateisystem und Git weiter als wichtigstes Arbeitsmedium nutzen | Mehrere gängige Laufzeitumgebungen sind bereits auf Dateien umgestiegen. | Wechseln sie zu eigenen „Gedächtnis-APIs“, wird Agent Home zu einem Exportformat; die anderen Konzepte hängen nicht von Dateien ab und bleiben bestehen. | | B2 Die „Ausführung“ bleibt die natürliche Einheit für Autorisierung und Zurechenbarkeit | Orchestratoren starten in der Regel pro Aufgabe oder pro Sitzung Sandboxes. | Kommen langlebige autonome Prozesse auf, werden Leases zu fortlaufenden Verlängerungen mit Budgets, und das Konzept bleibt. | | B3 Prompt Injection wird auf absehbare Zeit auf Modellebene nicht beseitigt | Metas eigene Formulierung; Fehlerquoten von Klassifikatoren; mehrere Angriffsstudien. | Wird sie beseitigt, werden Trust Labels zu einer billigen zusätzlichen Verteidigungsschicht. | | B4 Menschliche Aufmerksamkeit bleibt knapp | Von Anthropic veröffentlichte Daten. | Wird Vollautomatisierung zuverlässig genug, weicht ein Human Gate einer vorab autorisierenden Richtlinie, und der Prüfpfad bleibt. | | B5 Die Speicherschicht ist der richtige Ort, um Provenienz und Kontamination durchzusetzen | Die Forschung zur Gedächtnissicherheit betont Provenienz beim Schreiben; OpenClaw hat dasselbe innerhalb einer Laufzeitumgebung getan. | Wenn jede Laufzeitumgebung das selbst gut macht, muss das NAS nur noch Labels speichern, und seine Rolle wird dünner. | | B6 Gedächtnis, das über Laufzeitumgebungen und Agenten hinweg geteilt wird, wird zu einem echten Bedarf | Zusammenarbeit mehrerer Agenten; die Kosten eines Framework-Wechsels. | Bleibt Gedächtnis ein privates Merkmal jedes Frameworks, liegt der Wert von Agent Memory vor allem in der Portabilität für Einzelne und kleine Teams. | | B7 Protokolle werden sich ändern, aber „Dateien plus Tools“ als zwei Anschlüsse bleiben stabil | Versionswechsel bei MCP; A2A 1.0. | Die Adapter austauschen; deshalb isolieren Adapter die Protokolle. | ## Was voraussichtlich stabil bleibt und was sich ändern wird | Voraussichtlich stabil | Voraussichtlich veränderlich | | --- | --- | | Die sechs Kernbegriffe | Konkrete Protokolle und Transporte | | Die Verzeichniskonvention eines Home | Embedding-Modelle und Retrieval-Algorithmen | | Die vier Versprechen | Token-Formate | | Die Garantie „Export heißt Ausstieg“ | Agenten-Frameworks und Mensch-Computer-Schnittstellen | --- Kanonische URL: https://agentnas.com/de/principles/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # FAQ > Antworten auf die Fragen, die zu Agent NAS zuerst gestellt werden: was es ist, wie es sich von vorhandenen Speicher- und Gedächtnis-Werkzeugen unterscheidet, wie es mit Sicherheit und Datenschutz umgeht und wo das Projekt steht. ## Die Grundlagen ### Was ist Agent NAS? Agent NAS ist Netzwerkspeicher, der um die Ausführung herum gebaut ist: Jede Ausführung eines Agenten arbeitet in einem isolierten Branch und greift über eine kurzlebige, enge Lease auf Daten zu; jede Änderung lässt sich nachverfolgen und rückgängig machen; und das Gedächtnis sind gewöhnliche Dateien mit Provenienz. Bereitgestellt wird es über Mounts, Git, S3 und MCP. ### Ist Agent NAS ein Produkt, das ich kaufen oder herunterladen kann? Noch nicht. Es ist derzeit ein Konzept mit einem Spezifikationsentwurf (v0.2, November 2026). L0 und L1 lassen sich schon heute aus vorhandenen Bausteinen bauen; Ziel für die Referenzimplementierung v0 ist die erste Hälfte 2027, und der Plan danach steht in der [Roadmap](https://agentnas.com/de/roadmap/). ### Wie unterscheidet es sich von den KI-Agenten, die NAS-Hersteller ausliefern? Die Agenten von Herstellern wie QNAP, Synology und TrueNAS verwalten die Box. Agent NAS legt fest, wie andere Agenten mit den Daten in der Box arbeiten: Branches, Leases, Gedächtnis und Vergessen. Beides ergänzt sich; siehe den [Vergleich](https://agentnas.com/de/compare/). ### Wie unterscheidet es sich von einer Vektordatenbank oder einem Gedächtnis-Framework? Das sind Werkzeuge für Retrieval und Konsolidierung, während die Wahrheit in Agent NAS aus gewöhnlichen Notizen mit Provenienz besteht. Ein Vektorspeicher oder Gedächtnis-Framework kann als Indexer unter [Agent Memory](https://agentnas.com/de/concepts/agent-memory/) sitzen, und der Index lässt sich jederzeit verwerfen und neu aufbauen. ### Ist es Open Source? Die Spezifikation und diese Website stehen unter CC BY 4.0. Die Referenzimplementierung soll als Open Source unter Apache-2.0 erscheinen. ## Entwurf und Sicherheit ### Warum Dateien und Git statt einer Datenbank? Agenten nähern sich bei Dateien an: Anweisungen in `AGENTS.md`, Skills in `SKILL.md`, Gedächtnis als Markdown, Verlauf in Git. Jedes Werkzeug und jedes Modell kann Dateien lesen, sie lassen sich leicht vergleichen und leicht mitnehmen. Datenbanken und Indizes werden weiterhin genutzt, aber als abgeleitete Schicht, die sich neu aufbauen lässt. ### Was ist das Schlimmste, das passieren kann, wenn eine Ausführung schiefgeht? Im schlimmsten Fall geht ein verwerfbarer Branch verloren: Die geschützte Hauptlinie ändert sich nur durch geprüfte Merges, Löschen ist ein Soft Delete, und Snapshots liegen außerhalb jeder Lease. Das gilt, wenn der Fehler innerhalb des NAS passiert; eine bereits gesendete E-Mail oder eine bereits aufgerufene externe API kann das NAS nicht rückgängig machen. ### Wie verhält sich eine Lease zu einem OAuth-Token? Eine Lease ist ein OAuth-Access-Token: angefordert per Token Exchange (RFC 8693) und mit Rich Authorization Requests (RFC 9396) beschrieben durch Pfade und Aktionen. Agent NAS ergänzt die Konvention auf Ebene der Ausführung, einschließlich Branches, Budgets und der Eigenschaften der Zweierregel. Siehe [Capability Lease](https://agentnas.com/de/concepts/capability-lease/). ### Warum „Notizen plus Cache“ für das Gedächtnis? Damit es sich einsehen, korrigieren, mitnehmen und vergessen lässt. Notizen sind Dateien; Indizes, Embeddings und Zusammenfassungen werden mit einem dokumentierten Rezept daraus berechnet. Wechseln Sie das Embedding-Modell, rechnet das System im Hintergrund neu. Notizen aus einer kontaminierten Sitzung kommen zuerst in Quarantäne und werden erst nach einer Prüfung automatisch geladen. ### Kann Agent NAS Prompt Injection stoppen? Nein. Nichts außerhalb des Modells kann sie vollständig stoppen. Agent NAS begrenzt, was ein manipulierter Agent tun kann: [Trust Labels](https://agentnas.com/de/concepts/trust-labels/) verhindern, dass eine Sitzung, die externe Inhalte gelesen hat, zugleich sensible Daten und einen ausgehenden Kanal hält, und folgenreiche Aktionen brauchen ein [Human Gate](https://agentnas.com/de/concepts/human-gate/). Die ehrlichen Grenzen stehen auf der Seite [Sicherheit](https://agentnas.com/de/security/). ### Wie geht es mit dem „Recht auf Vergessenwerden“ um? Über [Cascade Forget](https://agentnas.com/de/concepts/cascade-forget/): Es löscht entlang der Lineage Zusammenfassungen, Embeddings und Notizen, die aus einer Quelle abgeleitet wurden, behandelt den Verlauf nach Aufbewahrungsklasse und vernichtet Schlüssel für die Klasse `sensitive` (kryptografisches Löschen). Sein Bericht listet ausdrücklich auf, was es nicht abdecken kann: Kopien außerhalb des NAS, Logs des Modellanbieters und Modellgewichte. Ein Modell etwas vergessen lassen kann es nicht. ### Muss ich MCP verwenden? Nein. MCP ist nur eine der Schnittstellen der Steuerungsebene; Dateien, Git und S3 brauchen es nicht, und die Protokollschicht ist so entworfen, dass sie sich austauschen lässt. ## Einführung und Zukunft ### Ersetzt es mein bestehendes NAS oder meinen Cloud-Speicher? Nein. Die Einsatzform Overlay setzt ein Gateway vor ein vorhandenes NAS, einen Objektspeicher oder einen Git-Host und verwaltet darin nur ein einziges Verzeichnis oder einen Bucket. Auch Cloud-Speicher kann als Store dienen. ### Mit welchen Agenten-Frameworks und Laufzeitumgebungen funktioniert es? Mit jeder Laufzeitumgebung, die ein Verzeichnis einbinden oder Git, S3 oder MCP nutzen kann. Der Aufbau eines Agent Home folgt offenen Konventionen (`AGENTS.md`, Agent Skills, Markdown mit YAML-Frontmatter); Claude Code, Cursor, Codex, OpenHands, LangGraph und selbstgebaute Frameworks kommen alle infrage. ### Kann ich jederzeit gehen? Ja. Alles lässt sich als gewöhnliche Dateien und Git-Verlauf exportieren. Das ist eines der vier Versprechen, kein Feature. ### Wann sollte ich Agent NAS nicht verwenden? Wenn Sie einen Agenten haben und Daten, die Sie problemlos neu erzeugen können: Ein Git-Repository mit einer `AGENTS.md` genügt. Weitere Fälle stehen unter [Anwendungsfälle](https://agentnas.com/de/use-cases/). ### Wie zitiere ich es oder wirke mit? Jede Seite nennt ihre kanonische URL und einen Zitiervorschlag. Um mitzuwirken, eröffnen Sie ein Issue oder starten Sie eine Diskussion auf GitHub. Einzelheiten stehen auf der Seite [Über das Projekt](https://agentnas.com/de/about/). --- Kanonische URL: https://agentnas.com/de/faq/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Glossar > Dieses Glossar definiert jeden Begriff, den Agent NAS verwendet: die neun benannten Konzepte und das ergänzende Vokabular. Die Namen der Konzepte sind geprägte Begriffe und bleiben in jeder Sprache englisch. ## Die neun Konzepte - **[Agent Home (Home-Verzeichnis)](https://agentnas.com/de/concepts/agent-home/)**: **Ein Agent Home** ist ein Verzeichnis pro Rolle, mit Verlauf: Anweisungen, Skills, Gedächtnis, Journal und Arbeitsbereich, alles als gewöhnliche Dateien. Jede Laufzeitumgebung kann es betreten, und Sie können alles mitnehmen, wenn Sie gehen. - **[Agent Branch (Agentenzweig)](https://agentnas.com/de/concepts/agent-branch/)**: **Ein Agent Branch** lässt jede Ausführung auf einem Copy-on-Write-Branch arbeiten. Änderungen erreichen die geschützte Hauptlinie nur durch einen geprüften Merge (einen Agent PR), und Sie können jederzeit Checkpoints setzen und wiederherstellen. - **[Flight Recorder (Flugschreiber)](https://agentnas.com/de/concepts/flight-recorder/)**: **Ein Flight Recorder** ist ein Append-only-Protokoll, per Hash verkettet und pro Ausführung geführt: was die Ausführung gelesen hat (das Lesemanifest), was sie geschrieben hat, was erlaubt oder verweigert wurde und wer was freigegeben hat. Er liegt neben den Daten und beantwortet eine Frage: „Was kann diese Änderung beeinflusst haben?“ - **[Capability Lease (befristete Berechtigung)](https://agentnas.com/de/concepts/capability-lease/)**: **Eine Capability Lease** ist eine Autorisierung für bestimmte Daten und bestimmte Operationen, mit ausdrücklichem Ablauf und Budgets. Sie wird **einer Ausführung** ausgestellt und ist der einzige Weg, auf dem eine Ausführung das NAS berührt. Eine Kind-Lease kann nur enger sein als ihre Eltern-Lease. - **[Human Gate (menschliche Freigabe)](https://agentnas.com/de/concepts/human-gate/)**: **Ein Human Gate** ist ein durch Richtlinien ausgelöster Kontrollpunkt: Bevor eine **unumkehrbare, nach außen gerichtete oder rechteerweiternde** Aktion wirksam wird, gibt ein Mensch (oder ein benannter Freigeber) eine vollständig dargestellte, konkrete Aktion frei. Es ist so entworfen, dass es selten, konkret und schwer durchzuwinken ist. - **[Trust Labels (Vertrauenslabels)](https://agentnas.com/de/concepts/trust-labels/)**: **Trust Labels** sind zwei sehr kleine Label-Mengen an den Daten, **Herkunft** (`owner`, `agent`, `external`) und **Sensibilität** (`public`, `private`, `secret`), plus **Sitzungskontamination**. Das NAS setzt die Zweierregel als Sitzungs-Invariante durch: Eine Sitzung kann nicht zugleich [A] externe Inhalte gelesen haben, [B] sensible Daten berühren und [C] geschützten Zustand ändern oder nach außen kommunizieren. Das Vervollständigen des Dritten braucht ein [Human Gate](https://agentnas.com/de/concepts/human-gate/). - **[Agent Memory (Agentengedächtnis)](https://agentnas.com/de/concepts/agent-memory/)**: **Agent Memory** = **Notizen, die Sie lesen und bearbeiten können** + **Indizes, die Sie jederzeit wegwerfen können**. Jede Notiz nennt ihre Quellen; Indizes (Volltext, Vektor, Graph, Gliederung) sind nur Ableitungen der Notizen; und Wartungsjobs im Hintergrund **schlagen** Änderungen nur **vor** und schreiben das rohe Journal nie um. - **[Budgeted Reads (budgetiertes Lesen)](https://agentnas.com/de/concepts/budgeted-reads/)**: **Budgeted Reads** sind Lesezugriffe, die in einem Token-Budget gemessen werden: Dieselbe Datei lässt sich in unterschiedlicher Detailtiefe lesen, von der Gliederung und dem Abschnitt bis zum Zeilenbereich und dem vollen Text. Der Agent bittet um „die beste Ansicht, die in N Token passt“ und erhält Belegzeiger auf die genaue Quelle zurück. - **[Cascade Forget (kaskadierendes Vergessen)](https://agentnas.com/de/concepts/cascade-forget/)**: **Cascade Forget** ist Löschen entlang der Lineage: Wird eine Quelle gelöscht oder bittet jemand darum, vergessen zu werden, findet das NAS alles, was daraus abgeleitet wurde, darunter Zusammenfassungen, Embeddings, Notizen, die darauf verweisen, Caches und Links zum Teilen, löscht es oder leitet es ohne diese Quelle neu ab und stellt einen **Bericht** aus: was getan wurde und was nicht möglich war. ## Ergänzende Begriffe - **Principal (Subjekt)**: Eine Entität, die authentifiziert und zur Verantwortung gezogen werden kann: ein Mensch, ein Agent, ein Dienst oder ein Knoten. - **Run (Ausführung)**: Eine Ausführung mit Anfang, Ende, Zweck und einem Verantwortlichen. Eine Ausführung hält eine Wurzel-Lease und besitzt einen Branch. - **Protected tree (geschützter Tree)**: Ein Tree, der nur durch einen geprüften Merge aktualisiert werden kann und nie direkte Schreibzugriffe annimmt, zum Beispiel `main`. - **Read manifest (Lesemanifest)**: Die aggregierte Aufzeichnung der Pfade, Commits, Bereiche und Inhalts-Hashes, die eine Ausführung gelesen hat. Der Inhalt selbst ist nicht enthalten. - **Evidence pointer (Belegzeiger)**: Ein überprüfbarer Verweis der Form `nas:////@#L12-L18` auf bestimmte Zeilen eines Commits. - **Derived data (abgeleitete Daten)**: Daten, die nach einem Rezept aus Notizen berechnet werden, etwa ein Index, ein Embedding oder eine Zusammenfassung. Sie lassen sich verwerfen und neu aufbauen. - **Recipe (Rezept)**: Alles, was nötig ist, um ein abgeleitetes Objekt zu erzeugen: das Modell samt Version, den Chunker und die Parameter. - **Lineage (Abstammung)**: Der Abhängigkeitsgraph zwischen abgeleiteten Objekten und den Eingaben, aus denen sie berechnet wurden. - **Session taint (Sitzungskontamination)**: Die Vereinigung der Labels von allem, was eine Sitzung gelesen hat. Sie wächst innerhalb einer Sitzung nur und bestimmt, was die Sitzung als Nächstes tun darf. - **Rule of Two (Zweierregel)**: Eine Heuristik von Meta: Solange Prompt Injection nicht verlässlich gelöst ist, sollte eine Sitzung höchstens zwei der drei Eigenschaften haben: [A] sie verarbeitet nicht vertrauenswürdige Eingaben, [B] sie greift auf sensible Daten zu, [C] sie ändert Zustand oder kommuniziert nach außen. - **Declassification (Deklassifizierung)**: Das Absenken der Vertraulichkeit oder das Anheben des Vertrauens in die Herkunft von Daten. Nur durch ein Human Gate oder eine schemavalidierte strukturierte Übergabe. - **Policy envelope (Richtlinienrahmen)**: Ein vom Eigentümer im Voraus festgelegter Bereich, innerhalb dessen Leases automatisch ausgestellt werden. Was darüber hinausgeht, läuft über ein Human Gate. - **Credential Broker (Zugangsdaten-Broker)**: Eine Komponente, die langlebige Geheimnisse verwahrt und kurzlebige nachgelagerte Tokens nur für genehmigte Egress-Aktionen ausstellt. Modelle und Ausführungen sehen langlebige Geheimnisse nie. - **Agent PR (Pull Request eines Agenten)**: Ein strukturierter Vorschlag, einen Branch in ein Ziel zu mergen, mit Diff, Provenienz, Prüfergebnissen und einer Zusammenfassung der Labels. - **Retention class (Aufbewahrungsklasse)**: Eine von `scratch`, `normal` oder `sensitive`, beim Schreiben gewählt. Sie bestimmt Backups, Verlauf und ob Daten vernichtet werden können. - **Crypto-shredding (kryptografisches Löschen)**: Das Zerstören eines Schlüssels, sodass jede damit verschlüsselte Kopie unlesbar wird. - **Conformance level (Konformitätsstufe)**: Eine Stufe von L0 bis L4. Jede entspricht einer Menge von Konzepten und einer Menge ausführbarer Abnahmetests. - **MCP**: Model Context Protocol: ein offenes Protokoll zwischen Agenten und Werkzeugen oder Datenquellen. - **A2A**: Agent2Agent-Protokoll: ein offenes Protokoll, mit dem Agenten bei Aufgaben zusammenarbeiten. --- Kanonische URL: https://agentnas.com/de/glossary/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Über das Projekt > agentnas.com ist die Heimat des Konzepts Agent NAS und seines Spezifikationsentwurfs. Es ist ein offenes Projekt, das Menschen und Agenten ein gemeinsames Vokabular geben will, dazu einen testbaren Vertrag, dem mehrere unabhängige Implementierungen folgen können. ## Stand Im November 2026 ist Agent NAS ein Konzept mit einem Spezifikationsentwurf (v0.2). Es gibt noch keine Referenzimplementierung und keine lauffähige Konformitäts-Suite. v0.2 ist eine Überarbeitung auf den Boden der Tatsachen: Dreizehn Konzepte wurden auf neun reduziert, und jedes sagt, wie man klein anfängt und wo seine ehrlichen Grenzen liegen. Diese Website ist das Erste, was das Projekt veröffentlicht hat. Den Plan finden Sie in der [Roadmap](https://agentnas.com/de/roadmap/). ## Lizenz Text und Diagramme dieser Website und der Spezifikation stehen unter [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/): teilen und bearbeiten, solange Sie die Quelle nennen. Die Referenzimplementierung soll unter Apache-2.0 veröffentlicht werden. ## So zitieren Sie Bitte zitieren Sie die Seite, die Sie genutzt haben, und geben Sie nach Möglichkeit ihre Definition wörtlich wieder. Jede Seite endet mit ihrer kanonischen URL und einem Zitiervorschlag. So zitieren Sie das Projekt als Ganzes: *Zitat* ```text Agent NAS project. „Agent NAS: Netzwerkspeicher für KI-Agenten.“ Spezifikation v0.2 (Entwurf), November 2026. https://agentnas.com/de/what-is-agent-nas/ ``` *BibTeX* ```bibtex @misc{agentnas2026, title = {Agent NAS: Netzwerkspeicher für KI-Agenten}, author = {{Agent NAS project}}, year = {2026}, howpublished = {Spezifikation v0.2 (Entwurf)}, url = {https://agentnas.com/de/what-is-agent-nas/} } ``` ## Governance - **Spezifikation und Implementierungen sind getrennt.** Viele Implementierungen sind willkommen; was „kompatibel“ definiert, sind die Konformitätstests und `conformance.json`, keine Marke. - **Verfahren.** Öffentliche Vorschläge (Issues und PRs); wesentliche Änderungen müssen Motivation, Belege und Gegenbeispiele nennen. - **Name.** „Agent NAS“ ist ein beschreibender Name für das Konzept; wer eine Konformitätsstufe beansprucht, muss eine `conformance.json` veröffentlichen. - **Widerspruch ist willkommen.** Einwände gegen jede These sind wertvoll, besonders gegen die [sieben Wetten](https://agentnas.com/de/principles/). ## Mitmachen Korrekturen, Kritik und Hinweise zur Implementierung sind willkommen. Eröffnen Sie ein Issue oder eine Diskussion im [Projekt-Repository](https://github.com/xwzy/agentnas.com). Diese Website veröffentlicht keine E-Mail-Adresse; Sicherheitsmeldungen zur Spezifikation nutzen denselben Kanal. ## Für Agenten und Crawler - Jede Seite hat einen Markdown-Zwilling: Hängen Sie `index.md` an die URL an oder senden Sie `Accept: text/markdown`. - [/llms.txt](https://agentnas.com/llms.txt) ist ein kuratierter Index, und [/llms-full.txt](https://agentnas.com/llms-full.txt) ist der vollständige Text. - Ein MCP-Server für diese Dokumentation läuft unter `https://agentnas.com/mcp`, beschrieben in seiner [Server Card](https://agentnas.com/mcp/server-card). - Ein Suchendpunkt, `POST /api/search`, ist in [/openapi.json](https://agentnas.com/openapi.json) beschrieben. - Der [AI Catalog](https://agentnas.com/.well-known/ai-catalog.json) und die [Sitemap](https://agentnas.com/sitemap.xml) listen alles auf. - Die Inhalte dürfen frei indexiert, zitiert und als Antwortgrundlage verwendet werden. Siehe [/robots.txt](https://agentnas.com/robots.txt). --- Kanonische URL: https://agentnas.com/de/about/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Agent Home (Home-Verzeichnis) *Ein Verzeichnis pro Rolle, mit Verlauf. Gewöhnliche Dateien, die Sie mitnehmen können.* > **Ein Agent Home** ist ein Verzeichnis pro Rolle, mit Verlauf: Anweisungen, Skills, Gedächtnis, Journal und Arbeitsbereich, alles als gewöhnliche Dateien. Jede Laufzeitumgebung kann es betreten, und Sie können alles mitnehmen, wenn Sie gehen. **AN-01** · Konformitätsstufe: L0 Files · Gruppe: Arbeit ## Das Problem Der Zustand eines Agenten verteilt sich auf Framework-Datenbanken, beim Anbieter gehostete Gedächtnis-APIs und Sandbox-Datenträger, die jederzeit verschwinden können. Wechseln Sie Framework oder Anbieter, geht der Zustand verloren; wenn etwas schiefläuft, gibt es keinen einzelnen Ort, an dem man sehen kann, was der Agent tatsächlich weiß. Zugleich nähern sich gängige Agenten den Dateien an: `AGENTS.md`, Agent Skills, Git-gestützte Gedächtnis-Repositories. Es fehlt nicht ein neues Format, sondern ein Ort dafür mit **einem Eigentümer, Verlauf, Kontingenten und garantiertem Export**. ## So funktioniert es - **Der Aufbau folgt offenen Konventionen.** `AGENTS.md`, das `SKILL.md` von Agent Skills und Markdown mit YAML-Frontmatter, wie in der Skizze unten. Wir erfinden kein Format. - **Ein Home gehört zu einer Rolle, nicht zu einer einzelnen Ausführung.** Ausführungen nutzen es über [Branches](https://agentnas.com/de/concepts/agent-branch/): Änderungen landen zuerst auf einem Branch und werden nach einer Prüfung ins Home zurückgemergt. - **Es hat einen Verlauf.** Jede Änderung ist ein Commit. `nas export` oder `git clone` nimmt das ganze Home mit, einschließlich der Klartext-Metadaten in `.nas/`. - **Der Startkontext ist nur das Lesen einiger Dateien:** `AGENTS.md`, `memory/MEMORY.md` und eine Zusammenfassung des Posteingangs. Es gibt kein besonderes Aufwach-Protokoll; ein NAS kann der Bequemlichkeit halber eine auf Token begrenzte Ansicht `briefing` anbieten, sie ist aber nicht erforderlich. - **Nur geprüfte Notizen werden automatisch geladen.** Nur Notizen mit der Markierung `reviewed` gelangen in `MEMORY.md` und in den automatisch geladenen Kontext; siehe [Trust Labels](https://agentnas.com/de/concepts/trust-labels/) und [Agent Memory](https://agentnas.com/de/concepts/agent-memory/). - **Lebenszyklus.** Anlegen aus einer Vorlage, Kontingente, Archivierung und Ruhestand, mit einem Erben, der beim Ruhestand benannt werden kann. ## Klein anfangen - Legen Sie ein Verzeichnis mit `AGENTS.md`, `skills/` und `memory/` an und führen Sie `git init` aus. Verlinken Sie `CLAUDE.md` und ähnliche Dateien per Symlink auf `AGENTS.md`. - Führen Sie vor jeder Ausführung `git worktree add` aus, damit sie in ihrem eigenen Arbeitsverzeichnis arbeitet. - Das ist L0: Ohne jede Agent-NAS-Software haben Sie bereits ein Home mit Verlauf, das Sie mitnehmen können. ## Schnittstellenskizze Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern. *layout* ```text /agents/cleo/ # a role's Home: it belongs to the role, not to one run ├── AGENTS.md # instructions (open convention) ├── skills/ # Agent Skills: one directory per skill │ └── release-notes/SKILL.md ├── memory/ │ ├── MEMORY.md # reviewed core memory: auto-loaded, token-capped │ ├── notes/ # notes: Markdown + YAML frontmatter │ ├── journal/ # raw log: append-only │ └── quarantine/ # unreviewed notes: recallable, never auto-loaded ├── inbox/ # tasks and messages received ├── outbox/ # deliverables and replies ├── workspace/ # scratch space (retention class: scratch) └── .nas/ # plain-text metadata: role.yaml, limits.yaml, maintenance.yaml ``` ## Was die Spezifikation verlangt - Ein Home MUSS allein aus dem Store wiederaufbaubar sein; sein Lesen DARF NICHT von abgeleiteten Daten abhängen. - Die Metadaten in `.nas/` MÜSSEN Klartext sein und MÜSSEN mit dem Home exportiert werden. - Automatisch geladener Kontext MUSS auf Token begrenzt sein und MUSS ausschließlich aus geprüften Notizen stammen. - Der Aufbau SOLLTE offenen Konventionen folgen: `AGENTS.md`, `SKILL.md`, Markdown mit YAML-Frontmatter. - Ausführungen MÜSSEN ein Home über Branches nutzen. ## Was übernommen ist und was neu ist Alles Folgende ist übernommen, und **sehr wenig ist neu**: Aufbau und Git gibt es bereits. Neu ist nur, das Home als Objekt erster Klasse mit Kontingenten, Erben und Exportgarantie zu behandeln und die Vertrauensgrenze zu setzen, dass nur geprüfte Notizen automatisch geladen werden. - [AGENTS.md](https://agents.md) - [Agent Skills](https://agentskills.io/specification) - [Letta Context Repositories](https://www.letta.com/blog/context-repositories/) - [Turso AgentFS](https://github.com/tursodatabase/agentfs) - [Cloudflare Artifacts](https://blog.cloudflare.com/artifacts-git-for-agents-beta/) ## Ehrliche Grenzen - Die nativen Gedächtnisformate unterscheiden sich zwischen Frameworks, daher ist die Abbildung auf die Home-Konventionen verlustbehaftet. - Es hilft nur, wenn Laufzeitumgebungen bereit sind, diese Dateien zu lesen und zu schreiben. - Verborgener Zustand auf der Anbieterseite, etwa Gedächtnis in der Cloud eines Anbieters, lässt sich nicht herüberholen. ## Offene Fragen - Wie lassen sich die Formate verschiedener Frameworks in beide Richtungen auf das Home abbilden? - Wie bleiben Last und Latenz beim Start bei einem sehr großen Home beherrschbar? ## Fragen ### Ist ein Agent Home nur ein Git-Repository? Im Wesentlichen ja, und absichtlich: Sie können es einfach mit `git clone` holen. Der Unterschied ist, dass es zusätzlich einen Eigentümer (eine Rolle), Kontingente, einen Erben, eine Exportgarantie und die Regel hat, dass nur geprüfte Notizen automatisch geladen werden, und dass das NAS dies durchsetzt, statt es bei einer Konvention zu belassen. ### Verliere ich das Gedächtnis, wenn ich das Agenten-Framework wechsle? Nein, solange die neue Laufzeitumgebung bereit ist, die Dateien zu lesen. Ein Home nutzt offene Konventionen: `AGENTS.md`, `SKILL.md` und Markdown-Notizen hängen von keinem Framework ab. Teile, deren Abbildung verlustbehaftet ist, sollten beim Import als ungeprüft markiert werden. ### Muss ich Agent NAS installieren, um ein Home zu nutzen? Nein. Ein Git-Verzeichnis mit einer `AGENTS.md` ist ein L0-Home. Was ein NAS hinzufügt, sind Kontingente, geschützte Merges, Leases und ein Prüfpfad, kein Dateiformat. ## Verwandte Konzepte - [Agent Branch (Agentenzweig)](https://agentnas.com/de/concepts/agent-branch/): Jede Ausführung arbeitet auf einem Copy-on-Write-Branch. Nur ein geprüfter Merge erreicht die Hauptlinie. - [Agent Memory (Agentengedächtnis)](https://agentnas.com/de/concepts/agent-memory/): Notizen, die Sie lesen und bearbeiten können, sind die Wahrheit. Indizes sind ein Cache, den Sie wegwerfen können. - [Capability Lease (befristete Berechtigung)](https://agentnas.com/de/concepts/capability-lease/): Eine enge Autorisierung für eine Ausführung, mit Ablauf und Budgets. Kind-Leases können nur enger sein. --- Kanonische URL: https://agentnas.com/de/concepts/agent-home/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Agent Branch (Agentenzweig) *Jede Ausführung arbeitet auf einem Copy-on-Write-Branch. Nur ein geprüfter Merge erreicht die Hauptlinie.* > **Ein Agent Branch** lässt jede Ausführung auf einem Copy-on-Write-Branch arbeiten. Änderungen erreichen die geschützte Hauptlinie nur durch einen geprüften Merge (einen Agent PR), und Sie können jederzeit Checkpoints setzen und wiederherstellen. **AN-02** · Konformitätsstufe: L0 Files · Gruppe: Arbeit ## Das Problem Agenten machen Fehler in Maschinengeschwindigkeit, und gemeinsame Daten bieten keine Möglichkeit, „es auszuprobieren, den Diff zu sehen, zu prüfen und rückgängig zu machen“. Parallele Agenten treten sich außerdem gegenseitig auf die Füße. Bei einem Vorfall im April 2026 löschte ein Agent mit einem zu weit gefassten Token innerhalb von 9 Sekunden ein Produktionsvolume und die Backups auf demselben Volume. Hätte er nur auf einen Branch schreiben können, wäre Löschen weich gewesen und hätten Snapshots außerhalb seiner Befugnis gelegen, wäre der Schaden weit kleiner gewesen. ## So funktioniert es - **Branches sind günstig** (je nach Engine idealerweise nahe an O(1)). Eine Lease erlaubt Schreibzugriffe **innerhalb des Branches** und `propose` in Richtung Ziel. - **Geschützte Trees.** Die Hauptlinie lässt sich nur durch einen Merge aktualisieren: Selbst abgeflossene Zugangsdaten können nicht direkt darauf schreiben. - **Agent PR.** Der Diff, die Absicht, die Provenienz (eine Zusammenfassung des Lesemanifests), Prüfergebnisse und eine Zusammenfassung der Labels. Bestehen die Prüfungen und erlaubt es die Richtlinie, wird automatisch gemergt; andernfalls geht es an ein [Human Gate](https://agentnas.com/de/concepts/human-gate/). - **Soft Delete.** Löschungen in einem geschützten Tree landen standardmäßig in einem Papierkorb und werden 7 Tage aufbewahrt; Snapshots gehören dem Eigentümer und liegen **außerhalb der Befugnis jeder Lease**. - **Checkpoints.** Benannte Snapshots; `restore` setzt Dateien auf einen Checkpoint zurück. - **Mergen.** Text nutzt einen Drei-Wege-Merge, andere Dateien werden pro Datei gemergt. Bei einem Konflikt hält er an und **überschreibt nie stillschweigend**; strukturierte Daten brauchen einen registrierten Merger oder einen Menschen. - **TTL und Kontingent,** um Branch-Bomben zu verhindern. - **Parallele Versuche.** Öffnen Sie N Branches für eine Aufgabe, mergen Sie den besten und geben Sie die übrigen in den Papierkorb. ## Klein anfangen - Git-Branches und Worktrees, dazu ein **geschützter `main`** auf Forgejo, Gitea oder GitHub. - Für große Verzeichnisse nutzen Sie btrfs- oder ZFS-Snapshots und -Clones; für Objektspeicher Forks von Tigris oder lakeFS. - Bringen Sie zuerst „Löschungen landen im Papierkorb“ und „Snapshots gehören dem Eigentümer“ in Ordnung. Das ist am günstigsten und verhindert den größten Schaden. ## Schnittstellenskizze Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern. *nas cli* ```bash nas branch create cleo/release-notes --from main --ttl 48h nas checkpoint create before-refactor nas propose --into main --checks links,schema nas restore before-refactor nas trash list # recycle area, kept 7 days by default nas trash restore ``` ## Was die Spezifikation verlangt - Ein geschützter Tree MUSS sich nur durch einen Merge aktualisieren lassen; keine Zugangsdaten DÜRFEN direkt darauf schreiben. - Ein Merge MUSS einen Commit erzeugen, der Provenienz trägt (Run, Lease, Principal). - Keine Lease DARF erlauben, einen Snapshot oder ein Backup zu löschen. - Eine Löschung in einem geschützten Tree MUSS ein Soft Delete sein und innerhalb des eingestellten Zeitfensters (standardmäßig 7 Tage) wiederherstellbar bleiben. - Ein Konflikt DARF NICHT stillschweigend aufgelöst werden; der Merge MUSS anhalten und Bericht erstatten. - Ein Branch MUSS eine TTL und ein Kontingent haben. ## Was übernommen ist und was neu ist Alles Folgende ist etablierte Praxis. **Neu ist:** den Branch an eine **Ausführung und eine Lease** zu binden, sodass der Branch die Einheit der Autorisierung und der Merge die Einheit der Prüfung ist. Branches und Snapshots selbst sind nicht neu. - [Git worktree](https://git-scm.com/docs/git-worktree) - [lakeFS for agents](https://lakefs.io/agentic-ai/) - [Tigris Agent Kit](https://www.tigrisdata.com/docs/ai/agent-kit/) - [Cloudflare Artifacts](https://blog.cloudflare.com/artifacts-git-for-agents-beta/) ## Ehrliche Grenzen - Ein Branch schützt nur Daten innerhalb des NAS. Er **macht keine externen Nebenwirkungen rückgängig**: eine bereits gesendete E-Mail, eine bereits aufgerufene API. - Große Binärdateien und Datenbankdateien lassen sich schwer mergen. - Freigabemüdigkeit kann trotzdem auftreten, daher dürfen Pfade mit geringem Risiko automatisch gemergt werden, und die Freigabequote wird gemessen. ## Offene Fragen - Wie werden semantische Merger registriert und als vertrauenswürdig eingestuft? - Wie sollte die Interaktion bei Binärkonflikten aussehen? ## Fragen ### Wie unterscheidet sich das von einem Git-Branch? Mechanisch ist es keine Magie: Sie können es auf Git bauen. Der Unterschied ist, dass es den Branch an eine Ausführung und eine Lease bindet, sodass „kann nur den eigenen Branch beschreiben“ zu einer Autorisierungsregel und der Merge zum einzigen Prüfpunkt wird. ### Verhindert ein Branch jeden Unfall? Nein. Er schützt nur Daten innerhalb des NAS: Eine bereits gesendete E-Mail oder eine bereits aufgerufene externe API wird durch das Zurücksetzen eines Branches nicht rückgängig gemacht. Solche Aktionen sollten über `egress` in der Lease und ein Human Gate laufen. ### Muss jeder Merge von einem Menschen freigegeben werden? Nein. Ein Merge, dessen Prüfungen bestehen, dessen Ausführung keine externen Inhalte gelesen hat und der kein Löschen oder Teilen betrifft, kann automatisch durchgehen. Ein Mensch ist nur in wenigen Fällen nötig; siehe [Human Gate](https://agentnas.com/de/concepts/human-gate/). ## Verwandte Konzepte - [Human Gate (menschliche Freigabe)](https://agentnas.com/de/concepts/human-gate/): Erscheint nur vor unumkehrbaren, nach außen gerichteten oder rechteerweiternden Aktionen und zeigt den echten Diff. - [Agent Home (Home-Verzeichnis)](https://agentnas.com/de/concepts/agent-home/): Ein Verzeichnis pro Rolle, mit Verlauf. Gewöhnliche Dateien, die Sie mitnehmen können. - [Flight Recorder (Flugschreiber)](https://agentnas.com/de/concepts/flight-recorder/): Ein Protokoll pro Ausführung, per Hash verkettet, das auch festhält, was gelesen wurde. --- Kanonische URL: https://agentnas.com/de/concepts/agent-branch/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Flight Recorder (Flugschreiber) *Ein Protokoll pro Ausführung, per Hash verkettet, das auch festhält, was gelesen wurde.* > **Ein Flight Recorder** ist ein Append-only-Protokoll, per Hash verkettet und pro Ausführung geführt: was die Ausführung gelesen hat (das Lesemanifest), was sie geschrieben hat, was erlaubt oder verweigert wurde und wer was freigegeben hat. Er liegt neben den Daten und beantwortet eine Frage: „Was kann diese Änderung beeinflusst haben?“ **AN-03** · Konformitätsstufe: L1 Authority · Gruppe: Arbeit ## Das Problem Bei einer Nachanalyse sind die Logs verstreut; zwischen einem „Lesen“ und der Aktion, die darauf folgte, gibt es keine Verbindung; und Logs kann derselbe Administrator ändern, oder sogar derselbe Agent. Grundsätzlicher: Wenn der Verdacht besteht, dass ein Merge oder eine Erinnerung kontaminiert ist, lässt sich „Was hat diese Ausführung gelesen?“ nicht beantworten. ## So funktioniert es - **Zwei Arten von Inhalt.** *Ereignisse* werden einzeln aufgezeichnet: Commits, Ausstellung und Widerruf von Leases, Gate-Anfragen und -Entscheidungen, Richtlinienablehnungen, Ableitungen, Vergessen. Das *Lesemanifest* wird pro Ausführung aggregiert: welche Pfade@Commit, welche Bereiche und welche Inhalts-Hashes gelesen wurden. Es zeichnet nicht jeden einzelnen Lesezugriff auf und nie den Inhalt. - **Jeder Commit trägt Provenienz-Metadaten:** `principal`, `on_behalf_of`, `run`, `lease`, `purpose` und einen Verweis auf das Lesemanifest. - **Eine Hash-Kette** (pro Tag), mit optionalen Signaturen und externer Verankerung (ein zweiter Knoten, ein Bucket mit Object Lock). Das Ziel ist „**Manipulation lässt sich erkennen**“, nicht „Manipulation ist unmöglich“. - **Export:** OpenTelemetry-GenAI-Spans, JSON Lines oder in ein SIEM. - **Datenschutz:** standardmäßig nur Metadaten, keine Inhalte; die Aufbewahrung von Records ist unabhängig vom Löschen von Inhalten; die Records selbst sind zugriffsgeschützt. - **`explain(commit)`:** liefert Ausführung, Lease, Gate-Entscheidungen, Lesemanifest und Eingaben hinter diesem Commit. - **Erst protokollieren, dann handeln:** Eine folgenreiche Operation muss zuerst einen Absichtseintrag schreiben. ## Klein anfangen - Eine Append-only-SQLite-Tabelle plus ein täglicher Hash. - Git-Trailer wie `Run:` und `Lease:` in jeder Commit-Nachricht. - Exportieren Sie OpenTelemetry-Spans in den Observability-Stack, den Sie bereits haben. ## Schnittstellenskizze Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern. *record.json* ```json { "seq": 18211, "time": "2026-11-12T09:14:22Z", "kind": "commit", "run": "run_91ab", "principal": "agt_cleo", "on_behalf_of": "usr_wei", "lease": "lse_7Qk3", "purpose": "Draft the Q4 release notes", "subject": { "path": "/shared/launch/notes.md", "commit": "91ce3a7" }, "read_manifest": "rm_5d2e", "decision": { "effect": "allow", "rule": "r-17" }, "taint": { "external": true, "sensitivity": "private" }, "prev_hash": "sha256:b3a0..." } ``` ## Was die Spezifikation verlangt - Eine folgenreiche Operation MUSS einen Absichtseintrag schreiben, bevor sie wirksam wird; schlägt das Schreiben fehl, MUSS die Operation fehlschlagen. - Jede Ausführung MUSS ein Lesemanifest haben, das die gelesenen Pfade, Commits und Bereiche aufzeichnet (nicht den Inhalt). - Records MÜSSEN per Hash verkettet sein und MÜSSEN mit einem veröffentlichten Befehl prüfbar sein. - `explain(commit)` MUSS die Ausführung, die Lease, die Gate-Entscheidungen und einen Verweis auf das Lesemanifest liefern. - Die Aufbewahrung von Records MUSS vom Löschen von Inhalten unabhängig sein. ## Was übernommen ist und was neu ist Alles Folgende sind etablierte Bausteine. **Neu ist das Lesemanifest:** Es macht aus „Lesen“ eine nachvollziehbare Menge von Eingaben, sodass sich „ein kontaminierter Merge“ und „vergiftetes Gedächtnis“ im Nachhinein untersuchen lassen. - [OpenTelemetry GenAI conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/) - [Certificate Transparency](https://certificate.transparency.dev) - [Sigstore Rekor](https://docs.sigstore.dev/logging/overview/) - [Git trailers](https://git-scm.com/docs/git-interpret-trailers) ## Ehrliche Grenzen - Ohne externe Verankerung kann ein Administrator mit root das Protokoll weiterhin zerstören. - Die Records selbst enthalten sensible Metadaten und müssen kontrolliert werden. - Die Granularität des Lesemanifests ist ein Kompromiss zwischen Speicherkosten und Nachvollziehbarkeit. ## Offene Fragen - Wie bleiben die Speicherkosten von Lesemanifesten bei hohem Durchsatz beherrschbar? - Wie werden Records mehrerer Knoten zusammengeführt und geprüft? ## Fragen ### Zeichnet es den Inhalt auf, den der Agent gelesen hat? Standardmäßig nicht. Ein Record enthält Pfade, Commits, Bereiche und Inhalts-Hashes: genug, um auf die Originaldaten zurückzuverweisen, ohne sensible Inhalte in ein Log zu kopieren. Der Inhalt bleibt im Store, geschützt durch Leases und Labels. ### Was bedeutet hier „manipulationserkennbar“? Wir versprechen nur, dass sich **Manipulation erkennen lässt**: Records sind per Hash verkettet, sodass das Ändern eines Records die Prüfung der Kette bricht; mit externer Verankerung (ein zweiter Knoten oder ein Bucket mit Object Lock) hält es auch gegen einen Administrator mit root stand. Ohne Verankerung kann ein Administrator das gesamte Log weiterhin zerstören. ### Warum werden Lesezugriffe aufgezeichnet? Weil das Risiko oft vom Lesen kommt: Eine Sitzung, die eine Webseite gelesen hat, kann danach eine kontaminierte Notiz schreiben. Das Lesemanifest lässt Sie hinterher beantworten: „Was hat diese Änderung beeinflusst?“ ## Verwandte Konzepte - [Capability Lease (befristete Berechtigung)](https://agentnas.com/de/concepts/capability-lease/): Eine enge Autorisierung für eine Ausführung, mit Ablauf und Budgets. Kind-Leases können nur enger sein. - [Trust Labels (Vertrauenslabels)](https://agentnas.com/de/concepts/trust-labels/): Zwei kleine Labels plus Sitzungskontamination setzen die Zweierregel durch. - [Cascade Forget (kaskadierendes Vergessen)](https://agentnas.com/de/concepts/cascade-forget/): Ableitungen entlang der Lineage löschen, den Verlauf nach Aufbewahrungsklasse behandeln und melden, was nicht möglich war. --- Kanonische URL: https://agentnas.com/de/concepts/flight-recorder/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Capability Lease (befristete Berechtigung) *Eine enge Autorisierung für eine Ausführung, mit Ablauf und Budgets. Kind-Leases können nur enger sein.* > **Eine Capability Lease** ist eine Autorisierung für bestimmte Daten und bestimmte Operationen, mit ausdrücklichem Ablauf und Budgets. Sie wird **einer Ausführung** ausgestellt und ist der einzige Weg, auf dem eine Ausführung das NAS berührt. Eine Kind-Lease kann nur enger sein als ihre Eltern-Lease. **AN-04** · Konformitätsstufe: L1 Authority · Gruppe: Befugnis ## Das Problem RBAC und ACLs gehen von stabilen Nutzern mit weitreichenden, dauerhaften Berechtigungen aus. Ein Agent braucht Berechtigungen, die auf die Aufgabe zugeschnitten sind und enden, wenn die Aufgabe endet. Schlimmer noch: Langlebige Zugangsdaten liegen oft dort, wo der Agent sie erreichen kann. Beim Vorfall vom April 2026 lag das Token in einer unbeteiligten Datei, erstellt zum Verwalten von Domains, aber fähig, alles zu tun. ## So funktioniert es - **Wer den Schlüssel hält.** Langlebige Zugangsdaten bleiben beim Orchestrator oder beim Eigentümer; eine Ausführung erhält eine Lease, keinen Schlüssel. Das Modell sieht nie langlebige Zugangsdaten. - **Eine Lease ist ein Access Token.** Ihre `authorization_details` ([RFC 9396](https://www.rfc-editor.org/rfc/rfc9396)) beschreiben Pfade, Aktionen und den Branch; sie wird vom Eigentümer oder Orchestrator per [Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693) angefordert, der Claim `act` hält die Delegationskette fest, und das NAS führt Zustand für Widerruf und Budgetzählung. - **Nur Verengung.** Eine Kind-Lease muss eine Teilmenge ihrer Eltern-Lease sein, vom NAS beim Ausstellen geprüft. - **Budgets.** Gelesene und geschriebene Bytes, Anzahl der Anfragen und optional Egress-Bytes und eine Ausgabengrenze, am Gateway gezählt. Sie sind eine **Sicherung** (Circuit Breaker), keine exakte Abrechnung. - **Richtlinienrahmen.** Der Eigentümer legt vorab einen Bereich fest; Leases darin werden automatisch ausgestellt, alles außerhalb geht an ein [Human Gate](https://agentnas.com/de/concepts/human-gate/). Langfristiger Zugriff wird als Rahmen ausgedrückt, nicht als langlebige Lease. - **B und C werden ausdrücklich erklärt.** Eine Lease nennt die höchste Sensibilität, die sie lesen darf, und ob sie in geschützte Trees schreiben oder Daten nach außen senden darf. Das sind Eingaben für [Trust Labels](https://agentnas.com/de/concepts/trust-labels/). - **Widerruf.** Eine kurze TTL (standardmäßig 4 Stunden, höchstens 24) plus sofortiger Widerruf, der sich auf Kind-Leases fortsetzt. - **`purpose` wird aufgezeichnet, nicht durchgesetzt:** Freitext kann eine Maschine nicht prüfen. ## Klein anfangen - Schreiben Sie einen Befehl `nas lease create`: Stellen Sie für jede Rolle ein Token mit Pfadpräfix, Aktionen und TTL aus, übergeben Sie es der Sandbox in einer Umgebungsvariablen, und lassen Sie das NAS Präfix und Aktionen durchsetzen. - Das verhindert bereits die erste Hälfte eines solchen Vorfalls: Das Token kann außerhalb der Lease nichts tun. - Budgets, Delegationsketten und Richtlinienrahmen können später folgen. ## Schnittstellenskizze Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern. *lease.json* ```json { "lease_id": "lse_7Qk3", "run": "run_91ab", "principal": "agt_cleo", "on_behalf_of": "usr_wei", "parent": null, "purpose": "Draft the Q4 release notes", "paths": ["/shared/launch/**", "/agents/cleo/workspace/**"], "actions": ["read", "write", "propose"], "branch": "cleo/run_91ab", "sensitivity_max": "private", "egress": false, "requires_gate": ["merge", "delete", "share"], "budgets": { "bytes_read": 200000000, "bytes_written": 5000000, "requests": 5000 }, "expires_at": "2026-11-12T16:00:00Z" } ``` ## Was die Spezifikation verlangt - Eine Lease MUSS ein Ablaufdatum haben und DARF NICHT über die maximale TTL hinaus verlängert werden; eine Verlängerung erfordert eine neue Ausstellung. - Eine Kind-Lease MUSS eine Teilmenge ihrer Eltern-Lease sein, und das NAS MUSS dies beim Ausstellen prüfen. - Der Widerruf einer Lease MUSS sich auf alle ihre Kind-Leases fortsetzen. - Langfristiger Zugriff MUSS als Richtlinienrahmen ausgedrückt werden und DARF NICHT zu einer langlebigen Lease gemacht werden. - Eine Lease MUSS ihre Sensibilitätsobergrenze erklären und angeben, ob sie Egress und Schreibzugriffe auf geschützte Daten erlaubt. - Langlebige Zugangsdaten DÜRFEN NICHT einem Modell oder einer Ausführung offengelegt werden. ## Was übernommen ist und was neu ist Alles Folgende sind etablierte Bausteine. **Neu ist:** die **Gestalt einer Ausführung und einer Aufgabe** als Einheit zu nehmen und den Branch, Budgets und die Eigenschaften der Zweierregel in eine einzige Lease zu legen. Tokens und Capability-Modelle selbst sind nicht neu. - [OAuth Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693) - [OAuth Rich Authorization Requests (RFC 9396)](https://www.rfc-editor.org/rfc/rfc9396) - [Biscuit](https://github.com/biscuit-auth/biscuit) - [UCAN](https://ucan.xyz/specification/) - [IETF attenuating agent tokens draft](https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/) ## Ehrliche Grenzen - Sie deckt nur Operationen innerhalb des NAS ab und kann nicht regeln, was ein Agent anderswo tut. - `purpose` lässt sich nicht durchsetzen, und Budgets sind ungefähr. - Eine Lease kann Missbrauch **innerhalb legitimer Befugnis** nicht verhindern; das ist die Arbeit von Branches und Gates. ## Offene Fragen - Wie kann `purpose` vom Freitext zu einer strukturierten Absicht werden, die eine Maschine prüfen kann? - Wie werden Budgets bei Föderation abgerechnet? ## Fragen ### Wie unterscheidet sich eine Lease von einem API-Schlüssel? Ein API-Schlüssel ist ein langlebiges gemeinsames Geheimnis, und sein Inhaber kann alles tun, was das Konto kann. Eine Lease ist an eine Ausführung gebunden, begrenzt Pfade, Aktionen und Zeit und kann nur enger werden; sie hört bei Ablauf auf zu wirken und lässt sich jederzeit widerrufen. ### Warum nicht einfach OAuth nutzen? Es ist OAuth: Eine Lease ist ein Access Token, angefordert per Token Exchange (RFC 8693) und beschrieben mit Rich Authorization Requests (RFC 9396). Agent NAS ergänzt nur, was OAuth nicht festlegt: die Ausführung als Einheit und den Branch, Budgets und die Eigenschaften der Zweierregel in einer Autorisierung. ### Was passiert mit einer Ausführung, wenn ihre Lease abläuft? Der Mount wird schreibgeschützt und danach ausgehängt; neue Anfragen werden abgelehnt und protokolliert. Der Branch bleibt, bis seine eigene TTL abläuft, sodass fertige Arbeit nicht verloren geht und nach einer Prüfung noch gemergt werden kann. ## Verwandte Konzepte - [Human Gate (menschliche Freigabe)](https://agentnas.com/de/concepts/human-gate/): Erscheint nur vor unumkehrbaren, nach außen gerichteten oder rechteerweiternden Aktionen und zeigt den echten Diff. - [Trust Labels (Vertrauenslabels)](https://agentnas.com/de/concepts/trust-labels/): Zwei kleine Labels plus Sitzungskontamination setzen die Zweierregel durch. - [Flight Recorder (Flugschreiber)](https://agentnas.com/de/concepts/flight-recorder/): Ein Protokoll pro Ausführung, per Hash verkettet, das auch festhält, was gelesen wurde. --- Kanonische URL: https://agentnas.com/de/concepts/capability-lease/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Human Gate (menschliche Freigabe) *Erscheint nur vor unumkehrbaren, nach außen gerichteten oder rechteerweiternden Aktionen und zeigt den echten Diff.* > **Ein Human Gate** ist ein durch Richtlinien ausgelöster Kontrollpunkt: Bevor eine **unumkehrbare, nach außen gerichtete oder rechteerweiternde** Aktion wirksam wird, gibt ein Mensch (oder ein benannter Freigeber) eine vollständig dargestellte, konkrete Aktion frei. Es ist so entworfen, dass es selten, konkret und schwer durchzuwinken ist. **AN-05** · Konformitätsstufe: L1 Authority · Gruppe: Befugnis ## Das Problem Das heutige „Human in the Loop“ ist entweder ein endloser Strom von Abfragen oder gar nichts. Anthropic berichtet, dass Nutzer von Claude Code 93 % bis 97 % der Berechtigungsabfragen freigeben; in seinem kontrollierten Experiment erkannten Menschen nur 13,6 % der eingeschleusten gefährlichen Befehle und wurden mit längeren Sitzungen schlechter. Das ist Herstellerforschung, um den Auto-Modus zu bewerben, und sie misst das Erkennen eingeschleuster Abfragen statt Vorfallraten im Betrieb, aber die Richtung ist klar. Dieselben Daten enthalten eine weitere Zahl: Nutzer lehnen 39 % der Pläne ab, aber nur 3 % der einzelnen Berechtigungsanfragen. Ernsthaft beurteilen Menschen Pläne und Merges, nicht jeden Tool-Aufruf. ## So funktioniert es - **Es erscheint an wenigen Stellen:** Merge in einen geschützten Tree, Löschen aus einem geschützten Tree, externes Teilen oder Veröffentlichen, Egress, Ausweiten einer Lease und Absenken eines Labels. Schreibzugriffe auf einem Branch brauchen keine Freigabe. - **Die Granularität ist ein Plan oder ein Merge.** Prüfen Sie einen PR, nicht fünfzig Abfragen. - **Die Gate Card wird vom NAS dargestellt:** der echte Diff, eine Zusammenfassung des Lesemanifests, die Lease und die Sitzungskontamination, nie die eigene Darstellung des Agenten. Optionen: freigeben, eingeschränkt freigeben, ablehnen; ein Timeout bedeutet standardmäßig Ablehnung. - **Eine Freigabe ist an den Digest der Aktion gebunden:** Sie bindet den Diff-Hash und die Lease und lässt sich nicht wiedereinspielen. - **Zustellung:** Push, Chat, E-Mail oder CLI; sie lässt sich delegieren; Passkeys sind eine optionale starke Authentifizierung. - **Nur eskalieren.** Ein optionaler Risikoklassifikator (auch ein LLM) darf eine Aktion nur an ein Gate **eskalieren** und nie **freigeben**. Ein Modell kann nur verschärfen, nie lockern. - **Müdigkeit wird gemessen:** Freigabequote und Zeit bis zur Freigabe; ist die Freigabequote ungewöhnlich hoch, spricht das dafür, Gates zusammenzulegen oder die Richtlinie zu verschärfen. ## Klein anfangen - Ein geschützter `main` plus PR-Review (jede Git-Plattform genügt) und eine Push-Benachrichtigung. - Oder eine CLI: `nas gate approve `. - Lassen Sie die Gate Card zuerst den „echten Diff“ zeigen; stürzen Sie sich nicht auf ausgefallene Oberflächen. ## Schnittstellenskizze Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern. *gate-card.json* ```json { "gate_id": "gt_2Mx4", "run": "run_91ab", "action": { "op": "merge", "from": "cleo/run_91ab", "into": "main", "files_changed": 4, "diff_sha256": "7d2a..." }, "why": "Release notes are ready for review", "risk": { "session_taint": ["external"], "sources": ["web:example.com/changelog"], "destructive": false, "egress": false }, "options": ["approve", "approve_narrowed", "deny"], "default": "deny", "expires_at": "2026-11-12T12:00:00Z" } ``` ## Was die Spezifikation verlangt - Eine Gate Card MUSS den echten, vom NAS berechneten Diff zeigen, nicht die Beschreibung des Agenten davon. - Eine Freigabe MUSS an den Digest der Aktion und an die Lease gebunden sein und DARF NICHT wiedereinspielbar sein. - Das Standardergebnis eines Timeouts MUSS die Ablehnung sein. - Ein Klassifikator oder ein LLM DARF NICHT freigeben; er KANN eine Aktion an ein Gate eskalieren. - Ein Merge in einen geschützten Tree, das Löschen aus einem geschützten Tree, externes Teilen, Egress, das Ausweiten einer Lease und das Absenken eines Labels MÜSSEN über ein Gate laufen. - Das NAS SOLLTE die Freigabequote und die Zeit bis zur Freigabe melden. ## Was übernommen ist und was neu ist Alles Folgende ist etablierte Praxis. **Neu ist:** die Freigabe am **Merge in der Speicherschicht** zu verankern und den Inhalt vom NAS (nicht vom Agenten) darstellen zu lassen. Freigaben und PRs selbst sind nicht neu. - [How we built Claude Code auto mode](https://www.anthropic.com/research/claude-code-auto-mode) - [Anthropic: approval data behind auto mode](https://claude.com/resources/articles/auto-mode-default-in-claude-code) - [CaMeL](https://arxiv.org/abs/2503.18813) - [WebAuthn](https://www.w3.org/TR/webauthn-3/) - [OpenID CIBA](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) ## Ehrliche Grenzen - Ein Mensch kann trotzdem die falsche Aktion freigeben; auch gebündelte Prüfung führt zu Müdigkeit. - Benachrichtigungskanäle können per Phishing angegriffen werden. - Eine Freigabe kann nichts aufhalten, was **außerhalb des Freigegebenen** liegt; das ist Aufgabe der Lease. ## Offene Fragen - Was ist die beste Oberfläche für Stapel- und gestufte Reviews? - Wie wird die Schwelle für automatisches Mergen gemessen und abgestimmt? ## Fragen ### Ist das nicht nur ein weiterer „Bestätigen“-Dialog? Bewusst nicht. Ein Dialog feuert bei jedem Tool-Aufruf, und bald klicken Menschen nur noch „Freigeben“. Ein Gate erscheint nur vor wenigen unumkehrbaren oder nach außen gerichteten Aktionen, zeigt den echten, vom NAS berechneten Diff, und die Freigabe bindet den Diff-Hash: Ändert sich der Diff, ist die Freigabe ungültig. ### Kann ein LLM entscheiden, ob etwas durchgeht? Es kann vorschlagen, dass „sich ein Mensch diesen Schritt ansehen sollte“; freigeben kann es nicht. Die Entscheidung, etwas durchzulassen, muss eine deterministische Regel oder die Freigabe eines Menschen sein. So hängt die Sicherheit nicht vom Urteil eines Modells ab. ### Was passiert bei einem Timeout? Standardmäßig Ablehnung. Die Ausführung erhält eine klare Absage und kann einen anderen Weg nehmen oder den Vorschlag auf ihrem Branch liegen lassen, damit sich ein Mensch darum kümmert. ## Verwandte Konzepte - [Capability Lease (befristete Berechtigung)](https://agentnas.com/de/concepts/capability-lease/): Eine enge Autorisierung für eine Ausführung, mit Ablauf und Budgets. Kind-Leases können nur enger sein. - [Trust Labels (Vertrauenslabels)](https://agentnas.com/de/concepts/trust-labels/): Zwei kleine Labels plus Sitzungskontamination setzen die Zweierregel durch. - [Agent Branch (Agentenzweig)](https://agentnas.com/de/concepts/agent-branch/): Jede Ausführung arbeitet auf einem Copy-on-Write-Branch. Nur ein geprüfter Merge erreicht die Hauptlinie. --- Kanonische URL: https://agentnas.com/de/concepts/human-gate/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Trust Labels (Vertrauenslabels) *Zwei kleine Labels plus Sitzungskontamination setzen die Zweierregel durch.* > **Trust Labels** sind zwei sehr kleine Label-Mengen an den Daten, **Herkunft** (`owner`, `agent`, `external`) und **Sensibilität** (`public`, `private`, `secret`), plus **Sitzungskontamination**. Das NAS setzt die Zweierregel als Sitzungs-Invariante durch: Eine Sitzung kann nicht zugleich [A] externe Inhalte gelesen haben, [B] sensible Daten berühren und [C] geschützten Zustand ändern oder nach außen kommunizieren. Das Vervollständigen des Dritten braucht ein [Human Gate](https://agentnas.com/de/concepts/human-gate/). **AN-06** · Konformitätsstufe: L3 Guard · Gruppe: Befugnis ## Das Problem Prompt Injection funktioniert, weil ein Modell „Anweisungen“ nicht von „Daten“ unterscheiden kann. Abwehr auf Modellebene (Klassifikatoren, Prompt-Härtung) hat Lücken, und Angreifer können sich anpassen. Ende Oktober 2025 schlug Meta die [Agents Rule of Two](https://ai.meta.com/blog/practical-ai-agent-security/) vor: Solange Injection nicht verlässlich gelöst ist, sollte eine Sitzung höchstens zwei von drei Eigenschaften haben. Verlässlicher ist es, die Folgen **außerhalb** des Modells zu begrenzen. Der Speicher ist genau der Ort, an dem jedes Lesen und Schreiben vorbeikommt, und damit ein natürlicher Ort, diese Regel in eine testbare Invariante zu verwandeln. ## So funktioniert es - **Labels.** Drei Herkünfte, drei Sensibilitäten und eine Markierung `reviewed` (gesetzt durch eine Gate-Freigabe). Importstellen (Webseiten, E-Mail, Uploads) erhalten standardmäßig `external`; findet ein Secret-Scanner Zugangsdaten, versieht er sie automatisch mit `secret`. - **Sitzungskontamination.** Die Zusammenfassung von allem, was eine Ausführung gelesen hat (aus dem Lesemanifest); innerhalb einer Sitzung wächst sie nur, und eine neue Sitzung beginnt sauber. - **Die Invariante.** A = die Sitzung hat `external` gelesen; B = die Lease darf `private` oder höher lesen (Schwelle konfigurierbar); C = die Lease darf einen Merge in einen geschützten Tree vorschlagen, teilen, löschen oder Daten nach außen senden. Gelten alle drei in einer Sitzung, wird der Aufruf, der C auslöst, abgelehnt oder an ein Gate geleitet. - **In der Praxis:** Braucht eine Lease sowohl B als auch C, braucht nach dem Lesen externer Inhalte jede spätere Aktion der Klasse C einen Menschen. Um diese Reibung zu vermeiden, erledigen Sie die Arbeit „externe Inhalte lesen“ in einer eigenen Sitzung ohne B und geben Ergebnisse nur über eine strukturierte Übergabe weiter. - **Weitergabe.** Ableitungen, die das NAS selbst erzeugt (Indizes, Zusammenfassungen), erben deterministisch die Vereinigung der Labels ihrer Eingaben; Dateien, die eine Ausführung schreibt, erben die Sitzungskontamination der Ausführung (die konservative Wahl). - **Deklassifizierung.** Nur über ein Human Gate oder eine **strukturierte Übergabe:** Die Ausgabe der kontaminierten Sitzung wird auf Felder beschränkt, die ein JSON Schema validiert (Enums, IDs, begrenzte Strings), und erst nach der Validierung darf eine privilegierte Sitzung sie lesen. Nur was sich deterministisch validieren lässt, verdient Vertrauen. - **Durchgesetzt wird am Gateway und am Mount** (die Lease und Sitzung kennen), nicht im Modell. ## Klein anfangen - Tun Sie nur zwei Dinge: Versehen Sie Dateien im Importverzeichnis mit `external`, und geben Sie einer Ausführung, die `external` gelesen hat, standardmäßig weder Egress noch einen geschützten Merge ohne Gate. - Schreiben Sie die Richtlinie als deterministische Regeln in Cedar oder Rego und nennen Sie bei Ablehnung lesbare Gründe. - Laufen Sie eine Woche im Modus „nur protokollieren“, um zu sehen, was fälschlich blockiert würde, und schalten Sie dann die Durchsetzung ein. ## Schnittstellenskizze Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern. *policy.yaml* ```yaml # Deterministic policy (Cedar- or Rego-style rules can express the same thing) session_invariant: rule_of_two properties: A: session.read_origin includes "external" B: lease.sensitivity_max >= "private" C: lease allows propose_protected | share | delete | egress on_would_complete_ABC: gate # never "allow" rules: - id: r-merge-1 when: session.A and op == "merge" and target.protected then: gate - id: r-secret-1 when: session.read_sensitivity == "secret" and op == "egress" then: deny ``` ## Was die Spezifikation verlangt - Jede Importstelle MUSS ein Standardlabel vergeben; externe Inhalte MÜSSEN `external` erhalten. - Die Sitzungskontamination DARF innerhalb einer Sitzung nur wachsen. - Die Richtlinienauswertung MUSS deterministisch sein und DARF NICHT ein LLM aufrufen. - Ein Aufruf, der einer Sitzung erlauben würde, A+B+C zu vervollständigen, MUSS abgelehnt oder an ein Gate geleitet werden. - Deklassifizierung MUSS über ein Gate oder eine schemavalidierte strukturierte Übergabe laufen. - Abgeleitete Daten MÜSSEN die Vereinigung der Labels ihrer Eingaben erben. ## Was übernommen ist und was neu ist Alles Folgende ist etabliertes Denken. **Neu ist:** die Sitzungskontamination an der **Speichergrenze** mit dem Lesemanifest umzusetzen und Labels auf Gedächtnis-Schreibzugriffe und abgeleitete Daten anzuwenden. Wir halten das Label-Gitter bewusst bei 3×3, weil feinkörnige Gitter in der Praxis zu einer Label-Explosion führen. OpenClaw macht Herkunftslabels und Isolation bereits innerhalb einer einzelnen Laufzeitumgebung; unser Unterschied ist nur, dies in den gemeinsamen Speicher zu legen. - [Agents Rule of Two (Meta)](https://ai.meta.com/blog/practical-ai-agent-security/) - [The lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) - [CaMeL](https://arxiv.org/abs/2503.18813) - [Fides](https://arxiv.org/abs/2505.23643) - [Design Patterns for Securing LLM Agents against Prompt Injections](https://arxiv.org/abs/2506.08837) - [OpenClaw memory architecture](https://docs.openclaw.ai/concepts/memory-architecture) ## Ehrliche Grenzen - Das ist **keine** Abwehr gegen Prompt Injection; es begrenzt Folgen. - Das NAS sieht Werkzeuge außerhalb von sich nicht (einen Browser, E-Mail), daher braucht es die Mitarbeit der Laufzeitumgebung. - Die Kontamination ist konservativ und bringt Reibung und Fehlalarme; Freitext außerhalb strukturierter Schemas kann weiterhin die Worte eines Angreifers tragen. - Verdeckte Kanäle lassen sich nicht beseitigen. ## Offene Fragen - Soll die Granularität eines Labels die Datei oder der Absatz sein? - Wie wird das Label-Vokabular über Mandanten hinweg verwaltet? - Wie lassen sich Fehlalarme verringern? ## Fragen ### Stoppt die Zweierregel Prompt Injection? Sie verhindert nicht, dass eine Injection geschieht. Sie sorgt dafür, dass eine manipulierte Sitzung **nicht alle drei** Eigenschaften „hat nicht vertrauenswürdige Inhalte gelesen, berührt sensible Daten, kann geschützten Zustand ändern oder Daten nach außen senden“ haben kann, und begrenzt so die Folgen. Meta betont selbst, dass sie eine Heuristik zur Risikominderung ist, die das Prinzip der geringsten Rechte nicht ersetzt. ### Warum nur drei Herkünfte und drei Sensibilitäten? Weil feinkörnige Label-Gitter dazu neigen, aufzublähen und in der Praxis abgeschaltet zu werden. 3×3 genügt, um zu sagen „wer es geschrieben hat, wie sensibel es ist“, und macht den Grund einer Ablehnung leicht verständlich. Feinere Aufteilungen lassen sich mit Pfaden und Leases erreichen. ### Macht die Sitzungskontamination den Agenten handlungsunfähig? Sie beschränkt nur drei Arten von Aktionen: einen geschützten Tree ändern, teilen oder löschen und Daten nach außen senden. Lesen und Schreiben innerhalb eines Branches bleiben unberührt. Um Reibung zu vermeiden, legen Sie die Arbeit des Lesens externer Inhalte in eine Sitzung ohne sensible Daten und geben nur Ergebnisse zurück, die gegen ein Schema validiert wurden. ## Verwandte Konzepte - [Human Gate (menschliche Freigabe)](https://agentnas.com/de/concepts/human-gate/): Erscheint nur vor unumkehrbaren, nach außen gerichteten oder rechteerweiternden Aktionen und zeigt den echten Diff. - [Agent Memory (Agentengedächtnis)](https://agentnas.com/de/concepts/agent-memory/): Notizen, die Sie lesen und bearbeiten können, sind die Wahrheit. Indizes sind ein Cache, den Sie wegwerfen können. - [Capability Lease (befristete Berechtigung)](https://agentnas.com/de/concepts/capability-lease/): Eine enge Autorisierung für eine Ausführung, mit Ablauf und Budgets. Kind-Leases können nur enger sein. --- Kanonische URL: https://agentnas.com/de/concepts/trust-labels/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Agent Memory (Agentengedächtnis) *Notizen, die Sie lesen und bearbeiten können, sind die Wahrheit. Indizes sind ein Cache, den Sie wegwerfen können.* > **Agent Memory** = **Notizen, die Sie lesen und bearbeiten können** + **Indizes, die Sie jederzeit wegwerfen können**. Jede Notiz nennt ihre Quellen; Indizes (Volltext, Vektor, Graph, Gliederung) sind nur Ableitungen der Notizen; und Wartungsjobs im Hintergrund **schlagen** Änderungen nur **vor** und schreiben das rohe Journal nie um. **AN-07** · Konformitätsstufe: L2 Memory · Gruppe: Wissen ## Das Problem Gedächtnis-Frameworks legen Gedächtnis in undurchsichtige Datenbanken: Man kann es nicht einsehen, vergleichen, migrieren oder korrigieren, zuverlässiges Löschen ist schwer, und Index und Embedding-Modell sind festgelegt. Und Gedächtnis ist selbst eine Angriffsfläche: In einer [Studie von 2026](https://arxiv.org/abs/2606.04329) erreichte die Vergiftung des persistenten Gedächtnisses über zwei Agenten hinweg eine durchschnittliche Angriffserfolgsrate von 50,46 %, und eine [weitere Studie](https://arxiv.org/abs/2607.05189) hatte mit einer einzigen sorgfältig gestalteten E-Mail Erfolg gegen Gedächtnis-Backends auf Dateisystem- wie auf Vektorbasis. Zugleich ist „welche Gedächtnisarchitektur ist die beste“ längst nicht entschieden: Benchmarks widersprechen sich. Ein Entwurf, der auf keinen bestimmten Retrieval-Algorithmus setzt, kann drei Jahre Wandel überstehen. ## So funktioniert es - **Notizen sind die Wahrheit.** Markdown mit YAML-Frontmatter: `kind` (episodisch, semantisch, prozedural, Präferenz), `subject`, `sources`, `confidence`, `valid_from`, `valid_to`, `supersedes`, `origin`, `reviewed`. - **Aktualisieren, nicht überschreiben.** Ein neuer Fakt `supersedes` den alten; Gültigkeitszeit und Aufzeichnungszeit werden getrennt gehalten, weil sich Fakten ändern und gängige Benchmarks das kaum testen. - **Indizes sind ein Cache.** BM25 (zum Beispiel SQLite FTS5), Vektoren (mehrere können nebeneinander bestehen) und ein optionaler Graph; jede Ableitung trägt ihr **Rezept** und ihre **Eingaben**. Das Embedding-Modell zu wechseln heißt, im Hintergrund neu zu berechnen, und der alte Index bleibt, bis der neue die Golden-Recall-Tests besteht. - **Zwei Arten der Ableitung.** Deterministische (Chunking, BM25, Embeddings aus einem festen Modell) sind reproduzierbar; generative (LLM-Zusammenfassungen, extrahierte Fakten) lassen sich nur „neu erzeugen und vergleichen“, daher werden sie mit `generated: true` markiert und dienen nie als einzige Kopie. - **Schreibpfad.** `nas_remember` schreibt eine Notiz (mit Quellen) auf den aktuellen Branch, und die Kontamination wird vererbt. Eine Notiz aus einer Sitzung mit der Kontamination `external` kommt in **Quarantäne**, als ungeprüft markiert: Sie lässt sich abrufen, wird aber **nicht automatisch geladen** und gelangt nicht in `MEMORY.md`. - **Lesepfad.** `nas_recall` = Suche, Kandidaten, eine budgetierte Ansicht plus Belegzeiger, und es zeigt Quelle und Prüfstatus jeder Notiz. - **Wartungsjobs** (über Nacht oder im Leerlauf): deduplizieren, Episoden zu semantischen Fakten verdichten, Widersprüche markieren, veraltete Fakten ausmustern, Indizes neu aufbauen. Jobs erzeugen Vorschläge auf einem Branch, die ein Mensch oder ein Agent prüft; sie **löschen nie das rohe Journal**; die „Reuerate“ (der Anteil der Vorschläge, die zurückgerollt werden) wird gemessen. - **Golden-Recall-Tests.** Pro Home eine Menge von Paaren „Frage, erwartete Notiz“, die automatisch laufen, wenn sich das Modell oder der Indexer ändert. ## Klein anfangen - `memory/notes/*.md` mit Frontmatter und SQLite FTS5 für die Suche. - Lassen Sie zehn Golden-Fragen in der CI laufen. - Vektorindizes und Wartungsjobs können später folgen; bringen Sie zuerst „Provenienz“ und „nur geprüfte Notizen werden automatisch geladen“ in Ordnung. ## Schnittstellenskizze Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern. *memory/notes/customer-acme.md* ```markdown --- id: mem_4kq2 kind: semantic subject: customer/acme valid_from: 2026-10-02 valid_to: null confidence: 0.8 origin: agent reviewed: true sources: - nas://home-box/agents/cleo/journal/2026-10-02.md@9f2c1de#L12-L18 supersedes: [mem_1xa9] --- Acme renewed for 24 months; the champion moved from Dana to Luis. ``` ## Was die Spezifikation verlangt - Notizen MÜSSEN ohne die Memory-Schicht lesbar sein (sie sind gewöhnliche Dateien im Store). - Jede Ableitung MUSS ihr Rezept und ihre Eingaben tragen; ein Index MUSS verwerfbar und wiederaufbaubar sein. - Notizen aus einer kontaminierten Sitzung DÜRFEN NICHT automatisch geladen werden, bevor sie geprüft wurden. - Ein neuer Fakt MUSS einen alten mit `supersedes` ersetzen, statt ihn zu überschreiben. - Wartungsjobs MÜSSEN auf einem Branch arbeiten und nur vorschlagen; sie DÜRFEN NICHT das rohe Journal löschen. - Jedes Home SOLLTE Golden-Recall-Tests enthalten und sie ausführen, sobald sich das Modell oder der Indexer ändert. ## Was übernommen ist und was neu ist Alles Folgende ist etabliertes Denken, und die Gedächtnisarchitektur von OpenClaw macht Provenienz-Labels, Quarantäne pro Stufe und die Weitergabe von Kontamination bei der Konsolidierung bereits. **Neu ist:** OpenClaw macht das **innerhalb einer Laufzeitumgebung**; wir schlagen vor, es **im gemeinsamen Speicher** zu tun, sodass jede Laufzeitumgebung profitiert, und den Index zu einem verwerfbaren Cache zu degradieren, damit sich der Retrieval-Algorithmus ändern kann, ohne Gedächtnis zu verlieren. - [Letta Context Repositories](https://www.letta.com/blog/context-repositories/) - [Letta: is a filesystem all you need?](https://www.letta.com/blog/benchmarking-ai-agent-memory/) - [OpenClaw memory architecture](https://docs.openclaw.ai/concepts/memory-architecture) - [Long-term memory security survey](https://arxiv.org/abs/2604.16548) - [Graphiti](https://github.com/getzep/graphiti) - [MemGPT](https://arxiv.org/abs/2310.08560) ## Ehrliche Grenzen - Generative Ableitungen lassen sich nie Bit für Bit reproduzieren. - Ein Wartungsjob kann einen Fehler zu einem Fakt „verhärten“; deshalb schlägt er nur vor und bearbeitet nie direkt. - Welche Gedächtnisarchitektur die beste ist, bleibt offen. ## Offene Fragen - Wann sollte ein Agent selbst Gedächtnis schreiben, und wann ein Wartungsjob? - Was ist der Regressionsmaßstab über Modellversionen hinweg? ## Fragen ### Warum Dateien statt einer Vektordatenbank? Dateien sind die Wahrheit, die Sie lesen, bearbeiten, vergleichen und mitnehmen können; ein Vektorindex ist ein abgeleiteter Cache, der in mehreren Versionen nebeneinander bestehen und jederzeit neu aufgebaut werden kann. Der Benchmark von Letta zeigte, dass ein Agent mit nur `grep` und Dateiwerkzeugen konkurrenzfähig ist, aber Benchmarks widersprechen sich, daher setzt der Entwurf nicht auf einen Retrieval-Algorithmus. ### Wie wird Gedächtnisvergiftung verhindert? Man kann nicht garantieren, dass nie etwas Schlechtes geschrieben wird, aber die Folgen lassen sich begrenzen: Inhalte von außen tragen das Label `external`; Notizen aus einer kontaminierten Sitzung kommen in Quarantäne und werden nicht automatisch geladen; Merges werden geprüft; und wenn etwas schiefgeht, können Sie der Provenienzkette zu den betroffenen Notizen folgen und zurücksetzen. ### Muss ich das Gedächtnis migrieren, wenn ich das Embedding-Modell wechsle? Nein. Die Notizen ändern sich nicht; nur die Indizes werden im Hintergrund mit dem neuen Rezept neu berechnet, und der alte Index bleibt, bis der neue die Golden-Recall-Tests besteht. ## Verwandte Konzepte - [Budgeted Reads (budgetiertes Lesen)](https://agentnas.com/de/concepts/budgeted-reads/): Eine Datei als Gliederung, Abschnitt, Zeilenbereich oder vollständig lesen, abgestuft, damit sie ins Budget passt. - [Cascade Forget (kaskadierendes Vergessen)](https://agentnas.com/de/concepts/cascade-forget/): Ableitungen entlang der Lineage löschen, den Verlauf nach Aufbewahrungsklasse behandeln und melden, was nicht möglich war. - [Trust Labels (Vertrauenslabels)](https://agentnas.com/de/concepts/trust-labels/): Zwei kleine Labels plus Sitzungskontamination setzen die Zweierregel durch. --- Kanonische URL: https://agentnas.com/de/concepts/agent-memory/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Budgeted Reads (budgetiertes Lesen) *Eine Datei als Gliederung, Abschnitt, Zeilenbereich oder vollständig lesen, abgestuft, damit sie ins Budget passt.* > **Budgeted Reads** sind Lesezugriffe, die in einem Token-Budget gemessen werden: Dieselbe Datei lässt sich in unterschiedlicher Detailtiefe lesen, von der Gliederung und dem Abschnitt bis zum Zeilenbereich und dem vollen Text. Der Agent bittet um „die beste Ansicht, die in N Token passt“ und erhält Belegzeiger auf die genaue Quelle zurück. **AN-08** · Konformitätsstufe: L2 Memory · Gruppe: Wissen ## Das Problem Agenten verbrennen ihren Kontext an ganzen Dateien und wiederholten Lesezugriffen, und naives RAG-Chunking verliert Struktur. Modelle sind bereits gut in `grep`, `tail` und zeilenweisem Lesen: Cursor schreibt zu lange Tool-Ausgaben in Dateien, die Agenten bei Bedarf lesen, und bei Ausführungen, die ein MCP-Tool aufriefen, senkte die [dynamische Entdeckung](https://cursor.com/blog/dynamic-context-discovery) von Tool-Beschreibungen die Gesamtzahl der Token um 46,9 %. Das Problem ist also nicht, „noch ein Retrieval-System zu bauen“, sondern dem Lesen auf Dateien einen **budgetierten, überprüfbaren** Vertrag zu geben. ## So funktioniert es - **Zuerst Dateien.** Standardlesezugriffe (auch auf Zeilenbereiche) sind immer verfügbar; Budgeted Reads ist eine optionale Erweiterung obendrauf und ersetzt das Dateisystem nicht. - **Deterministische Gliederungen (kostenlos):** der Überschriftenbaum von Markdown, Code-Symbole (tree-sitter), Schlüssel von JSON und YAML, Kopfzeilen und Zeilenanzahl von CSV. Ein LLM ist dafür nicht nötig. - **Budget und Abstufung.** Eine Anfrage trägt `budget_tokens`; passt es nicht, wird auf eine gröbere Ansicht abgestuft **statt stillschweigend abzuschneiden**; die Antwort nennt die tatsächliche Ansicht, die Token-Zahl und ob sie `generated` ist. - **Die Suche liefert Ausschnitte und Zeiger,** keine ganzen Dateien. - **Belegzeiger:** `nas:////@#L12-L18`, stabil und gegen einen Commit überprüfbar; `dereference` liefert den genauen Inhalt. - **Was sich seit dem letzten Mal geändert hat:** liefert den Diff zwischen zwei Commits statt der ganzen Datei. - **Eine optionale LLM-Zusammenfassungsschicht:** als Cache, mit `generated: true` markiert und mit einer Veraltungsmarkierung. ## Klein anfangen - Fügen Sie nichts über `nas_read` hinaus hinzu: Lassen Sie den Agenten auf die alte Art lesen, mit `rg` und `sed -n`. - Ergänzen Sie dann ein kleines Gliederungswerkzeug für Markdown und Code. - Beginnen Sie Belegzeiger als „Pfad@Commit#Zeile“; ein neuer Dienst ist nicht nötig. ## Schnittstellenskizze Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern. *POST /v1/files/read* ```http POST /v1/files/read { "path": "/agents/cleo/memory/notes/customer-acme.md", "view": "outline", "budget_tokens": 400 } 200 OK { "view": "outline", "tokens": 212, "generated": false, "truncated": false, "content": "# Acme\n## Renewal (L12-L18)\n## Contacts (L19-L31)\n## Open issues (L32-L40)", "evidence": [ { "pointer": "nas://home-box/agents/cleo/memory/notes/customer-acme.md@9f2c1de#L1-L40" } ] } ``` ## Was die Spezifikation verlangt - Eine Antwort MUSS die tatsächlich gelieferte Ansicht und ihre Token-Zahl nennen; generative Ansichten MÜSSEN markiert sein. - Ist das Budget zu klein, MUSS das NAS auf eine gröbere Ansicht abstufen und DARF NICHT stillschweigend abschneiden. - Standard-Dateilesezugriffe (auch auf Bereiche) MÜSSEN verfügbar bleiben. - Belegzeiger MÜSSEN gegen einen Commit überprüfbar sein. - Die Suche MUSS standardmäßig Ausschnitte und Zeiger statt ganzer Dateien liefern. ## Was übernommen ist und was neu ist Schrittweises Offenlegen und grep sind an sich nicht neu. **Neu ist:** Budgets und Belegzeiger zu einem **Lesevertrag auf der Speicherebene** zu machen, sodass sich Antworten überprüfen lassen: Man kommt von einem Satz zurück zu den Zeilen des Commits, aus denen er stammt. - [Cursor: dynamic context discovery](https://cursor.com/blog/dynamic-context-discovery) - [Agent Skills (progressive disclosure)](https://agentskills.io/specification) - [Letta Context Repositories](https://www.letta.com/blog/context-repositories/) - [RAPTOR](https://arxiv.org/abs/2401.18059) ## Ehrliche Grenzen - Tokenizer unterscheiden sich zwischen Modellen, daher sind Token-Zahlen Schätzungen. - Es funktioniert nur, wenn Clients es übernehmen. - Zusammenfassungen veralten und können falsch sein, daher sind sie nur ein Cache und immer markiert. ## Offene Fragen - Wie soll der Budgetfehler über unterschiedliche Modell-Tokenizer hinweg behandelt werden? - Wie wird die Qualität von Zusammenfassungen bewertet? ## Fragen ### Wie unterscheidet sich das von RAG? RAG liefert die Ausschnitte, die einer Frage am nächsten sind. Budgeted Reads lässt einen Leser die Detailtiefe für ein Objekt wählen, das er schon kennt, stuft ehrlich ab, wenn das Budget knapp ist, und liefert überprüfbare Zeiger. Beides lässt sich stapeln: Suchergebnisse können ebenfalls als budgetierte Ansichten zurückkommen. ### Muss ich es nutzen, um Dateien zu lesen? Nein. Mounts und Git geben Ihnen immer gewöhnliche Dateien; Budgeted Reads ist ein optionales Lesen für Agenten, denen Token wichtig sind. ### Kann ein Belegzeiger „erfundene Zitate“ verhindern? Er macht Zitate überprüfbar: Ein Zeiger nennt bestimmte Zeilen in einem Commit, und sein Inhalts-Hash lässt sich verifizieren. Er hindert ein Modell nicht daran, etwas zu erfinden, aber er macht aus „Gibt es die zitierte Passage tatsächlich?“ eine maschinelle Prüfung. ## Verwandte Konzepte - [Agent Memory (Agentengedächtnis)](https://agentnas.com/de/concepts/agent-memory/): Notizen, die Sie lesen und bearbeiten können, sind die Wahrheit. Indizes sind ein Cache, den Sie wegwerfen können. - [Agent Home (Home-Verzeichnis)](https://agentnas.com/de/concepts/agent-home/): Ein Verzeichnis pro Rolle, mit Verlauf. Gewöhnliche Dateien, die Sie mitnehmen können. - [Flight Recorder (Flugschreiber)](https://agentnas.com/de/concepts/flight-recorder/): Ein Protokoll pro Ausführung, per Hash verkettet, das auch festhält, was gelesen wurde. --- Kanonische URL: https://agentnas.com/de/concepts/budgeted-reads/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0 --- # Cascade Forget (kaskadierendes Vergessen) *Ableitungen entlang der Lineage löschen, den Verlauf nach Aufbewahrungsklasse behandeln und melden, was nicht möglich war.* > **Cascade Forget** ist Löschen entlang der Lineage: Wird eine Quelle gelöscht oder bittet jemand darum, vergessen zu werden, findet das NAS alles, was daraus abgeleitet wurde, darunter Zusammenfassungen, Embeddings, Notizen, die darauf verweisen, Caches und Links zum Teilen, löscht es oder leitet es ohne diese Quelle neu ab und stellt einen **Bericht** aus: was getan wurde und was nicht möglich war. **AN-09** · Konformitätsstufe: L3 Guard · Gruppe: Wissen ## Das Problem Eine Datei zu löschen löscht weder ihre Embeddings noch ihre Zusammenfassungen noch die Fakten, die das Gedächtnis daraus abgeleitet hat; Snapshots und Backups bleiben; und der Inhalt steht weiter im Versionsverlauf. „Wiederherstellbar“ und „vergessbar“ sind zwei Enden einer Achse, und die meisten Systeme überlassen diese Wahl keinem Menschen. Wer erst nach dem Schreiben ans Vergessen denkt, ist meist zu spät dran. ## So funktioniert es - **Lineage.** Jede Ableitung hält ihre Eingaben fest; ein Rückwärtsindex beantwortet „alles, was von X abhängt“; auch das Feld `sources` einer Notiz ist Lineage. - **Aufbewahrungsklasse, beim Schreiben entschieden** (weil sich der Verlauf danach nicht mehr umschreiben lässt): `scratch` (kurze TTL, nicht in Backups, kann bei Ende der Ausführung bereinigt werden), `normal` (versioniert, wiederherstellbar) und `sensitive` (eigene Schlüsseldomäne, die sich durch Zerstören des Schlüssels vernichten lässt). - **Die Spannung zwischen Wiederherstellung und Vergessen.** Wiederherstellbar innerhalb des Soft-Delete-Fensters; erst danach endgültig gelöscht; eine Vergessensanfrage darf das Fenster überspringen. - **Ablauf.** Eine Anfrage (von einem Menschen oder Betreiber gestellt; ein Agent kann nur bitten, nicht ausführen), Durchlaufen der Lineage, Löschen von Ableitungen und Neuableiten von Fakten gemischter Herkunft, Umschreiben des Verlaufs betroffener Pfade und Bereinigen von Snapshots für die Klasse `normal`, Zerstören von Schlüsseln für die Klasse `sensitive` und schließlich der Bericht. - **Der Bericht:** die Anzahl gelöschter Dateien, entfernter Ableitungen, ob der Verlauf umgeschrieben wurde, zerstörter Schlüssel, noch nicht abgelaufener Snapshots und eine **ausdrückliche Liste dessen, was es nicht abdeckt:** Kopien außerhalb des NAS, Logs des Modellanbieters und Modellgewichte. - Es läuft immer über ein [Human Gate](https://agentnas.com/de/concepts/human-gate/) (oder eine vorab autorisierende Richtlinie); eine **Löschsperre (Legal Hold)** blockiert das Vergessen und wird protokolliert. ## Klein anfangen - Beginnen Sie mit Aufbewahrungsklassen und Soft Delete und halten Sie die Eingaben jeder Ableitung fest. - Erreichen Sie zuerst: „Wird eine Quelldatei gelöscht, alle ihre Ableitungen auflisten und löschen.“ - Heben Sie sich das kryptografische Löschen für die Klasse `sensitive` auf; es muss nicht gleich überall umgesetzt werden. ## Schnittstellenskizze Nur zur Veranschaulichung. Feldnamen können sich vor der Spezifikation v0.3 ändern. *forget-report.json* ```json { "forget_id": "fgt_3b7c", "selector": { "paths": ["/shared/crm/acme/**"], "subject": "customer/acme" }, "retention_class": "sensitive", "report": { "files_removed": 142, "derived_removed": { "embeddings": 3621, "summaries": 210, "notes_rewritten": 6 }, "history": "rewritten (3 commits)", "keys_destroyed": ["key_acme"], "snapshots_pending": ["nightly-2026-11-10 (expires 2026-11-17)"], "not_covered": ["copies outside the NAS", "model provider logs", "model weights"] }, "state": "pending_expiry" } ``` ## Was die Spezifikation verlangt - Vergessen MUSS sich entlang der Lineage von der Quelle auf jede Ableitung fortsetzen. - Die Aufbewahrungsklasse MUSS beim Schreiben zugewiesen werden (standardmäßig `normal`). - Ein Vergessensbericht MUSS auflisten, was er nicht abdeckt: Kopien außerhalb des NAS, Logs des Anbieters und Modellgewichte. - Eine Löschsperre MUSS das Vergessen blockieren und MUSS protokolliert werden. - Ein Agent KANN Vergessen anfordern, DARF es aber NICHT ausführen. - Ein Bericht DARF NICHT behaupten, ein Modell habe etwas „vergessen“. ## Was übernommen ist und was neu ist Alles Folgende ist etabliert. **Neu ist:** die **Aufbewahrungsklasse** als ausdrückliche Eigenschaft des Speichers zu behandeln und zuzugeben, dass „wiederherstellbar“ und „vergessbar“ ein Kompromiss auf einer Achse sind. - [OpenLineage](https://openlineage.io) - [GDPR Article 17](https://gdpr-info.eu/art-17-gdpr/) - [Long-term memory security survey (forget and rollback)](https://arxiv.org/abs/2604.16548) ## Ehrliche Grenzen - Backups, Kopien außerhalb des NAS und Logs von Modellanbietern liegen außerhalb des Umfangs. - Bei Fakten, die aus mehreren Quellen abgeleitet wurden, ist der „betroffene Bereich“ schwer zu definieren. - Das Umschreiben des Verlaufs ist teuer und riskant. ## Offene Fragen - Wie wird der betroffene Bereich eines Fakts gemischter Herkunft definiert? - Wie sollte der Ablauf aussehen, wenn eine Löschsperre mit einer Vergessensanfrage kollidiert? ## Fragen ### Kann es ein Modell vergessen lassen? Nein, und es behauptet das auch nicht. Es kann Dateien und Ableitungen innerhalb des NAS löschen und, für die Klasse `sensitive`, Verlauf und Schlüssel; Logs von Modellanbietern und Modellgewichte liegen außerhalb des Umfangs, und der Bericht sagt das ausdrücklich. ### Warum wird die Aufbewahrungsklasse beim Schreiben gewählt? Weil sich der Verlauf danach schwer umschreiben lässt: Was bereits in Backups und Verlauf gelandet ist, lässt sich nur umschreiben oder muss ablaufen. Beim Schreiben zu entscheiden, ob etwas `scratch`, `normal` oder `sensitive` ist, ist die Voraussetzung dafür, später sauber löschen zu können. ### Kann ein Agent von sich aus darum bitten, etwas zu vergessen? Er kann eine Anfrage stellen, aber nicht ausführen. Vergessen ist unumkehrbar und muss über einen Menschen oder eine vorab autorisierende Richtlinie laufen, und eine Löschsperre kann es blockieren. ## Verwandte Konzepte - [Agent Memory (Agentengedächtnis)](https://agentnas.com/de/concepts/agent-memory/): Notizen, die Sie lesen und bearbeiten können, sind die Wahrheit. Indizes sind ein Cache, den Sie wegwerfen können. - [Flight Recorder (Flugschreiber)](https://agentnas.com/de/concepts/flight-recorder/): Ein Protokoll pro Ausführung, per Hash verkettet, das auch festhält, was gelesen wurde. - [Agent Branch (Agentenzweig)](https://agentnas.com/de/concepts/agent-branch/): Jede Ausführung arbeitet auf einem Copy-on-Write-Branch. Nur ein geprüfter Merge erreicht die Hauptlinie. --- Kanonische URL: https://agentnas.com/de/concepts/cascade-forget/ Aktualisiert am: 2026-11-11 · Spezifikationsentwurf v0.2 · CC BY 4.0