Kann die Skriptfreigabe für KI-Agenten einem signierten Interpreter vertrauen?

Ein signierter Interpreter beweist nicht, welches Skript du genehmigt hast. Er beweist etwas Engeres: Das Betriebssystem hat eine bestimmte Interpreter-Binärdatei gestartet, deren Signatur es prüfen konnte. Der Interpreter kann anschließend beliebig viele veränderliche Dateien lesen, Quelltext aus einem Befehlsstring übernehmen, Code über einen Paketauflöser laden und mit Zugangsdaten handeln, die das Skript selbst nie besaß.

Diese Unterscheidung geht verloren, wenn eine Genehmigungskarte „Python“ oder „Node“ anzeigt und dazu ein beruhigendes Signatursymbol einblendet. Ich habe erlebt, dass Prüfer diese Abfrage genehmigten, weil der Name der Binärdatei vertraut war. Später verbrachten sie den unangenehmen Teil des Nachmittags damit herauszufinden, welches Repository-Checkout, welcher Symlink, welche Umgebungseinstellung oder welcher vorgeladene Paketcode den eigentlichen Quelltext geliefert hatte. Vertraute ausführbare Dateien verdienen das Maß an Vertrauen, das zu ausführbaren Dateien passt. Sie machen beliebigen Quelltext nicht vertrauenswürdig.

Ein signierter Interpreter identifiziert nur den Interpreter

Codesignaturen beantworten eine Herkunftsfrage zu einer ausführbaren Datei. Unter macOS kann das Tool codesign die Signatur und die designierte Anforderung einer ausführbaren Datei prüfen. Gatekeeper und die Laufzeitschutzmechanismen der Plattform verwenden verwandte Informationen, wenn sie Software bewerten. Keine dieser Mechanismen bestätigt, dass eine über die Befehlszeile übergebene Python-Datei vom selben Entwickler stammt, seit der Prüfung unverändert geblieben ist oder gutartige Imports verwendet.

Betrachte diese beiden Aufrufe:

/usr/bin/python3 /Users/dev/work/release/publish.py
/usr/bin/python3 -c "import os; os.system('curl ...')"

Die Identität des Interpreters kann in beiden Fällen gleich sein. Die Identität des Quelltexts ist völlig verschieden. Der erste Aufruf enthält einen Pfad, der einem Prüfer helfen kann, den Code zu finden. Der zweite hat überhaupt keine Skriptdatei. Eine Abfrage, die beide Aufrufe auf „signiertes Python fordert Netzwerkzugriff an“ reduziert, entfernt genau den Teil, den ein Mensch bewerten muss.

Die Python-Dokumentation beschreibt getrennte Befehlszeilenformen zum Ausführen einer Datei, eines Befehls mit -c, eines Moduls mit -m und von Quelltext über die Standardeingabe. Das ist normales Verhalten eines Interpreters, kein Fehler. Der Fehler besteht darin, diese Formen so zu behandeln, als stünde hinter allen dasselbe stabile, signierte Programm.

Dasselbe Problem tritt bei der Prozessidentität auf. Ein Genehmigungssystem kann dir korrekt mitteilen, dass ein Agent-Prozess von einer dir bekannten Codesignatur-Autorität stammt. Daraus lässt sich trotzdem nicht ableiten, dass jede lokale Datei, die der Prozess von einem Interpreter ausführen lässt, dieselbe Genehmigung verdient. Aufruferidentität und Quelltextidentität beantworten unterschiedliche Fragen:

• Die Aufruferidentität fragt, wer die Anfrage gestartet hat.
• Die Interpreteridentität fragt, welche Binärdatei den Quelltext verarbeitet.
• Die Quelltextidentität fragt, welche Bytes der Interpreter verarbeitet.
• Die Aktionsidentität fragt, welcher Host, API-Endpunkt, Account oder Befehl die resultierende Anfrage erhält.

Wenn auf dem Prüfbildschirm nur Platz für die ersten beiden Angaben ist, entsteht ein falsches Gefühl von Genauigkeit. In der Praxis entscheiden Quelltext und Aktion darüber, ob die Anfrage akzeptabel ist.

Das Prüfziel ist ein Ausführungs-Tupel

Ein Prüfer braucht eine stabile Beschreibung der exakten Ausführung, kein freundliches Label. Ich nenne diese Beschreibung ein Ausführungs-Tupel: der aufgelöste Interpreter, seine Argumente, das Quellartefakt, der Ausführungskontext und die angeforderte externe Aktion. Ändert sich ein wesentliches Mitglied des Tupels, handelt es sich um eine andere Ausführung, die eine neue Entscheidung erfordert.

Für einen dateibasierten Python-Aufruf sieht das minimale nützliche Tupel so aus:

{
  "caller": {
    "pid": 48172,
    "signing_authority": "Example Development Team"
  },
  "interpreter": {
    "resolved_path": "/usr/local/bin/python3.12",
    "signing_identity": "Python Software Foundation",
    "sha256": "c44e...9a10"
  },
  "argv": ["/usr/local/bin/python3.12", "/private/var/run/gateway-src/publish.py"],
  "source": {
    "display_path": "/Users/dev/work/release/publish.py",
    "sha256": "6ab1...ee42"
  },
  "context": {
    "working_directory": "/Users/dev/work/release",
    "environment": {"DEPLOY_ENV": "staging"}
  },
  "requested_action": "POST https://api.example.invalid/releases"
}

Die verkürzten Digest-Werte gehören auf die Genehmigungskarte, der vollständige Digest ins Journal. Ein Prüfer braucht meist den lesbaren Pfad sowie einen Diff oder eine Quelltextvorschau. Ein Ermittler braucht einen eindeutigen Wert, der später verglichen werden kann.

Nimm nicht jede Umgebungsvariable auf die Karte. Sonst wird aus einer Entscheidung ein Sehtest. Erfasse Werte, die die Codeauswahl, die Befehlsauflösung, Zugangsdaten, Proxy-Routing, Zielauswahl oder Feature-Schalter beeinflussen. Für Python können dazu PYTHONPATH, PYTHONHOME und ein ausdrücklich angegebener Konfigurationspfad gehören. Bei der Shell-Ausführung sind es oft PATH, das aktuelle Verzeichnis und Variablen, die in den Befehl eingesetzt werden. Speichere die vollständige Umgebung in geschützten Audit-Daten, wenn es dein Bedrohungsmodell verlangt, und zeige dem Menschen die wesentliche Teilmenge.

Hier verwischen Teams oft eine zweite Unterscheidung: Reproduzierbarkeit ist keine Autorisierung. Eine Lockdatei, ein Git-Commit oder ein Container-Image kann helfen, die ausgeführte Variante zu reproduzieren. Daraus folgt nicht, dass dieser Code die Produktion aufrufen, einen entfernten Branch löschen oder eine SSH-Sitzung öffnen darf. Verknüpfe die Quelltextidentität mit einer klaren Aktionsanfrage.

Python kann Code hinter gewöhnlichen Startern verbergen

Python lässt einen einfachen Datei-Aufruf unkomplizierter wirken, als er ist. python deploy.py zeigt, wo die Ausführung beginnt. Der Interpreter kann Module jedoch aus dem Skriptverzeichnis, installierten Paketen, konfigurierten Suchpfaden und aus Code laden, den die Anwendungslogik auswählt. Eine virtuelle Umgebung kann außerdem ändern, auf welchen Interpreter ein nicht vollständig qualifiziertes python verweist.

Löse die ausführbare Datei auf, bevor du ihre Signatur bewertest. Die Bezeichnungen python, python3 oder venv/bin/python sind keine Identität. Ein Launcher kann ein Symlink, ein Shim oder nach einer Toolchain-Aktualisierung eine andere Binärdatei sein. Das Gateway sollte das Objekt auflösen, das der Kernel starten wird, dieses Objekt prüfen und seinen Pfad sowie Digest festhalten.

Behandle den Quellpfad anschließend als Orientierungshilfe, nicht als Sicherheitsgrenze. Löse Symlinks für den Prüfdatensatz an einen kanonischen Ort auf, führe nach der Prüfung aber nicht das veränderliche Original aus. Ein Repository-Checkout kann deploy.py ersetzen, ohne den Pfad zu ändern. Ein Symlink kann auf ein anderes Ziel zeigen. Eine Pfadprüfung erkennt keines dieser Ereignisse allein.

Eine praktikable Abfolge sieht so aus:

1. Lies die angeforderten Skript-Bytes und berechne SHA-256.
2. Kopiere diese Bytes in ein privates, vom Gateway verwaltetes Verzeichnis mit restriktiven Berechtigungen.
3. Zeige den Pfad des Aufrufers, den kanonischen Pfad, den Digest und eine Quelltextvorschau zur Genehmigung an.
4. Starte den geprüften Interpreter mit der privaten Kopie und ordne das Ergebnis anschließend diesem Digest zu.

Diese Kopie ist keine Beschäftigungstherapie. Sie schließt die Lücke zwischen Prüfung und Verwendung. Wenn der Prüfer den Digest 6ab1...ee42 genehmigt hat, muss der Interpreter die Bytes mit genau diesem Digest lesen. Das Hashen der Repository-Datei und ein späteres erneutes Lesen derselben Datei durch Python lässt ein kleines, aber reales Zeitfenster für einen Austausch offen.

Auch Imports brauchen eine Entscheidung. Wenn publish.py ein lokales release_helpers.py importiert, kann ein geänderter Helfer das Verhalten verändern, obwohl die Einstiegsdatei unverändert bleibt. Die strenge Variante ist ein Quellmanifest, das jedes für diese Ausführung erlaubte lokale Modul enthält. Für Routinearbeiten ist eine praktischere Variante, das Einstiegsskript und seinen deklarierten lokalen Paketbaum gemeinsam bereitzustellen, Imports außerhalb dieses bereitgestellten Baums abzulehnen und bei einer Änderung des Manifest-Digests eine neue Genehmigung zu verlangen.

Tu nicht so, als würden damit dynamische Imports, native Erweiterungen, sitecustomize oder beliebiger zur Laufzeit abgerufener Code erfasst. Das ist nicht der Fall. Die Genehmigungsansicht sollte solche Freigaben benennen, wenn es sie gibt. Ein Skript mit importlib.import_module(os.environ["PLUGIN"]) hat nicht dieselbe umfassende Genehmigung verdient wie ein in sich geschlossenes Skript, nur weil beide mit demselben signierten Interpreter beginnen.

Die Einstiegdatei von Node ist nur ein Teil des Programms

Node fügt eine andere Ebene der Mehrdeutigkeit hinzu. node task.js hat zwar eine Einstiegsdatei, doch die Modulauflösung kann Code über package.json, Paket-Exports, Lockdateien, Symlinks und das aktuelle Verzeichnis auswählen. Die Node-CLI-Dokumentation beschreibt außerdem Preloads wie --require und --import. Sie können Code ausführen, bevor die Einstiegsdatei beginnt.

Deshalb muss ein Prüfsystem den vollständigen Argumentvektor anzeigen, nicht nur den abschließenden .js-Pfad. Diese Aufrufe verdienen eine unterschiedliche Prüfung:

node tools/publish.mjs
node --import ./tools/setup.mjs tools/publish.mjs
node --require ./tools/patch.cjs tools/publish.mjs
node -e "require('child_process').execSync(process.argv[1])" "git push --force"

Ein Prüfer, der nur tools/publish.mjs sieht, übersieht im zweiten und dritten Aufruf Code, der vorher ausgeführt wird. Beim letzten Aufruf gibt es keine geprüfte Einstiegsdatei. Der Befehlsstring ist das Quellartefakt und muss als solches angezeigt, gespeichert und gehasht werden.

Die Umgebungsvariable NODE_OPTIONS verdient dieselbe Behandlung. Node dokumentiert sie als Möglichkeit, erlaubte Befehlszeilenoptionen über die Umgebung zu übergeben. Wenn ein Prozess darüber Preloads oder Debugging-Verhalten einschleusen kann, hat ein Gateway, das sie ignoriert, einen unvollständigen Befehl geprüft. Du musst Prüfer nicht mit jeder Laufzeiteinstellung verunsichern. Du musst aber solche Einstellungen sichtbar machen, die Code laden oder die Zielauswahl verändern.

Paketmanager schaffen eine weitere Falle. npm run publish wirkt oft wie eine benannte Aufgabe. Tatsächlich stammt das Verhalten aus einer veränderlichen package.json, ihren Skripten, der Lockdatei, Hooks des Paketmanagers und Binärdateien im Abhängigkeitsbaum des Projekts. Ein Aufgabenname muss vor der Genehmigung aufgelöst werden. Zeige den aufgelösten Befehl, die Projektversion oder das bereitgestellte Manifest und jeden auszuführenden Lebenszyklus-Hook. Wenn diese Auflösung nicht möglich ist, verlange eine engere Genehmigung oder lehne die Anfrage ab. „Paket-Skript ausführen“ beschreibt keine sinnvolle Aktion, wenn sich die Paketdatei unterdessen ändern kann.

Für wiederholbare Node-Automatisierung solltest du einen geprüften Workspace-Snapshot bereitstellen oder ein unveränderliches Build-Artefakt verwenden. Ein Hash von publish.mjs allein reicht nur, wenn das Skript keine lokalen Abhängigkeiten und keinen Preload-Pfad hat. Die meisten anspruchsvolleren Projekte erfüllen diese Bedingung nicht.

Shell-Strings müssen wie Quelltext behandelt werden

Shell-Anfragen scheitern bei der Prüfung, wenn man sie als Befehle statt als Programme bezeichnet. sh -c verarbeitet einen Quelltextstring mit Expansionen, Substitutionen, Umleitungen, Pipelines, Funktionen und Befehlsauflösung. Der String kann kurz sein und trotzdem eine unbegrenzte Folge weiterer Programme aufrufen.

Vergleiche diese Anfragen:

/bin/sh -c 'curl -fsS "$RELEASE_URL" | sh'
/bin/sh /private/var/run/gateway-src/release.sh

Die erste Anfrage braucht den exakten Befehlsstring, jeden wesentlichen Umgebungswert und eine Erklärung, was das nachgelagerte Programm erhält. Die zweite braucht für Skriptpfad und Inhalt dieselbe Behandlung wie Python oder Node. Die Signatur von /bin/sh sagt dir, wer den Parser bereitgestellt hat. Sie erklärt keine der beiden Eingaben für sicher.

Genehmige einen Shell-Befehl nicht anhand seines ersten Verbs. git status kann in einem exakt passenden Argumentvektor harmlos sein, während git -c credential.helper=... die Eingaben verändert, die Git lädt. curl kann Daten abrufen, eine Datei schreiben oder Bytes in einen anderen Interpreter weiterleiten. Ein Prüfer braucht genug Syntax, um Umleitungen und Substitutionen zu erkennen, und genug Ausführungskontext, um zu sehen, wie Programme aufgelöst werden.

PATH wird oft übersehen. Ein Skript, das deploy ohne absoluten Pfad aufruft, überlässt die Auswahl der ausführbaren Datei der Umgebung. Wenn die Anfrage aus einem Agent-Workspace kommt, kann ein Angreifer, der diesen Workspace verändern darf, ein Programm weiter vorne in PATH platzieren. Erfasse nach Möglichkeit für jedes sicherheitsrelevante Unterkommando den aufgelösten Pfad der ausführbaren Datei. Wenn eine vollständige Shell-Auswertung selbst unsicher oder zu unberechenbar wäre, verwende eine eingeschränkte Befehlsschnittstelle, statt einen perfekten Shell-Parser bauen zu wollen.

Dieser letzte Punkt spricht gegen eine verbreitete Empfehlung: „Einfach eine signierte Shell erlauben und bei jedem Aufruf nachfragen.“ Sie ist beliebt, weil es die Shell überall gibt und die Genehmigung einfach wirkt. Sie ist falsch, weil eine einzelne Genehmigung kein stabiles Quellobjekt hat, solange das System nicht den exakten String oder ein unveränderliches Skript sowie den wesentlichen Kontext festhält. Eine Genehmigung pro Aufruf kann mit bewundernswerter Konsequenz trotzdem das Falsche genehmigen.

Ein Inhalts-Hash braucht eine Datei, an die er tatsächlich gebunden ist

Ein Hash ist ein Beleg für Bytes, aber kein Beweis dafür, dass das beabsichtigte Programm sie verwenden wird. Die Implementierung muss die geprüften Bytes an die Ausführung binden. An dieser Stelle scheitern viele ansonsten sorgfältige Entwürfe.

Das unsichere Muster ist leicht zu erkennen:

1. Read /workspace/scripts/publish.py
2. Calculate and display SHA-256
3. Wait for approval
4. Run python /workspace/scripts/publish.py

Zwischen den Schritten 2 und 4 kann ein anderer Prozess die Datei bearbeiten, einen Symlink ersetzen oder ein eingebundenes Verzeichnis ändern. Der Genehmigungsdatensatz bleibt zwar für das korrekt, was der Prüfer gesehen hat, sagt aber nichts Verlässliches über das aus, was ausgeführt wurde.

Verwende stattdessen eines dieser Modelle:

• Kopiere die geprüften Bytes in ein privates Ausführungsverzeichnis, setze die Berechtigungen so, dass der anfragende Prozess sie nicht ändern kann, und führe die Kopie aus.
• Führe ein zuvor erstelltes unveränderliches Artefakt aus, dessen Digest geprüft und gespeichert wurde.
• Halte ein bereits geöffnetes Dateiobjekt nur dann durch Prüf- und Ausführungspfad, wenn Interpreter und Betriebssystem die Ausführung genau dieses Objekts ermöglichen, ohne einen veränderlichen Pfad erneut aufzulösen.

Das Modell mit der privaten Kopie ist meist leichter zu erklären und zu prüfen. Es liefert außerdem ein stabiles Artefakt für die Untersuchung von Vorfällen. Bewahre den ursprünglichen Anzeigepfad als Kontext auf, denn Menschen müssen wissen, welche Projektdatei den Lauf ausgelöst hat. Verwechsle ihn aber nicht mit den Bytes, die ausgeführt wurden.

Inhalts-Hashing hat Grenzen, die sichtbar bleiben sollten. Es kann nicht entscheiden, ob Quelltext sicher ist. Es kann Antworten aus dem Netz, zeitabhängiges Verhalten, Zufallswerte oder nach dem Hashing geladenen Code nicht stabilisieren. Es verhindert eine bestimmte Art von Genehmigungsfehler: eine lokale Skriptversion zu prüfen und eine andere auszuführen. Das ist eine sinnvolle Grenze, sofern du sie ehrlich beschreibst.

Verwende SHA-256 oder einen anderen aktuellen kryptografischen Digest mit einer festgelegten Kodierung und nenne in den Datensätzen immer den Algorithmus. Eine bloße Hexadezimalzeichenfolge führt später leicht zu Verwirrung. Ein Digest-Datensatz sollte sha256:6ab1...ee42 lauten, nicht nur 6ab1...ee42.

Genehmigungskarten sollten die verwertbaren Belege zeigen

Eine gute Genehmigungskarte ermöglicht eine schnelle Entscheidung, ohne die Fakten zu verbergen, die diese Entscheidung beeinflussen. Stelle einen Datei-Hash nicht an den Anfang. Menschen können einen Hash nicht anhand seines Aussehens bewerten. Beginne mit der angeforderten Aktion und dem Aufrufer, und zeige anschließend Interpreter, Quellort, Quellstatus und den wesentlichen Ausführungskontext.

Für eine Deployment-Anfrage könnte eine kompakte Karte so aussehen:

Caller: signed process from Example Development Team, PID 48172
Action: POST release data to api.example.invalid
Interpreter: /usr/local/bin/python3.12, signed by Python Software Foundation
Source: /Users/dev/work/release/publish.py
Reviewed bytes: sha256:6ab1...ee42
Execution copy: /private/var/run/gateway-src/6ab1...ee42/publish.py
Context: DEPLOY_ENV=staging, working directory /Users/dev/work/release

Die Karte sollte eine Quelltextvorschau oder einen Diff zur zuletzt genehmigten Digest-Version anbieten. Für wiederholte Arbeiten ist ein Diff oft besser, weil er die Aufmerksamkeit auf die geänderten Zeilen lenkt. Der vollständige Quelltext sollte trotzdem auf Anfrage verfügbar sein. Eine irreführend gekürzte Vorschau ist schlechter als gar keine Vorschau.

Vermeide vage Genehmigungsbezeichnungen wie „Deployment-Tools erlauben“ oder „Python-Zugriff erlauben“. Sie bringen Menschen dazu, aufgrund des Markennamens weiterzuklicken. Eine Entscheidung sollte auch ihre Gültigkeitsdauer nennen. Ein einzelner Lauf, eine Prozesssitzung und die Freigabe eines geprüften Artefakts sind unterschiedliche Geltungsbereiche. Eine Sitzungsgenehmigung für einen Agent-Prozess kann die Abfragemüdigkeit verringern. Jedes Skript, dessen Digest sich ändert, sollte jedoch eine neue Quelltextentscheidung auslösen, bevor es die externe Berechtigung erneut verwenden darf.

Das unterscheidet sich von einer Regel-Engine. Du brauchst keine Sprache, mit der Menschen Bedingungen wie „sichere Skripte erlauben“ schreiben. Du brauchst ein festes Prüfobjekt, das sich nach der Genehmigung nicht unbemerkt erweitern kann. Das System sollte dieses Objekt aus den aufgelösten Eingaben erstellen, anzeigen und die Ausführung daran binden.

Abhängigkeitsgrenzen müssen ausdrücklich festgelegt werden

Der Digest eines Einstiegsskripts kann ausreichen, wenn die Codegrenze des Programms tatsächlich nur aus dieser einen Datei besteht. Behandle das als Ausnahme, nicht als Standard. Python-Imports, Node-Module, Shell-source-Befehle, Vorlagen, Konfigurationsdateien und ausführbare Plugins können das Verhalten ändern, nachdem der Einstiegspunkt geprüft wurde.

Lege die Grenze nach den Folgen der Aktion fest. Für einen risikoarmen Lesezugriff auf einen Entwicklungsdienst kannst du ein bereitgestelltes Einstiegsskript akzeptieren und ausdrücklich festhalten, dass es installierte Pakete importieren darf. Für einen Schreibzugriff auf die Produktion oder einen SSH-Befehl solltest du lokale Quellabhängigkeiten in ein Manifest aufnehmen, externe Abhängigkeiten festlegen und das Herunterladen ausführbaren Codes zur Laufzeit ablehnen. Der Datensatz sagt dann, was du mit „dem Skript“ gemeint hast.

Ein einfaches Manifest kann relative Pfade und Digests enthalten:

sha256  publish.py  6ab1...ee42
sha256  release_helpers.py  9d07...1a3c
sha256  config/targets.json  743e...64b1

Das Gateway sollte dieses Manifest aus bereitgestellten Kopien oder einer kontrollierten Build-Eingabe berechnen, statt ein Manifest zu akzeptieren, das aus demselben veränderlichen Workspace stammt. Wenn ein Projekt eine Lockdatei als Teil seiner Grenze festlegt, hash auch diese Lockdatei. Eine Lockdatei hilft nur, wenn die Laufzeit sie berücksichtigt und der geprüfte Prozess keinen anderen Abhängigkeitsbaum einsetzen kann.

Irgendwann ist die lokale Ausführung über einen Interpreter für eine Ein-Klick-Entscheidung zu weit gefasst. Wenn Code Plugins aus beliebigen Verzeichnissen finden, entfernte Inhalte abrufen und ausführen oder generierte Skripte schreiben und anschließend starten kann, teile die Arbeit auf. Genehmige einen Build, der ein unveränderliches Artefakt erzeugt, prüfe die darin deklarierte Aktion und genehmige diese Aktion anschließend. Diese zusätzliche Grenze ist günstiger, als eine unbeabsichtigte Änderung in der Produktion rekonstruieren zu müssen.

Logs müssen festhalten, was lief, nicht wie die Oberfläche es nannte

Wenn eine Aktion schiefgeht, lautet die erste nützliche Frage meist: „Was genau lief mit dieser Berechtigung?“ Ein Journaleintrag mit „Python genehmigt“ kann sie nicht beantworten. Bewahre das Ausführungs-Tupel, den Geltungsbereich der Entscheidung, die Interaktion mit dem Prüfer, Zeitstempel und das beobachtete Ergebnis auf. Schwärze Geheimnisse im Datensatz, aber nicht die Identität des Quellartefakts oder der Zielaktion.

Ein guter Datensatz verknüpft zusammengehörige Ereignisse. Der Sitzungseintrag identifiziert den Agent-Prozess und seine Berechtigung. Der Aktionsdatensatz identifiziert Interpreter, Digest des bereitgestellten Quelltexts, Argumente, Ziel und Ergebnis. Wenn ein Prüfer eine Sitzung widerruft, sollte dieses Ereignis mit derselben Sitzungsidentität verknüpft sein. Sonst können Betreiber nicht erkennen, ob der Widerruf den anfragenden Prozess gestoppt hat, der den Aufruf ausgelöst hatte.

Manipulationsnachweise verbessern die Qualität des Datensatzes. Ein hashverkettetes Journal kann spätere Änderungen erkennbar machen, fehlende Felder aber nicht nachträglich ergänzen. Prüfe die Kette und frage trotzdem, ob der Datensatz den aufgelösten Pfad, den Quell-Digest, den Kontext und die tatsächliche Aktion enthält. Integrität bewahrt Belege. Sie erzeugt keine Belege, die das System nie erfasst hat.

Sallyports getrennte Journale sind hier nützlich, weil sie den Agent-Lauf von einzelnen HTTP- oder SSH-Aufrufen trennen und beide aus einem verschlüsselten, hashverketteten Audit-Log abbilden. Mit sp audit verify kann die Kette offline über den Chiffretext geprüft werden. Das ist die richtige Eigenschaft, um festzustellen, ob sich gespeicherte Belege nachträglich verändert haben.

Behandle Quelltextänderungen als neue Berechtigung

Der sicherste Standard ist einfach: Wenn sich der Quell-Digest ändert, verlange für eine externe Aktion eine neue Entscheidung. Übertrage eine frühere Skriptgenehmigung nicht stillschweigend, nur weil Pfad, Interpreter, Projektname oder Prozesssignatur vertraut wirken.

Diese Regel erzeugt während der aktiven Entwicklung einige zusätzliche Abfragen. Das ist sinnvoll. Eine Codeänderung verändert die Berechtigung, wenn der Code eine Zugangsdaten verwenden, einen entfernten Dienst verändern oder einen SSH-Befehl ausführen kann. Die Lösung besteht nicht darin, jede Abfrage zu unterdrücken. Verbessere das Prüfartefakt, stelle deterministischen Quelltext bereit und erteile dem Prozess nur dann eine umfassendere Sitzungsberechtigung, wenn der Quelltext unabhängig identifiziert bleibt.

Für Teams mit einem Aktions-Gateway sollte die Sperre auf den Punkt fokussiert sein, an dem Zugangsdaten den lokalen Rechner verlassen. Der Agent sollte eine HTTP-Anfrage oder einen SSH-Befehl mit einem quellengebundenen Prüfdatensatz anfordern, während das Gateway die Zugangsdaten verwahrt und das Ergebnis zurückgibt. So müssen Geheimnisse nicht an ein veränderliches Skript übergeben werden. Trotzdem muss klar bleiben, welcher Code die Aktion angefordert hat.

Beginne mit deinem sensibelsten Interpreter-Aufruf. Löse die Binärdatei auf, zeige die vollständigen Argumente an, hashe und stelle die tatsächlichen Quelltext-Bytes bereit, erfasse den wesentlichen Kontext und behandle einen geänderten Digest als geänderte Genehmigung. Sobald dieser Datensatz vorhanden ist, wird ein signierter Interpreter zu einem nützlichen Beleg in einer vollständigen Entscheidung statt zu einem beruhigenden Label über einem unbekannten Skript.