Sicherheit
MarketingOS verspricht keine Sicherheit durch ein neues Etikett. Direct ist der heutige Standard und akzeptiert nur vertrauenswürdige lokale Workloads. OpenClaw Secure ergänzt eine Docker Schutzschicht, deren vollständige Workload Isolation noch nicht belegt ist. Hermes Secure ist nicht verfügbar und stoppt vor jeder Änderung. Diese Runtime-Profile besitzen keinen allgemeinen Schreibpfad; der getrennte Managed Google Connector wird ausschließlich auf einer dedizierten Reviewer-Infrastruktur live validiert und ist kein Kundenrelease.
Direct benötigt kein Docker und ist für Crawls, Analysen, Evidence und lokale Entwürfe gedacht. Es akzeptiert ausschließlich vertrauenswürdige lokale Workloads. Eine Werkzeugliste kann Rechte verkleinern, aber keinen bereits kompromittierten Host Prozess einschließen.
Der Orchestrator und elf Fachagenten laufen mit deaktiviertem Netzwerk, schreibgeschütztem Root Dateisystem, ohne Workspace Zugriff und ohne Linux Fähigkeiten. Dieser Aufbau ist Defense in Depth. Noch ist nicht belegt, dass jeder relevante Agent Workload und jeder Gateway Pfad innerhalb dieser Grenze bleibt. Deshalb gilt er nicht als untrusted oder Production ready.
Zwölf Skills, Slash Commands und das Team Bundle tragen die Rollenlogik samt delegate_task Zuordnung. Das native Plugin stellt davon getrennt exakt elf Datenwerkzeuge bereit. Diese Tool Surface enthält kein Terminal, Dateisystem, Browser, Webzugriff, allgemeines Exec, Memory, Skill Management, Tool Search, MCP oder fremdes Plugin Werkzeug. Auch diese Allowlist ist keine Prozessisolation.
Ein Secure Versuch stoppt vor jeder Mutation mit hermes-secure-whole-process-unavailable und fällt nicht auf Direct zurück. Eine Docker Terminal Umgebung würde nur das Terminal einschließen, nicht den Hermes Prozess. Erst ein geprüfter Wrapper um den gesamten Prozess kann diese Grenze schließen.
Policy Authority, Capability Broker, Secret Broker, Audit Service und Secure Executor trennen Entscheidung, Berechtigung, Credential Referenz, Beleg und Ausführung. Sie sind gebaut und getestet. Im lokalen Standardaufbau laufen diese fünf Dienste weiterhin unter demselben Betriebssystemkonto und bilden deshalb keine harte Kernel-Grenze. Die dedizierte Managed-Google-Prüfumgebung ergänzt getrennte Betriebssystemidentitäten für Proxy, Callback Relay, Local Agent, Secure Profile, Audit Witness, Reviewer Gateway und OpenClaw.
Der öffentlich dokumentierte Alpha-Quellstand besitzt keine aktiven Produktionsadapter für allgemeine Writes und keinen allgemeinen externen Schreibpfad. Ein Prompt, ein gespeichertes Secret oder ein allgemeines approved Signal kann diese Sperre nicht öffnen. Die fünf Google Writes brauchen jeweils ihren exakten Vertrag im getrennten Managed Connector.
Capability Grants sind mit Ed25519 signiert, kurzlebig und genau einmal verwendbar. Sie binden Workspace, Kontext, Connector, Operation, Ziel, Payload, Risiko, Freigabe, Ablaufzeit und Nonce. Ändert sich ein gebundener Wert, ist der Grant unbrauchbar. Jeder Google Write darf höchstens einen Provider-Versuch auslösen und braucht Receipt, Provider-Postcheck sowie Rollback oder ausdrückliche Recovery.
Der Audit Service führt eine signierte Hash Kette. Ein unabhängig betriebener Witness akzeptiert nur den registrierten Schlüssel, die nächste Sequenz und den zuvor bestätigten Head. Dreizehn Angriffstests prüfen unter anderem Fork, Rollback, falsche Schlüssel, gelöschte Tails und denselben Betriebssystemaccount. Ein Prozess unter demselben Konto zählt nicht als unabhängig.
Bleibt die Bestätigung unklar, behält der Audit Service seinen lokalen Eintrag und sperrt spätere Einträge bis zum manuellen Abgleich. Die dedizierte Reviewer-Bereitstellung führt den Witness unter einer zweiten Betriebssystemidentität; dieser Live-Beleg gilt nur für den Reviewer-Host und nicht für den lokalen Standardaufbau oder ein Kundenrelease.
Automatisierte Tests prüfen Installation, Update und Rückbau in isolierten Windows Testverzeichnissen. Sie ersetzen keinen Lauf auf einer frischen Kundenmaschine und belegen kein aktuelles signiertes Kundenartefakt. Reale Release Läufe fehlen damit für Windows, macOS und Linux.
Der WLAN Zugriff braucht HTTPS, eine enge Firewallregel und eine kurzlebige Browsersitzung. Portfreigaben ins Internet, geteilte Master Tokens und unverschlüsseltes HTTP gehören nicht zum vorgesehenen Betrieb.
MarketingOS ersetzt weder Patchmanagement noch Backups, Endgeräteschutz oder die Rechteverwaltung verbundener Plattformen. Es reduziert Reichweite und Wiederverwendbarkeit eines Fehlers. Nullrisiko oder Enterprise Isolation wären heute keine ehrlichen Aussagen.
Primärquellen
OpenClaw beschreibt die Sandbox als optional. Toolausführung kann isoliert laufen, der Gateway Prozess bleibt jedoch auf dem Host. Erhöhte Tools können die Sandbox umgehen.
Die Tool Policy entscheidet, welche Werkzeuge ein Modell überhaupt sieht. Ein erlaubtes exec bleibt trotzdem eine allgemeine Shell und wird nicht durch das Sperren einzelner Dateitools automatisch lesend.
Hermes benennt die Betriebssystemisolation als eigentliche Grenze gegen ein feindliches Modell. Für nicht vertrauenswürdige Eingaben und produktive oder geteilte Installationen empfiehlt das Projekt einen Schutz um den gesamten Prozess.
Der Proof Ledger trennt Runtimeprüfung, installierte Profile, Connector Tests und noch offene Betriebsgates. Herstellerdokumentation ersetzt keinen MarketingOS Test.
Weiterlesen
Das Trust Center trennt technische Evidence, synthetische Showcases und offene Release Gates.