These: Agent-Safety ohne Out-of-Band-Sentry ist Sandbox-Marketing

Ein Agent, der in einer Sandbox läuft und von einem Sentry beobachtet wird, klingt nach sauberer Arbeit. Ob es das ist, entscheidet eine einzige Frage: Wer erzwingt die Policy, wenn der Host, auf dem der Agent läuft, schon kompromittiert ist?

Meine These steht vorab, damit Sie wissen, woran Sie sind. Agent-Safety ohne Out-of-Band-Sentry ist Prompt-Theater mit Sandbox-Marketing. Das ist keine NVIDIA-Aussage. Das ist meine Einschätzung.

Falsch wäre es, daraus zu lesen, Software-Isolation sei wertlos. Sie ist nötig. Sie ist nur nicht genug, wenn die Kontrolle auf derselben Maschine sitzt wie das Ding, das sie kontrollieren soll.

Warum der Agent sich nicht selbst kontrolliert

Wer Agent-Safety nur im selben Host durchsetzt, betreibt Self-Policing. Die Polizei wohnt im Haus des Verdächtigen. Solange das Haus steht, mag das funktionieren. Fällt der Host, fällt die Aufsicht gleich mit.

Ohne Out-of-Band-Sentry ist die Sandbox Marketing, nicht Enforcement. Hart formuliert, ich weiß. Aber prüfen Sie es: Wo läuft der Code, der Ihre Regeln durchsetzt, und wer hat dort Schreibrechte?

NVIDIA liefert dafür selbst ein Argument, und zwar eines, das mich überzeugt. Im Technical Blog vom 28. September beschreiben die Autoren John Myers, Alex Watson, Ali Golshan und Ofir Arkin das Problem der Drift. Gemeint sind Handlungen, die von Aufgabe oder Constraints abweichen. Sie entstehen laut Blog nach einem Policy-Block, nach einem Bug, bei einem fehlenden Tool, bei mehrdeutigen Anweisungen oder in langen Läufen.

Der entscheidende Punkt: Drift lässt sich laut NVIDIA nicht wegtrainieren, ohne die Fähigkeit des Modells zu verlieren. Die Lehre daraus ist unbequem. Ein Agent in dieser Lage kann sein Verhalten nicht vollständig selbst regieren.

Genau. Wer das akzeptiert, muss die Kontrolle nach außen verlegen.

Zwei Quellen, ein Produktversprechen

Ich stütze mich auf zwei NVIDIA-Quellen: den Technical Blog und die Product Page zur Open Agent Safety Platform. Beide stammen vom Hersteller. Alles, was folgt, sind also NVIDIA-Claims, keine unabhängigen Messungen und keine eigenen Tests von uns. Wir bei digital-magazin.de haben nichts davon im Labor nachgestellt.

Der Blog trägt den Titel „NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring“. Er beschreibt OpenShell als Open-Source-Secure-Runtime unter Apache 2.0, gedacht für autonome Agents in Sandbox-Umgebungen mit Kernel-Level-Isolation. Dazu kommt NVIDIA Sentry auf BlueField-4 DPUs. Beides zusammen ergibt eine geschichtete Safety-Architektur, mit OpenShell auf Vera CPUs.

Die Product Page erzählt dieselbe Geschichte als Verkaufsargument. Sie nennt ein offenes Reference Design mit Partnern, das Agent-Verhalten überwacht und steuert. Die Lizenz Apache 2.0 taucht dort allerdings nicht auf. Die Seite sagt nur: Open Source. Das ist eine kleine Abweichung, aber sie zeigt, welche Quelle welche Details trägt.

Es gibt größere Abweichungen. Dazu später mehr. Eine vorab: Die Product Page spricht von „host is compromised“ und in der FAQ von „host or workload is compromised“. Der Blog formuliert anders, nämlich „host resources cannot be trusted“ und „beyond the agent’s reach“. Das sind nicht dieselben Sätze, und ich schiebe sie nicht zusammen.

Was die Schichten laut NVIDIA leisten

Der Blog nennt drei Schichten: Application, Runtime und Infrastructure. Unter Application fallen die Modelle und das, was NVIDIA „Harness“ nennt. Mehr braucht es für diesen Artikel nicht.

Die Runtime-Schicht ist OpenShell. Es setzt jeden Agent in eine Sandbox und macht aus den Anweisungen eine verifizierbare Policy. Die Verantwortlichen definieren Dateien, Netze, Tools, Prozesse und Credentials. Geprüft wird vor dem Lauf, durchgesetzt während der Arbeit.

Die Infrastruktur-Schicht ist Sentry. Der Blog beschreibt sie als zusätzliche, unabhängige Schicht in BlueField-Hardware. DOCA macht das BlueField-Fundament programmierbar und koppelt es an die OpenShell-Policy. Es korreliert Interaktionen, Policy-Entscheidungen sowie Tool- und Datenzugriff. Das DOCA-Gateway kümmert sich um Identity Governance, also die fortlaufende Prüfung von Identität und delegierter Autorität.

Mal ehrlich: Das klingt plausibel. Es klingt auch nach Architekturfolien. Entscheidend ist, was im Betrieb passiert, wenn etwas schiefgeht, und dafür lohnt ein genauer Blick auf die Formulierungen.

Bei OpenShell behauptet NVIDIA auf der Product Page Zero-Trust, Permissions nach Intent und ein Out-of-Process-Enforcement, das als nicht umgehbar bezeichnet wird. Das ist ein Claim über die Software-Schicht. Er betrifft nicht Sentry. Und genau hier liegt die Spannung, die ich benennen will: Dieselbe Seite wirbt dafür, dass die Hardware-Schicht übrig bleibt, wenn Host oder Workload kompromittiert sind. Wäre die Software-Durchsetzung auf dem Host tatsächlich nicht umgehbar, bräuchte es diese zweite Schicht nicht in dieser Dringlichkeit. Beides zugleich zu verkaufen, ist legitim. Beides zugleich zu glauben, ist es nicht.

Kernel-Sandbox und Out-of-Process-Policy auf demselben Host sind nicht dasselbe wie Out-of-Band-Enforcement außerhalb der Host-Software. Außerhalb des Agent-Prozesses ist nicht außerhalb des Hosts. Dieser Unterschied ist der ganze Artikel in einem Satz. Die Product Page selbst trennt die Ebenen: OpenShell wendet Policy außerhalb des Agent-Prozesses an, Sentry mit BlueField-4 setzt eine unabhängige Schicht außerhalb von Agent- und Host-Software. Zwei Außen, zwei verschiedene Vertrauensgrenzen. Wer beide in einen Topf wirft, kauft die falsche Sicherheit und merkt es erst im Vorfall, wenn der Host bereits nicht mehr das tut, was er soll, und niemand mehr da ist, der es bemerkt.

Sentry und Sandbox: Braucht OpenShell wirklich BlueField-4?

Nein. Die FAQ der Product Page ist an dieser Stelle erfreulich ehrlich. OpenShell läuft auf lokaler, On-Prem-, Cloud- und Kubernetes-Infrastruktur, und zwar ohne BlueField-4. Wer eine Sandbox für seinen Agenten will, braucht dafür keine neue Hardware. Punkt. Die Sandbox gibt es also auch ohne Sentry.

Interessant wird der zweite Teil der Antwort. Mit BlueField-4 ergänzt Sentry laut Product Page hardware-isoliertes Monitoring und Enforcement, das in Betrieb bleibt, „if the host or workload is compromised“. Merken Sie sich die Doppelung: Host oder Workload. Das ist weiter gefasst als die Formulierung im Benefits-Block der Seite, wo es nur um „even if the host is compromised“ geht. Der Blog formuliert wieder anders: Dort heißt es, Sentry sei vom Host isoliert und „beyond the agent’s reach“, auch wenn „host resources cannot be trusted“. Drei Quellenstellen, drei Wortlaute. Ich schiebe sie nicht zu einem Satz zusammen, weil sie nicht dasselbe versprechen. Wer Sentry bewertet, muss wissen, welchen dieser Sätze er gerade kauft.

Der Blog nennt Sentry zudem ausdrücklich eine optionale Security-Schicht neben OpenShell. Optional. Die Plattform ist laut NVIDIA auch mit anderer Hardware kompatibel. Das ist die Sprache eines Referenzdesigns, nicht die eines Pflichtkaufs. Ein Out-of-Band-Sentry bleibt damit eine Entscheidung, keine Voraussetzung für die Sandbox.

Wo BlueField-4 sitzt, entscheidet alles

Im Vera-Rubin-POD sitzt BlueField-4 laut Blog auf dem einzigen Pfad des Knotens zum Modell. Von dort aus gibt es kontinuierliche Out-of-Band-Observability und Policy-Enforcement in Echtzeit, „at line speed“. Eine Zahl nennt der Blog dafür nicht, und ich erfinde keine. Der Sentry sitzt also nicht neben dem Agenten, sondern auf dessen Weg.

Für alle, bei denen Vera mit BlueField-4 schon läuft, kommt der Schutz laut Blog per Software-Update. Das ist der pragmatischste Satz der ganzen Plattform. Die Hardware steht schon im Rack, die Sentry-Schicht wird eingeschaltet. Für alle anderen gilt: Sie bekommen OpenShell, und Sie bekommen die Sandbox. Die zweite, unabhängige Schicht bekommen Sie damit nicht. Ohne sie bleibt die Sandbox ein Werkzeug auf dem Host, den sie eigentlich schützen soll.

Die fünf Prinzipien: Was NVIDIA im Blog tatsächlich festlegt

Fünf Prinzipien, und nur der Blog formuliert sie aus. Die Product Page listet sie nicht. Wer also mit „NVIDIA sagt, Safety braucht fünf Dinge“ argumentiert, sollte wissen, welche Quelle er zitiert. Hier sind sie, ohne Auffüllung.

Erstens: Policy muss verifizierbar sein. Vor dem Lauf zeigt ein Prover, dass die Policy die Absicht der Verantwortlichen nicht verlassen kann. Das ist ein Beweis vorab, kein Vertrauen im Nachhinein. Mal ehrlich: Die meisten Policies, die ich im Betrieb sehe, werden erst im Vorfall geprüft. Dann hilft auch die beste Sandbox nichts mehr.

Zweitens: Enforcement muss out of band sein. Die Controls leben nicht im Agent und nicht in seiner Reichweite. Der Agent muss nicht einmal wissen, dass er beobachtet wird. Genau hier setzt meine These an. Ein Kontrollpunkt, den der Beobachtete erreichen kann, ist keiner. Ein Out-of-Band-Sentry ist die Antwort auf genau diesen Satz.

Drittens: Der Pfad zum Modell ist der Kontrollpunkt. Ohne den nächsten Gedanken kann der Agent nicht handeln. Wer den Pfad zum Modell kontrolliert, besitzt den Beobachtungspunkt und den Kill-Switch. Das ist elegant gedacht. Es ist aber eine architektonische Aussage über den Aufbau, in dem BlueField-4 auf diesem Pfad sitzt und Sentry dort arbeitet.

Und hier die Einschränkung, die ich klar sagen will: Der Kill-Switch gilt dort, wo die Hardware auf dem einzigen Pfad sitzt. Er gilt nicht automatisch für jede OpenShell-Installation ohne diese Hardware. Wer den Blog liest und daraus „jede Sandbox hat einen Not-Aus“ macht, liest zu viel hinein.

Viertens: Autorität wächst mit der Sichtbarkeit des Denkens. Je mehr ein Agent darf, desto sichtbarer muss sein Reasoning sein. Offene Modelle machen Reasoning-Raum und Activations einsehbar, und das nennt der Blog als Vorteil. Ein geschlossenes Modell liefert diese Sicht nicht in derselben Tiefe. Das sollten Einkaufsrunden wissen, bevor sie einem Agenten Rechte freigeben.

Fünftens: geteilte Verantwortung. Labs, Enterprises und Hardware-Anbieter besitzen je eine Schicht. Runtime und Policy-Sprache sollen offen sein. Das ist gleichzeitig Architektur und Absicherung gegen den Vorwurf, NVIDIA wolle alles besitzen. Auch die Sentry-Schicht ist nur eine von mehreren.

Was die Prinzipien für Ihren Betrieb heißen

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic photo of a glass server cage and an empty office chair, no labels, no logos, no readable text, no watermarks, 16:9

Wer fragt, ob das alles nur Theorie ist? Nein, aber es ist eine Checkliste mit unbequemen Antworten. Wir bei digital-magazin.de lesen die fünf Prinzipien als Prüffragen. Wer besitzt den Pfad zum Modell? Sitzt die Kontrolle in der Reichweite des Agents? Gibt es einen Beweis vor dem Lauf oder nur eine Hoffnung? Bleibt die Kontrolle, wenn der Host fällt und die Sandbox mit ihm?

Die Grundlagen dafür finden Sie in Regeln, Rechte, Logs und ein Not-Aus im Betrieb. Dort geht es um die organisatorische Seite. Die Hardware-Frage ersetzt sie nicht. Und wer Netzgrenzen bauen will, findet den Gegenentwurf zum Prompt-Vertrauen bei Firewall-Regeln, die ein Agent nicht selbst wegverhandelt.

Den Gesamtzusammenhang lesen Sie am besten im Original, im Technical Blog von NVIDIA, der die fünf Prinzipien ausformuliert. Lesen Sie ihn als Positionspapier eines Anbieters. Das ist er auch.

Meiner Einschätzung nach ist das stärkste Prinzip das zweite. Alle anderen lassen sich mit Software nachbauen. Dieses eine nicht, jedenfalls nicht ehrlich. Falsch wäre allerdings der Schluss, ohne BlueField-4 sei jede Sandbox wertlos. Sie begrenzt den Schaden im Normalfall. Sie ist nur kein unabhängiger Zeuge, wenn der Host selbst zum Problem wird. Dafür braucht es Sentry oder eine vergleichbare Schicht außerhalb des Hosts.

Sentry und die Quarantäne: Was die Quellen wirklich sagen

Jetzt wird es heikel. Die Product Page behauptet, NVIDIA Sentry könne einen Agent in Millisekunden quarantänen. Out-of-band, mit in-silicon Telemetrie und Policy-Enforcement. Eine Zahl nennt die Seite nicht, und ich erfinde keine.

Der Blog klingt anders. Dort steht nichts von Millisekunden und nichts von Quarantäne. Er beschreibt Sentry als zusätzliche, optionale Schicht neben OpenShell, mit kontinuierlicher Out-of-Band-Observability und Policy-Enforcement in Echtzeit („at line speed“). Das sind zwei Formulierungen für verwandte, aber nicht identische Versprechen. Die eine beschreibt eine Reaktion auf einen Agent, die andere Beobachtung und Durchsetzung auf dem Pfad zum Modell.

Mal ehrlich: Das ist kein Skandal. Eine Product Page darf zuspitzen, ein Technical Blog darf vorsichtiger sein. Aber Sie dürfen daraus keinen gemeinsamen Satz basteln. Wer „Quarantäne in Echtzeit“ in ein Pflichtenheft schreibt, zitiert keine der beiden Quellen. Fragen Sie den Anbieter, was genau passiert, wenn Sentry anschlägt: Wird der Pfad gekappt, der Agent angehalten, die Sandbox eingefroren? Und wer bekommt die Meldung?

Drei Sätze zum Host, drei Aussagen

Auch beim Thema Host lohnt der Blick auf den Wortlaut. Die Product Page sagt an einer Stelle, die unabhängige Security-Boundary halte, „even if the host is compromised“. In der FAQ heißt es, das hardware-isolierte Monitoring bleibe in Betrieb, „if the host or workload is compromised“. Der Blog formuliert wieder anders: Sentry arbeite auch dann, wenn „host resources cannot be trusted“, und liege „beyond the agent’s reach“, also außerhalb der Reichweite des Agents.

Das ist dreimal dieselbe Richtung, aber nicht dreimal derselbe Anspruch. „Workload kompromittiert“ ist ein größerer Fall als „Agent außer Reichweite“. „Host nicht vertrauenswürdig“ ist wiederum weicher als „Host kompromittiert“. Ich finde, genau hier entscheidet sich der Einkauf.

Stellen Sie deshalb zwei Fragen. Erstens: Welche Schicht bleibt übrig, wenn der Host fällt? Hält die Sandbox dann noch, oder nur Sentry? Zweitens: Welche Quelle behauptet das überhaupt, Blog, Benefits oder FAQ? Lassen Sie sich die Antwort schriftlich geben, mit Verweis auf die Stelle. Wer das nicht kann, verkauft Ihnen Stimmung.

Sentry, DOCA und die Frage nach der Identität

Was heißt „in-silicon“ eigentlich? Ohne Marketing: Die Prüfung läuft nicht als Prozess auf dem Server, den sie überwachen soll, sondern auf einer eigenen Karte mit eigenem Prozessor. Die BlueField-DPU sitzt am Netzpfad. Ein Angreifer, der den Host übernimmt, übernimmt damit nicht automatisch diese Karte. So lautet jedenfalls das Argument.

DOCA ist die Software, die BlueField programmierbar macht. Laut Product Page sieht Sentry über DOCA jede Request und jede Response. Dazu kommen granulare Policy, attestierte Telemetrie, verifizierbare Identität und Zero-Trust auf Datenzugriff. Der Blog setzt einen anderen Akzent: DOCA koppelt das Fundament an die OpenShell-Policy und korreliert Interaktionen, Policy-Entscheidungen, Tool- und Datenzugriff. Das DOCA-Gateway prüft fortlaufend Identität und delegierte Autorität jedes einzelnen Agenten.

Der Unterschied ist praktisch. Die Product Page zählt Fähigkeiten auf. Der Blog beschreibt eine Verknüpfung zwischen Sandbox-Policy und Hardware-Sicht. Für Ihren Betrieb ist die Verknüpfung interessanter, denn ein Log ohne Bezug zur Policy hilft im Vorfall wenig. Klartext: Attestierte Telemetrie von Sentry ist nur so gut wie die Entscheidung, wer sie liest und was daraus folgt. Das gilt auch für die zentralen Sandbox-Logs mit ihrem Allow/Deny-Audit-Trail.

Die Grenze im selben Host

Wir bei digital-magazin.de haben schon beschrieben, warum Rootless-Container als Isolationsgrenze sinnvoll sind. Das gilt weiter. Rootless senkt die Rechte eines Agenten, verkleinert den Schaden und ist ein ordentlicher Baustein.

Aber es bleibt Host-Territorium. Eine Isolationsgrenze, die der Host selbst zieht, kann nur so lange halten wie der Host. Rootless ist ein anderes Thema als Sentry, die Frage dahinter ist dieselbe: Wer setzt die Grenze durch, wenn der Host fällt?

Punkt. Eine Kernel-Sandbox beantwortet sie nicht. Out-of-Process-Policy auf demselben Rechner beantwortet sie auch nicht, so nützlich beides im Alltag ist. Eine Sandbox, die auf dem gefallenen Host läuft, ist dann Sandbox-Marketing. Nur eine Instanz außerhalb von Agent-Software und Host-Software kann es überhaupt versuchen.

Das bedeutet nicht, dass Sie sofort Hardware bestellen. OpenShell läuft laut FAQ ohne BlueField-4, auf lokaler, On-Prem-, Cloud- und Kubernetes-Infrastruktur. Sentry ist die Option obendrauf. Prüfen Sie, welches Risiko Sie tragen, bevor Sie entscheiden, ob Ihnen dieser Zeuge namens Sentry den Aufpreis wert ist. Fragen Sie auch, welche Sandbox dann noch zählt und welcher Agent welche Rechte behält.

Jetzt zur Zahl, die in Präsentationen am häufigsten hängen bleibt. Die Product Page beschreibt die Vera-CPU als eigens gebaut für agentic reasoning, Tool-Execution und Task-Planning, mit der Control Plane auf Vera. Dazu kommt ein Vergleich: bis zu 80 Prozent schnellere Sandbox-Performance gegenüber traditioneller CPU-Infrastruktur. Der Zweck dahinter: „sandbox everything“ soll Standard werden statt Kompromiss. Jeder Agent läuft dann in einer Sandbox, ohne dass es wehtut.

Beachten Sie die Herkunft. Diese 80 Prozent stehen nur auf der Product Page. Der Technical Blog vom 28. September nennt sie nicht, mit keinem Wort. Wir haben nichts nachgemessen, und wir behaupten auch nichts dazu. Es ist ein NVIDIA-Claim für die Sandbox-Performance, und er sagt „bis zu“, nicht „immer“.

Meiner Einschätzung nach sagt die Zahl etwas über die Kosten der Sandbox und nichts darüber, wer die Policy erzwingt, wenn der Host fällt. Schnelle Isolation ohne Sentry bleibt Isolation auf demselben Host. Der Agent läuft dort schneller, mehr nicht.

Wer die Details prüfen will, liest die Angaben direkt auf der Product Page von NVIDIA. Dort steht auch der Teil, der für den Betrieb wichtiger ist als jede Prozentzahl: der Audit.

Audit: Was die Sandbox protokolliert

Laut FAQ gibt es einen Audit-Trail von Allow- und Deny-Entscheidungen und zentrale Sandbox-Logs. Ein Agent kann Policy-Änderungen anfragen. Automatische Genehmigungen sind optional und gelten nur innerhalb der freigegebenen Policy-Grenzen. Die Verantwortlichen behalten die Grenzen in der Hand.

Das ist solide. Es ist aber ein Logbuch, kein Beweis. Ein Log aus der Sandbox, die auf dem Host entsteht, den Sie gerade verdächtigen, hat dasselbe Vertrauensproblem wie alles andere dort. Erst Sentry als unabhängige Schicht außerhalb des Hosts ändert diese Lage. Mehr dazu, was bei der Implementierung im Betrieb schiefgeht, lesen Sie in unserem Beitrag zur Einführung.

Zur Kompatibilität nennt die Product Page als unterstützte Agents Claude Code, Codex, OpenCode, GitHub Copilot CLI und OpenClaw, dazu eigene Sandbox-Images sowie offene und geschlossene Modelle. Das war es dazu.

Fünf Fragen vor dem Kauf

Hand aufs Herz: Die meisten Beschaffungsgespräche drehen sich um Preis und Durchsatz. Stellen Sie stattdessen diese Fragen:

• Wer besitzt den Pfad zum Modell?
• Läuft die Kontrolle auf demselben Host wie der Agent?
• Bleibt sie bestehen, wenn der Host fällt, und welche Quelle sagt das?
• Ist Sentry gekauft oder nur die Sandbox?
• Steht die 80-Prozent-Angabe zur Sandbox im Blog oder nur auf der Product Page?

Die dritte Frage trennt Belege von Behauptungen. Die Product Page spricht von „even if the host is compromised“ und „host or workload is compromised“. Der Blog formuliert anders: „host resources cannot be trusted“, die Kontrolle liege „beyond the agent’s reach“. Das ist nicht derselbe Satz. Schieben Sie ihn nicht zusammen, auch nicht für die Folie. Ein Agent, eine Sandbox und ein Sentry brauchen jeweils ihren eigenen Beleg.

Der Punkt ist:

Ich finde die Architektur ernsthaft interessant. Aber ich bleibe bei meiner Linie, und sie ist unsere, nicht die von NVIDIA: Agent-Safety ohne Out-of-Band-Sentry ist Prompt-Theater mit Sandbox-Marketing.

Wer die Regeln nur im selben Host durchsetzt, überwacht sich selbst. Fällt der Host, fällt auch der Aufpasser. Eine Sandbox ohne unabhängigen Sentry daneben ist Marketing, kein Enforcement, egal wie schnell der Agent darin läuft.

Ehrlich gesagt: Das heißt nicht, dass Sie Hardware brauchen. Es heißt, dass Sie wissen müssen, was Sie nicht haben.