Der Agent arbeitet. Die Kontrolle über die endgültige Wirkung bleibt bei Ihnen.

Für wen es gedacht ist

Drei Angriffsflächen, ein Prinzip

Agenten dürfen Vorschläge machen. Die Autorität bleibt außerhalb des Agenten. Die Abdeckung beschränkt sich auf die deklarierten und getesteten Routen: SecureStamp kontrolliert keine Operationen, die diese Grenze umgehen, und benennt sie, statt sie zu verbergen.

Break the Mandate — die Schritt-für-Schritt-Anleitung

Die Einstiegsfrage ist einfach: Kann Ihr Agent etwas außerhalb der genehmigten Aufgabe tun? Das Referenzszenario beantwortet sie in fünf Schritten, auf synthetischen Fixtures, ohne Konto und ohne API-Schlüssel eines Modells.

1. 01

   Eine nützliche Aufgabe

   Der Agent bereitet eine echte Änderung innerhalb einer abgeschotteten Fixture vor.

2. 02

   Die Lücke in der Baseline

   Derselbe Versuch außerhalb des Auftrags entfaltet in einer bewusst permissiven Baseline seine Wirkung, beobachtet aus einem anderen Prozess. Es ist eine bekannte experimentelle Kontrolle, keine auf Ihrem Rechner entdeckte Schwachstelle.

3. 03

   Die Lücke, eingedämmt

   Bei aktiver Kontrolle wird diese Route eingedämmt, und die nützliche Aufgabe wird trotzdem abgeschlossen. Eine Ablehnung, die die Aufgabe nutzlos macht, zählt nicht als Wert.

4. 04

   Nachweise verfallen, wenn sich die Umgebung ändert

   Eine wesentliche Abhängigkeit des Profils ändert sich: Die früheren Nachweise berechtigen diese Route nicht mehr, bis sie erneut validiert wurde.

5. 05

   Nur der exakte Kandidat verlässt das System

   Der eingefrorene Kandidat wird geprüft. Wer seine Bytes oder sein Ziel ändert, macht den Export ungültig; wird das Genehmigte wiederhergestellt, ist die Wirkung zulässig.

Schnellstart

Doctor benötigt weder Docker noch ein Modell und führt nichts aus, was es liest. Das Referenzszenario ist synthetisch: Es führt nie Projektcode aus, und sein Bericht ist als simulierter Nachweis gekennzeichnet.

# Node 22.22.3 oder neuer
npm install --save-dev @securestamp/mcp-guard @securestamp/execution-governance

# 1. Doctor: statische Diagnose der Dateien, die Sie auswählen
npx securestamp-mcp-doctor scan .mcp.json --propose
npx securestamp-mcp-doctor scan-native <settings.json|config.toml> --format=<shape>
npx securestamp-mcp-doctor scan-workflow .github/workflows/agent.yml

# 2. Portables Szenario: die Referenz validieren und ausführen, mit einem Hold
npx securestamp-execution-governance validate scenario.json
npx securestamp-execution-governance run scenario.json --hold-before=step-1

Jeder Befehl gibt bei ungültigen Argumenten seine Verwendung und die unterstützten Formate aus. Für ein vollständiges HarnessProfileV1 verwenden Sie securestamp-mcp-doctor scan-harness. Mit --hold-before zeigt der Lauf eine angehaltene Wirkung, die nie zugelassen wird. Standardmäßig keine Telemetrie.

Doctor: zuerst Ihre nativen Dateien

Doctor liefert deklarierte Fakten, jeweils mit Quelldatei und Feld, sowie eine Teildiagnose, die angibt, welche Ebenen gelesen wurden und welche unbekannt bleiben. Kompatibilität wird als Form + Transport + getesteter Client beschrieben; ein nicht erkanntes Format wird als nicht unterstützt gemeldet und nie stillschweigend übersprungen.

• .mcp.json · JSON mit mcpServers (stdio)

  Deklarierte Befehle, Credential-Referenzen, in die Datei geschriebene Secrets, Shell-Starts sowie veränderliche oder @latest-Pakete. Eine gepinnte Version begründet keine Integrität: Den effektiven Artefakt mit dem genehmigten zu vergleichen, ist Aufgabe des Ausführenden.

• settings.json · config.toml ([mcp_servers])

  Berechtigungen, Tools und erkannte Konfigurationsebenen, mit Konflikten und fehlenden Daten. Eine einzelne Datei verrät keine verwalteten Richtlinien, CLI-Overrides oder geerbte Konfiguration: Die Ausgabe weist darauf hin.

• .github/workflows/*.yml

  Agent Workflow Doctor: nicht vertrauenswürdige Eingaben aus Issues, PRs oder Kommentaren, die den Agenten erreichen, deklarierte Berechtigungen, Secret-Referenzen, weit gefasste Tools und der Checkout externer Inhalte. Es lädt keine Actions herunter, löst keine Secrets auf und führt kein YAML aus.

• HarnessProfileV1

  Das vollständige Profil für fortgeschrittene Nutzer. Doctor erfindet es nie aus einer einzelnen Datei: Mounts, Beobachter, effektive Credentials und Backend werden vom Betreiber gewählt und validiert.

• Liest nur die Dateien, auf die es verwiesen wird; es durchsucht nicht das Home-Verzeichnis.
• Führt keine Befehle, Hooks oder Ausdrücke aus der Datei aus.
• Löst keine Secrets auf und validiert keine Tokens.
• Schlägt einen prüfbaren Patch auf einer Kopie vor; überschreibt nie das Original.
• Zeigt ein unauffälliges Ergebnis mit demselben Gewicht wie einen Befund.
• Eine statische Diagnose begründet weder Isolation noch Schutz.

Exact Export: der Agent bereitet vor, Sie autorisieren die exakte Änderung

Der Agent bereitet die Änderung in einer abgeschotteten Kopie Ihres Projekts vor. Das Export-Credential bleibt außerhalb seiner Umgebung, und nur der geprüfte Kandidat verlässt das System, über den Execution Guardian.

1. 01

   Vorbereiten

   In Quarantäne, auf einem Snapshot des gewählten Projekts; Ihr .git wird nie als vertrauenswürdige Basis wiederverwendet.

2. 02

   Einfrieren

   Der Kandidat wird vor der Prüfung festgelegt: Basis, Bytes und Digests, Ref, Ziel und vorheriger Zustand.

3. 03

   Autorisieren

   Die Freigabe ist an diesen Kandidaten gebunden. Eine spätere Änderung macht sie ungültig; ein --yes ersetzt weder MFA noch Quorum.

4. 04

   Ausführen

   Vom Guardian in Verwahrung gehalten, mit Prüfung des Zustands am Ziel: Drift und Races werden nie überschrieben.

5. 05

   Verifizieren

   Unabhängige Verifikation der Postcondition und ein Beleg, den Sie dem PR oder Issue beifügen.

Das anfängliche Ziel ist ein lokales Git-Repository. Mit einem autorisierten Profil und Ziel legt der GitHub-Adapter einen neuen Ref an: Er aktualisiert keinen Branch, führt kein Force-Push, kein Merge und kein Deploy aus, und das Öffnen eines PR ist eine eigene Wirkung mit eigener Autorisierung. Die Verwahrung des Credentials wird nur für das Profil behauptet, das sie mit effektiver Identität, Mounts, Sockets und Netzwerk sowie Canaries aus dem Kontext des Agenten nachweist.

Eine portable Konfiguration, drei Schnittstellen

Die Konfiguration ist eine JSON-Datei, die in Ihrem Repository versioniert wird. Die Bibliothek erzeugt die vollständigen Verträge und ihre Digests; niemand schreibt Signaturen von Hand. CLI und Dashboard importieren und exportieren dieselbe Darstellung und durchlaufen dieselbe Validierung: Es gibt keine Web-Richtlinie, die von der Richtlinie in Git abweicht. Jede Änderung erzeugt eine neue Revision, und aktive Läufe behalten ihren Snapshot.

• npm · @securestamp/execution-governance

  Portable Szenariovarianten als Verträge, eine Kontrollebene mit Hold, Resume und Stop sowie geschwärzte Berichte: Szenarien validieren und serialisieren, Läufe starten, idempotente Anweisungen ausgeben und Berichte erstellen, verifizieren und vergleichen. Es verleiht keine Befugnis, schließt den Host nicht ein und ersetzt nicht den Guardian des Kunden.

• CLI · securestamp-mcp-doctor · securestamp-execution-governance

  scan, scan-native, scan-workflow und scan-harness für die Diagnose; validate und run für Szenarien. Kein Konto. Jeder Lauf erzeugt seinen eigenen Bericht, ohne einen anderen zu überschreiben.

• Dashboard · securestamp.online/dashboard/agents

  Szenarien, Vorbereitung, Läufe, Live-Detail und Analyse nach dem Lauf, auf registrierten Runnern, die der Kunde betreibt. Der Browser führt den Test nicht aus und erhält keine Anbieter-Credentials; das Verbinden eines Runners ist optional.

Hold, Resume, Stop

Die Steuerungen wirken auf die vom Guardian vermittelten Routen. Der Agent kann weiter schlussfolgern, während seine Wirkungen angehalten sind; die Oberfläche zeigt dies als „Wirkungen angehalten / Prozess läuft“ und nie als eingefrorenen Agenten.

Eine erfolgreiche HTTP-Antwort bestätigt nur, dass der Befehl empfangen wurde. Das Dashboard zeigt getrennt an, was angefordert, was vom Supervisor angewendet und was beobachtet wurde. Bricht der Remote-Kanal ab, während der Beobachter gesund ist, bleiben die Zulassungen lokal angehalten; fällt der Beobachter aus, unterbindet das Profil den Egress und beendet den Container. Der lokale Stop hängt nie vom Dashboard ab.

Berichte: Zustände, die nicht zu einer Ampel zusammenfallen

Der Ausführungsbericht trägt nur eine informative Prüfsumme, deklariert seine Nachweisstufe und erlaubt Laufvergleiche; eine Prüfsumme authentifiziert keinen Aussteller. Wenn ein vollständiges Action-Proof-Bundle angehängt ist, prüft der unabhängige Verifier es offline mit außerhalb des Berichts gelieferten Vertrauensankern und bindet Kandidat, Ziel, Autorität und beobachtetes Receipt-Ergebnis. FAIL, SKIP, fehlende Evidenz und nicht bewertete Routen bleiben sichtbar; ein Instrumentierungsfehler ergibt INCOMPLETE, nie PASS.

Informativer Pull-Request-Check

Vergleicht Base und Head der nativen Dateien mit denselben Importern und Regeln, zeigt deklarierte Änderungen, Unbekanntes und Kandidaten für eine erneute Validierung und validiert einen beigefügten Beleg gegen seine Anker. Er läuft von einer gepinnten, vertrauenswürdigen Revision aus, mit Leserechten, ohne Secrets und ohne Code aus dem PR auszuführen. Er dient der Information für das Review: Er ist nicht der Check, der einen Export autorisiert, und ersetzt weder den Guardian noch ein Ruleset.

Was dies nicht leistet

• Es macht das Modell nicht sicher und beweist keine allgemeine Alignment: Es testet Ausführungsgrenzen auf einem deklarierten Profil.
• Es kontrolliert keine Routen, die den Guardian umgehen; eine Route ohne Probe bleibt not evaluated und gilt nie durch Vererbung als geschützt.
• Es macht keine bereits eingetretene Wirkung rückgängig: Hold und Stop sind kein Rollback.
• Ein Beleg zeigt Integrität und Geltungsbereich unter seinen Ankern; er zeigt weder, dass der genehmigte Code harmlos ist, noch dass ihn jemand Unabhängiges auditiert hat.
• Es ist kein unternehmensweiter Kill-Switch: v1 steuert den gewählten Lauf und seine deklarierten Runner.
• Die Kompatibilität wird pro Profil, Version und Umgebung veröffentlicht. Ein PASS auf einem Harness überträgt sich nicht auf ein anderes Betriebssystem, eine andere Route oder einen anderen Client.

Weiterlesen