Sie sollten nicht auf eine vollständige Öffnung warten: Der Öffnungszeitpunkt des Anthropic Model Hardware Standard ist zum 10.09.2026 nicht bekannt, weil MHS weiterhin als Forschungsangebot für ausgewählte Einrichtungen und über eine Nachrückerbewerbung läuft. Bereiten Sie jetzt Geräte-APIs, Berechtigungsgrenzen, menschliche Notabschaltung und reproduzierbare Tests vor, vermeiden Sie aber eine groß angelegte Umstellung auf eine noch nicht veröffentlichte Spezifikation.

Diese Seite ist für drei Gruppen gedacht: Entwickler, die MHS in gewöhnlichen Agent-Projekten einsetzen möchten, Forschungs- und Fertigungsteams mit programmierbaren Geräten sowie Plattformverantwortliche für sichere Fernsteuerung, Prüfstände und Rechenressourcen. Wenn Sie ausschließlich Desktop-Automatisierung ohne physische Geräte betreiben, benötigen Sie derzeit keine MHS-Integration.

Letzte Aktualisierung: 10.09.2026. Der Status wurde anhand der offiziellen Forschungsankündigung von Anthropic, der öffentlich beschriebenen MHS-Antragslage und der genannten Sicherheitsquellen geprüft.

Der bestätigte MHS-Stand lässt keine allgemeine Freigabe zu

Anthropic hat bestätigt, dass der Model Hardware Standard zunächst Forschungseinrichtungen und fortgeschrittenen Fertigungsorganisationen in einer Forschungsphase zugänglich gemacht wird. Zusätzlich werden Bewerbungen für eine Nachrückerliste angenommen. Eine konkrete allgemeine Öffnung oder ein verbindlicher Termin für die Veröffentlichung der vollständigen Spezifikation wurde dagegen nicht genannt. Die Aussage, dass der Standard künftig offen zugänglich werden soll, ist deshalb eine Planung, aber kein Veröffentlichungsdatum.

Wann wird der Model Hardware Standard als Open-Source-Standard verfügbar?
Derzeit gibt es dafür keinen bestätigten Termin. Aussagen über ein bestimmtes Quartal, eine bestimmte Gerätefamilie oder eine flächendeckende Freigabe sind Prognosen. Sie sollten solche Angaben nicht als Grundlage für die Beschaffung von Hardware, die Neuentwicklung eines Treibers oder eine langfristige Produktplanung verwenden.

Für Ihre Planung ist die Unterscheidung zwischen drei Zuständen entscheidend:

  • Jetzt umsetzbar: Gerätebeschreibung, Statusabfragen, Rollenmodell, Protokollierung, Simulation, Freigabeprozesse und Not-Aus.
  • Nur bei Vorschauzugang umsetzbar: Tests mit der tatsächlichen MHS-Schnittstelle und eine Rückmeldung an Anthropic zur Interoperabilität.
  • Erst nach Veröffentlichung belastbar: eine allgemeine Kompatibilitätsaussage, stabile Konformitätstests und eine dauerhafte Abhängigkeit von der MHS-Spezifikation.

Damit bleibt der sinnvollste Ansatz modular. Ihr AI Agent sollte eine eigene interne Geräteabstraktion verwenden, während ein späterer MHS-Adapter nur eine austauschbare Integrationsschicht bildet.

Software-Agenten benötigen heute keine Hardware-Norm

MHS richtet sich auf programmierbare physische Geräte. Ein Claude-gestützter Agent, der Dateien bearbeitet, einen Browser bedient oder über gewöhnliche MCP-Werkzeuge auf Softwarefunktionen zugreift, wird dadurch nicht automatisch zu einem MHS-Anwendungsfall. MCP beschreibt die Verbindung zwischen Modellen beziehungsweise Agenten und Werkzeugen; die Anthropic-Dokumentation zu MCP behandelt daher nicht automatisch die Sicherheitsfragen eines Motors, einer Druckkammer oder eines Roboterarms.

Das hat für Desktop- und Softwareteams drei praktische Konsequenzen:

  1. Werkzeugrechte bleiben Ihre Verantwortung. Ein Agent sollte nur die Aktionen sehen, die er für die aktuelle Aufgabe benötigt. Lesen, Schreiben, Starten, Löschen und externe Kommunikation gehören in getrennte Berechtigungsgruppen.
  2. Die Laufzeitumgebung muss isoliert sein. Eine virtuelle Arbeitsumgebung, ein getrenntes Benutzerkonto oder ein isolierter Testknoten verhindert, dass ein fehlerhafter Auftrag Produktionsdaten und Testdaten vermischt.
  3. Jede Aktion muss nachvollziehbar bleiben. Speichern Sie Auftrags-ID, Werkzeugname, Parameter, Freigabestatus, Ergebnis und Abbruchgrund. Bei personenbezogenen oder vertraulichen Daten müssen Sie zusätzlich die Anforderungen der Datenschutzerklärung von SSHMac und Ihrer eigenen DSGVO-Prozesse prüfen.

Können gewöhnliche Entwickler MHS bereits beantragen?
Eine allgemeine Bewerbung mit garantiertem Zugang ist nicht bestätigt. Die öffentliche Information beschreibt eine Forschungsphase mit ausgewählten Einrichtungen und eine Nachrückerbewerbung. Für ein gewöhnliches Softwareprojekt ist es deshalb vernünftiger, die interne Agent-Sicherheit fertigzustellen und einen möglichen MHS-Adapter später einzusetzen, statt auf eine Teilnahme zu spekulieren.

Wenn Ihr Team heute mit Computersteuerung beginnt, sollten Sie Zugangs-, Support- und Übergabeprozesse als Teil Ihrer Sicherheitsarchitektur dokumentieren. MHS wird weder fehlerhafte Werkzeugrechte noch unklare Verantwortlichkeiten automatisch beheben.

Erfahrungshinweis: Ein MCP-Server ist kein Geräte-Treiber und ein Geräte-Treiber ist keine Sicherheitsfreigabe. Die drei Ebenen sollten getrennt versioniert, getestet und abgeschaltet werden können.

Laborgeräte brauchen eine kontrollierte Geräteschicht

Für Forschungs- und Laborautomatisierung ist MHS wesentlich interessanter, weil standardisierte Gerätebeschreibungen die Verbindung zwischen Agent, Instrument und Ausführungsumgebung vereinheitlichen könnten. Die Forschungsankündigung bezieht sich auf programmierbare physische Systeme; daraus folgt jedoch nicht, dass jedes vorhandene Laborgerät bereits offiziell unterstützt oder kompatibel ist.

Bereiten Sie für jedes Instrument eine technische Gerätemappe vor. Sie sollte mindestens folgende Informationen enthalten:

  • verfügbare Programmier- und Kommunikationsschnittstellen;
  • lesbare Zustände, Messwerte und Zustandswechsel;
  • Fehlercodes mit einer eindeutigen Zuordnung zu Ursache und Gegenmaßnahme;
  • zulässige Betriebsbereiche und Aktionen, die ausschließlich Menschen ausführen dürfen;
  • Wiederanlaufverhalten nach Strom-, Netzwerk- oder Prozessfehlern;
  • manuelle Übernahme, physischer Not-Aus und sichere Rückkehr in den Leerlauf;
  • Testdaten, mit denen ein Agent ohne reale Probe üben kann.

Ist MHS auf Laborgeräte beschränkt?
Nein, die bestätigte Forschungsphase darf nicht als endgültige Gerätebegrenzung verstanden werden. MHS ist gerade als allgemeine Schnittstelle für physische, programmierbare Systeme relevant. Gleichzeitig ist nicht bestätigt, welche Geräteklassen nach einer späteren Öffnung unterstützt werden. Bezeichnen Sie ein Instrument daher erst dann als kompatibel, wenn eine veröffentlichte Spezifikation und ein reproduzierbarer Konformitätstest vorliegen.

Für die Zulassung sollte nicht der Agent selbst die letzte Entscheidung treffen. Ein fachkundiger Bediener muss einen Auftrag freigeben, wenn Material, Temperatur, Druck, Bewegung, Strahlung oder biologische Proben betroffen sind. Das gilt auch dann, wenn der Agent alle erwarteten Zustandswerte meldet. Ein plausibel aussehender Messwert kann auf einen falsch angeschlossenen Sensor, eine beschädigte Probe oder einen veralteten Kalibrierstand zurückgehen.

Roboter und Geräteverbände verlangen mehr als ein einheitliches Protokoll

Bei Robotern liegt der mögliche Nutzen von MHS vor allem in der Geräteerkennung und in einer einheitlicheren Auftragsübergabe. Ein Orchestrator könnte Gerätefähigkeiten, aktuelle Zustände und zulässige Operationen besser voneinander unterscheiden. Für Multi-Geräte-Abläufe wäre das hilfreich: Ein Greifer, eine Kamera und ein Prüfstand könnten ihre Rollen in einem gemeinsamen Ablauf beschreiben, ohne dass der Agent jedes Herstellersystem vollständig individuell kennen muss.

Das ist eine mögliche Wirkung der Standardisierung, keine bestätigte MHS-Funktion für jede konkrete Roboterplattform. Die Forschungsarbeit von Anthropic zu Claude und Robotik zeigt, warum räumliche Schlussfolgerungen und die Ausführung physischer Aktionen getrennt bewertet werden müssen. Ein Modell kann einen plausiblen nächsten Schritt formulieren und trotzdem eine Kollision, einen falschen Greifpunkt oder einen unerwarteten Zustand nicht zuverlässig erkennen.

Welche Vorbereitung braucht ein Geräte-Agent vor einem MHS-Anschluss?
Beginnen Sie mit einer Sicherheitsmatrix für jede Aktion:

  • Welche maximale Bewegung oder Zustandsänderung ist zulässig?
  • Welche Sensorwerte müssen vor dem Start und während der Ausführung bestätigt werden?
  • Was passiert bei widersprüchlichen Messwerten?
  • Welche Person darf freigeben, pausieren oder übernehmen?
  • Wie wird ein Not-Aus getestet, ohne das Gerät zu beschädigen?
  • Kann derselbe Auftrag in einer Simulation oder mit einem Attrappen-Gerät wiederholt werden?

Für kollaborative oder bewegliche Systeme müssen außerdem tote Winkel, Reichweite, Last, Kollisionserkennung und die sichere Position nach einem Kommunikationsabbruch geprüft werden. Ein vereinheitlichtes Geräteprotokoll ersetzt keine Gefährdungsbeurteilung. Die NIST-Initiative zu Physical AI und Robotikdaten ist dafür eine geeignete Referenz, weil sie die Bedeutung reproduzierbarer physischer Tests und Daten hervorhebt.

Fertigung und Fernwartung sollten zunächst nur lesend beginnen

In Produktions- und Wartungsszenarien könnte MHS später die Geräteerkennung, die Fehlerbehebung und die Koordination mehrerer Anlagen vereinfachen. Heute ist das eine Auswirkung auf die mögliche Produktplanung, keine zugesicherte MHS-Roadmap. Ihre erste Implementierung sollte deshalb keine freie Fernsteuerung vorsehen.

Ein belastbarer Aufbau arbeitet in Stufen:

  1. Nur-Lese-Monitoring: Der Agent darf Zustände, Warnungen und Diagnosewerte abrufen, aber keine Anlage verändern.
  2. Vorschlag statt Ausführung: Der Agent formuliert eine Maßnahme mit Parametern und erwarteten Nebenwirkungen.
  3. Menschliche Freigabe: Eine berechtigte Person bestätigt den konkreten Auftrag, nicht nur die allgemeine Sitzung.
  4. Isolierte Ausführung: Die Operation läuft über ein getrenntes Netzwerksegment oder einen kontrollierten Fernzugriff.
  5. Nachprüfung: Das System vergleicht den erwarteten Zustand mit den tatsächlich gemeldeten Werten.
  6. Rücksetzplan: Bei Abweichungen wird die Ausführung gestoppt und eine definierte sichere Betriebsart aktiviert.

Das Modell der NIST-KI-Risikomanagement-Rahmenwerk hilft dabei, technische Risiken nicht nur als Modellfehler zu behandeln. Zuständigkeit, Überwachung, Wiederherstellung und Nachweisbarkeit gehören ebenso in die Bewertung. Für Fernwartung kommen Netzwerkisolation, zeitlich begrenzte Zugangsdaten, Protokollschutz und eine getrennte Freigabe außerhalb des Agent-Prozesses hinzu.

Plattformteams müssen MCP, Agent und Gerät getrennt verwalten

Die häufigste Fehlplanung besteht darin, die Verantwortung in einer einzigen „Agent-Integration“ zu bündeln. Für einen späteren MHS-Einsatz sollten Sie mindestens vier Schichten unterscheiden:

  • Modell: erzeugt Vorschläge oder Aktionspläne;
  • Agent-Harness: entscheidet über Ablauf, Kontext, Wiederholungen und Abbruch;
  • MCP- oder Werkzeugschicht: stellt Funktionen mit definierten Eingaben und Ausgaben bereit;
  • Gerätetreiber: übersetzt Befehle, liest Zustände und behandelt gerätespezifische Fehler.

MCP kann eine standardisierte Werkzeugverbindung bereitstellen, ist aber nicht gleichbedeutend mit einer physikalischen Sicherheitsfreigabe. Die MCP-Ankündigung von Anthropic beschreibt den Zweck des Protokolls; die Autorisierungsspezifikation vom 18.06.2025 liefert konkrete Orientierung für Berechtigungsflüsse. Für Ihren Gerätebetrieb müssen Sie darüber hinaus Not-Aus, Grenzwerte, Zustandskonsistenz und fachliche Freigaben implementieren.

Wie verhalten sich MHS und MCP zueinander?
MCP kann die Werkzeug- und Kontextübergabe zwischen Agent und Dienst strukturieren. MHS soll nach der bestätigten Zielrichtung eine standardisierte Verbindung zu physischen, programmierbaren Geräten ermöglichen. Sie sind daher eher benachbarte als austauschbare Ebenen: MCP kann ein MHS-bezogenes Werkzeug transportieren, ersetzt aber nicht die Gerätebeschreibung, den Treiber oder die physische Sicherheitslogik.

Planen Sie für die Infrastruktur mindestens diese Artefakte:

  • einen zentralen, kurzlebigen Geheimnis- und Berechtigungsspeicher;
  • unveränderbare Aktionsprotokolle mit Korrelation zu Auftrag und Benutzer;
  • vollständige Aufgabenwiederholung aus Eingaben, Werkzeugaufrufen und Geräteantworten;
  • getrennte Testknoten für Simulation, Hardware-in-the-Loop und reale Geräte;
  • Versionssperren für Modell, Agent-Harness, MCP-Adapter und Gerätetreiber;
  • ein Rollback-Verfahren, das nicht auf den Agenten selbst angewiesen ist.

Wichtige Abgrenzung: Die Freigabe eines Werkzeugaufrufs darf niemals als Beweis gelten, dass die physische Aktion sicher ist. Die Sicherheitsentscheidung muss eine unabhängige, abschaltbare Kontrollinstanz treffen können.

Die Vorbereitung lässt sich mit einer klaren Prüfliste priorisieren

Nutzen Sie die folgende Liste, bevor Sie eine Bewerbung, einen Pilotbetrieb oder eine größere Architekturänderung einplanen:

  • [ ] Für jedes Gerät sind API, Kommunikationsweg, Zustände, Fehlercodes und zulässige Befehle dokumentiert.
  • [ ] Schreibende Aktionen sind von rein lesenden Diagnosefunktionen getrennt.
  • [ ] Rollen, Freigaben und zeitlich begrenzte Zugangsdaten sind definiert.
  • [ ] Ein physischer Not-Aus und eine manuelle Übernahme sind getestet und dokumentiert.
  • [ ] Agent-Aufgaben können ohne reale Produktionseinwirkung simuliert und wiederholt werden.
  • [ ] Jede Aktion enthält Auftrag, Benutzer, Modellversion, Werkzeugversion, Parameter und Ergebnis.
  • [ ] Netzwerkzugriffe auf das Gerät sind von Büro- und Entwicklungsnetzen isoliert.
  • [ ] Nach einem Kommunikationsfehler gibt es einen sicheren Zustand und einen manuellen Wiederanlauf.
  • [ ] Für jede Anlage existiert ein fachlicher Verantwortlicher, der Grenzwerte freigibt.
  • [ ] Ein MHS-Adapter kann ausgetauscht werden, ohne den gesamten Agent-Harness neu zu schreiben.
  • [ ] Offizielle MHS-Ankündigungen, Spezifikationsseiten und Sicherheitsleitfäden werden regelmäßig geprüft.
  • [ ] Nicht bestätigte Aussagen über Geräteunterstützung oder Öffnungstermine sind im Projektplan als Annahmen markiert.

Bewerten Sie Ihren Stand nicht nur nach der Anzahl erledigter Punkte. Ein Team mit vollständiger Protokollierung, aber ohne funktionierenden Not-Aus ist nicht bereit für einen physischen Agent-Piloten. Umgekehrt kann ein kleines Forschungsteam ohne MHS-Zugang bereits einen wertvollen Simulations- und Freigabeprozess aufbauen.

Ein Aktualisierungsboard verhindert falsche Termine

Für eine fortlaufende Beobachtung sollten Sie vier Quellenbereiche getrennt führen:

  • Anthropic Newsroom: neue Aussagen zur Forschungsphase, zur Bewerbung und zur geplanten Öffnung;
  • offizielle MHS-Seite: Antragsstatus, unterstützte Integrationswege und Sicherheitsanforderungen;
  • möglicherweise öffentliches Spezifikations- oder Normenarchiv: Versionen, Änderungsprotokolle und Konformitätsregeln;
  • Sicherheitsdokumentation: Anforderungen an menschliche Kontrolle, Berechtigungen, Tests und Vorfallbehandlung.

Prüfen Sie diese Bereiche wöchentlich und vergleichen Sie Formulierungen Satz für Satz. Eine Partnerankündigung kann einen Pilotversuch beschreiben, ohne eine allgemeine MHS-Freigabe zu bedeuten. Auch eine Demonstration mit Claude oder einem Roboter beweist nicht, dass Ihre eigene Anlage unterstützt wird.

Ordnen Sie jede Information einer der folgenden Spalten zu:

  • Bestätigt: direkt von Anthropic oder einer offiziellen Spezifikation veröffentlicht;
  • Antrag beziehungsweise Vorschau: nur für ausgewählte Einrichtungen oder nach Zulassung verfügbar;
  • Erwartung: externe Prognose, Partnerschaftshinweis oder technische Schlussfolgerung ohne Terminbindung.

Wenn eine allgemeine Öffnung offiziell angekündigt wird, sollten Sie diese Seite aktualisieren, statt eine weitere, inhaltsgleiche Nachricht zu veröffentlichen. Entscheidend sind dann nicht nur das Datum, sondern auch Umfang, Lizenz, unterstützte Gerätemodelle, Sicherheitsauflagen und die Frage, ob Konformitätstests öffentlich reproduzierbar sind.

Was Ihr aktueller Ansatz gegenüber einer Mac-Testumgebung verliert

Wenn Sie Agenten ausschließlich auf einem persönlichen Rechner, einem gemeinsam genutzten Bürogerät oder einer improvisierten Fernwartung testen, entstehen drei konkrete Nachteile: Zustände lassen sich schlechter reproduzieren, Berechtigungen werden häufig zu weit gefasst, und Fehlerprotokolle vermischen Entwicklung, Bedienung und Abnahme. Für kurze Hardware- und Desktop-Agent-Tests kann eine gemietete, klar getrennte Mac-Umgebung deshalb die sauberere Zwischenlösung sein als ein vorzeitiger Umbau auf eine unbestätigte MHS-Spezifikation.

SSHMac ist dabei kein Ersatz für MHS, keinen physischen Not-Aus und keine offizielle Gerätekompatibilität. Die Stärke liegt vielmehr in einer kontrollierbaren Testumgebung für Agent-Harness, Werkzeugrechte, Sitzungsprotokolle und reproduzierbare Abläufe. Für langfristige, gleichbleibende Schwerlast, spezielle physische Anschlüsse oder einen echten Produktionsroboter bleibt eigene Hardware mit fachlicher Aufsicht die passendere Wahl.