Welcher tatsächliche Agent-Prozess fordert die Freigabe an?

Eine Freigabeaufforderung mit der Bezeichnung «Terminal» oder «zsh» ist meist zu ungenau für eine echte Entscheidung. Diese Programme können Teil des Startpfads sein, dienen aber oft nur als gemeinsam genutzte Infrastruktur. Ein Prüfer muss wissen, welcher Agent-Lauf die Aktion angefordert hat, was ihn gestartet hat und ob es in dieser Kette etwas gibt, das der Anfrage eine dauerhafte Identität verleiht.

Die Schwierigkeit besteht darin, dass ein Prozessbaum mehrere Fragen gleichzeitig beantwortet. Er kann zeigen, welcher Prozess welchen anderen erzeugt hat. Er kann einen Task Runner sichtbar machen, den niemand erwartet hat. Er kann zeigen, dass eine grafische IDE das Terminal gestartet hat. Er kann jedoch nicht allein beweisen, dass ein signierter übergeordneter Prozess jede Codezeile freigegeben hat, die ein untergeordneter Prozess ausführen wird. Eine gute Freigabegestaltung nutzt den Baum als Beleg und formuliert anschließend genau die begrenzte Aussage, die sich daraus ableiten lässt.

Die Freigabe gilt einem Akteur, nicht einem Terminal

Der Akteur, den ein Prüfer freigibt, ist der Prozesslauf, der die Aktion angefordert hat, betrachtet im Kontext seines Startpfads. Ein Terminalfenster ist ein Ort, an dem Prozesse laufen. Es ist nicht automatisch das verantwortliche Programm.

Diese Unterscheidung wirkt kleinlich, bis ein Team mehrere Agents aus derselben Shell ausführt. Ein Entwickler öffnet ein Terminal in iTerm2, startet in einem Tab einen interaktiven Coding-Agent, führt in einem zweiten eine Repository-Aufgabe aus und lässt in einem dritten einen Hintergrund-Überwachungsprozess laufen. Alle drei Nachkommen können irgendwo über sich dieselbe Terminal-Anwendung haben. Jede Anfrage «iTerm2» zu nennen, sagt dem Prüfer fast nichts.

Der umgekehrte Fehler ist ebenso häufig. Ein Prüfer sieht node, python oder zsh und nimmt an, dass die Binärdatei direkt vor der Anfrage die gesamte Identität darstellt. Diese Binärdatei kann der Interpreter eines Agent-Pakets, ein Hook eines Paketmanagers, ein temporäres Skript einer IDE-Erweiterung oder ein Wrapper eines Teamwerkzeugs sein. Der Name ist technisch korrekt und praktisch nutzlos.

Verwenden Sie intern drei Bezeichnungen, auch wenn die Freigabekarte nur zwei davon zeigt:

• Anfragender Prozess: der Prozess, der tatsächlich um die Nutzung des geschützten Kanals gebeten hat.
• Ausführungskette: die relevanten übergeordneten Prozesse, die erklären, wie der anfragende Prozess dorthin gelangt ist.
• Erkennbare Instanz: der nächste Vorfahr, dessen Identität ein Prüfer vernünftigerweise erkennen und dessen Codesignatur er bewerten kann.

Diese Bezeichnungen lösen ein Problem, das viele Freigabesysteme verwischen. Der anfragende Prozess beantwortet die Frage «Welcher Prozess hat diesen Aufruf ausgelöst?» Die erkennbare Instanz beantwortet die Frage «Durch wen oder welche Organisation ist dieser Lauf gegangen?» Beides hängt zusammen, ist aber nicht austauschbar.

Eine Anfrage könnte beispielsweise so aussehen:

Code Helper (signed application)
  └─ zsh -l
      └─ npm run agent
          └─ node ./tools/start-agent.mjs
              └─ agent-cli --workspace /Users/maya/src/payments

Wenn agent-cli eine HTTP-Anfrage stellt, ist es der anfragende Prozess. Die Shell und npm erklären den Startpfad. Der signierte Prozess Code Helper kann die beste erkennbare Instanz sein, sofern er sich tatsächlich in der laufenden Vorfahrenkette befindet und nicht nur auf dem Desktop geöffnet ist. Eine Freigabekarte mit «agent-cli, gestartet von Code Helper» ist ehrlich. Eine Karte mit nur «Code Helper möchte Zugriff» unterschlägt die Information, die diesen Lauf von einer anderen Erweiterung oder Aufgabe unterscheiden würde.

Ein Prozessbaum ist ein Beleg, keine Absichtserklärung

Ein übergeordneter Prozess beweist, dass er eine Beziehung zu einem untergeordneten Prozess erzeugt oder geerbt hat. Er beweist nicht, dass der übergeordnete Prozess die späteren Argumente, Eingaben, Repository-Anweisungen oder Antworten aus der Ferne des untergeordneten Prozesses verstanden hat.

Diese Einschränkung ist wichtig, wenn ungenau über Signaturen gesprochen wird. Apple beschreibt eine Designated Requirement als Mechanismus, mit dem macOS feststellt, ob Code über verschiedene Versionen hinweg derselbe Code ist. Sie enthält im Allgemeinen eine Kennung und eine Signaturinstanz. Apple macht auch die Grenze deutlich: Nicht signierter Code besitzt keine dauerhafte Designated Requirement, und lokale Ad-hoc-Signaturen liefern keine stabile Identität über Versionen hinweg.

Für eine Freigabe ist das ein nützlicher Beleg. Es ist keine Zustimmung zu einer Aktion. Eine signierte IDE kann ein nicht signiertes Repository-Skript starten. Ein signiertes Terminal kann eine heruntergeladene Binärdatei ausführen. Ein signierter Task Runner kann feindselige Umgebungsvariablen an einen völlig gewöhnlichen Interpreter weitergeben. Die Signatur ermöglicht es dem Prüfer, einen Herausgeber des Codes zu erkennen. Sie macht die darunterliegende Kette nicht automatisch sicher.

Unterscheiden Sie die folgenden Aussagen:

Die praktische Konsequenz: Fassen Sie diese vier Aussagen nicht zu einem freundlichen App-Symbol und einem einzigen Satz zusammen. Ein Prüfer sollte erkennen können, welche Aussage er akzeptiert.

Wenn die Kette unklar ist, sagen Sie das. «Von einem nicht signierten Skript aus einer Terminalsitzung gestartet» ist eine bessere Freigabebezeichnung, als die Anfrage der Terminal-Anwendung zuzuschreiben, als hätte das Terminal sie selbst verfasst. Falsche Genauigkeit bringt Menschen dazu, die Karte zu ignorieren.

Prüfen Sie die laufende Kette, bevor Sie die Freigabekarte entwerfen

Am schnellsten finden Sie den richtigen Akteur, indem Sie einen echten Lauf prüfen, während er aktiv ist. Lassen Sie den Agent dabei eine harmlose Aktion ausführen, denn die Kette kann sich ändern, wenn die Arbeit vom Start in einen Task Runner oder einen untergeordneten Helfer übergeht.

Beginnen Sie unter macOS mit der PID des anfragenden Prozesses, sofern Ihr Gateway sie erfasst. Dieser Befehl gibt Prozess, übergeordnete PID, Startzeit, ausführbaren Namen und Argumente aus:

ps -p "$PID" -o pid=,ppid=,lstart=,user=,comm=,args=

Ein typisches Ergebnis sieht so aus:

81234 80991 Tue Jul 21 14:08:31 2026 maya /usr/local/bin/agent-cli agent-cli --workspace /Users/maya/src/payments

Gehen Sie anschließend nach oben. ps durchläuft die Kette nicht automatisch. Eine kleine Shell-Funktion macht die Prüfung wiederholbar:

ancestry() {
  local pid="$1"
  while [ "$pid" -gt 1 ] 2>/dev/null; do
    ps -p "$pid" -o pid=,ppid=,user=,comm=,args=
    pid=$(ps -p "$pid" -o ppid= | tr -d ' ')
  done
}

ancestry "$PID"

Die Ausgabe ist bewusst schlicht. Achten Sie auf Wechsel der Art: von der Agent-Binärdatei zum Interpreter, vom Interpreter zum Paketmanager, vom Paketmanager zur Shell, von der Shell zum Terminal oder IDE-Helfer. Hören Sie nicht auf, sobald Sie einen Namen erkennen. Gehen Sie weiter, bis Sie einen Prozess erreichen, der dem Prüfer eine aussagekräftige Herkunft liefert, oder bis die lokale Kette endet.

Für eine breite Momentaufnahme ist diese Ansicht hilfreich, wenn mehrere Nachkommen existieren:

ps -ax -o pid=,ppid=,user=,lstart=,comm=,args= | sort -n

Verwenden Sie sie zur Untersuchung, nicht für eine Freigabeaufforderung. Eine vollständige Prozessliste enthält zu viele irrelevante Details und zu wenig Struktur. Ihre Implementierung sollte sie bei Bedarf erfassen und dann auf den anfragenden Prozess, den direkten übergeordneten Prozess, die erkennbare Instanz und die Zwischenschritte reduzieren, die einen unerwarteten Start erklären.

Dabei gibt es zwei zeitliche Fallen. Erstens können Prozess-IDs wiederverwendet werden, nachdem ein Prozess beendet wurde. Erfassen Sie zusammen mit der PID die Startzeit und lösen Sie die Kette zum Zeitpunkt der Anfrage auf, statt einer früheren Momentaufnahme zu vertrauen. Zweitens kann ein Task Runner einen Worker forken und sich beenden, bevor der geschützte Aufruf erfolgt. Ist der übergeordnete Prozess bereits verschwunden, bewahren Sie die beim Erzeugen des Prozesses beobachtete Kette auf oder melden Sie die fehlende Verbindung. Ersetzen Sie sie nicht durch einen vermuteten Elternprozess.

VS Code verändert den Startpfad, wird aber nicht zum anfragenden Prozess

Das integrierte Terminal von VS Code kann Argumente oder Umgebungsvariablen einschleusen, wenn es unterstützte Shells für die Shell-Integration startet. Laut Dokumentation gilt die automatische Einschleusung außerdem nicht für jede Konfiguration, etwa für bestimmte Subshells, SSH-Sitzungen und komplexe Shell-Fälle. Das erinnert daran, dass Metadaten der Terminaloberfläche und Unix-Prozessbeziehungen zwei getrennte Belegquellen sind.

In einem einfachen Fall sieht die Kette so aus:

Visual Studio Code
  └─ terminal helper
      └─ login shell
          └─ agent-cli

Der Terminal-Helfer existiert, weil die IDE ein Pseudoterminal und dessen untergeordnete Shell verwalten muss. Die Login-Shell kann ein Profil laden, das PATH verändert, eine Sprachlaufzeit aktiviert, Shell-Hooks installiert oder ein projektspezifisches Skript startet. Diese Details erklären, warum sich derselbe Befehl in einem eigenständigen Terminal anders verhält als im IDE-Terminal.

Die Freigabeentscheidung sollte nicht so tun, als gäbe es diese Details nicht. Zeigen Sie die ausführbare Agent-Datei als anfragenden Prozess. Stellen Sie VS Code nur dann als Startinstanz dar, wenn es sich in der aktuellen Vorfahrenkette befindet. Nehmen Sie Shell und Task-Befehl in einen ausklappbaren Pfad auf, wenn sie den Lauf wesentlich unterscheiden.

Ein häufiger Fehler sieht so aus:

Visual Studio Code
  └─ zsh
      └─ make test-agent
          └─ sh -c ./scripts/bootstrap-agent
              └─ python3 tools/agent.py

Eine naive Implementierung sieht zsh und nennt die Anfrage «VS Code-Terminal». Eine andere sieht python3 und nennt sie «Python». Beides hilft dem Prüfer nicht festzustellen, ob es sich um die bekannte Repository-Aufgabe oder um einen beliebigen Prozess aus derselben Shell handelt.

Die nützliche Aussage sieht eher so aus:

Requester: python3 tools/agent.py
Run path: make test-agent > scripts/bootstrap-agent
Launched from: Visual Studio Code integrated terminal

Diese Bezeichnung hat einen Preis: Sie macht sichtbar, dass die Anfrage aus vom Repository kontrolliertem Code stammt. Das sollte sie auch. Wenn ein Prüfer einem signierten Editor vertraut, aber dem aktuellen Checkout nicht, muss die Karte Raum für diese Einschätzung lassen.

Leiten Sie die Zuständigkeit von VS Code nicht allein aus Terminal-Escape-Sequenzen, Umgebungsvariablen oder einem Fenstertitel ab. Diese Informationen können geerbt, kopiert oder veraltet sein. Die lebende Vorfahrenkette ist der stärkere Beleg. Prozesskontext, den die IDE liefert, kann die Anzeige nach bestätigter Abstammung ergänzen, sie aber nicht ersetzen.

Ein eigenständiges Terminal liefert Kontext, keine pauschale Berechtigung

iTerm2, Terminal und ähnliche Apps geben Menschen einen bewusst gewählten Einstiegspunkt. Öffnet ein Entwickler ein sauberes Terminal, gibt einen Agent-Befehl ein und erhält sofort eine Freigabeaufforderung, ist die Bezeichnung der Terminal-Anwendung ein nützlicher Kontext. Sie zeigt, wo der Lauf begann.

Sie rechtfertigt trotzdem keine pauschale Freigabe für jeden untergeordneten Prozess, der zufällig dieselbe Sitzung verwendet. Shells sind dafür ausgelegt, untergeordnete Prozesse zu erzeugen, und langlebige Tabs bestehen oft länger als der Anlass, aus dem sie geöffnet wurden. Ein Befehl, der um 9:00 Uhr in einem Terminal-Tab gestartet wurde, kann bis zum Mittag weiterlaufen, nachdem cd, ein Branch-Wechsel, eine Umgebungsänderung und drei unabhängige Befehle ausgeführt wurden.

Machen Sie die Unterscheidung sichtbar:

Requester: agent-cli --workspace /Users/maya/src/payments
Parent: zsh -l
Interactive origin: signed terminal application
Session started: Tue Jul 21 14:08:31 2026

Der interaktive Ursprung ist unterstützender Kontext. Die Sitzung gehört zum tatsächlichen Prozesslauf. Endet der Prozess, widerrufen Sie die Sitzungsfreigabe, auch wenn der Terminal-Tab geöffnet bleibt. Ein neuer Agent-Prozess im selben Tab ist ein neuer Lauf mit neuen Argumenten und möglicherweise einer anderen ausführbaren Datei in PATH.

Hier wird die Identität, die ein Prüfer erkennen kann, schwierig. Die Terminal-App kann von einem bekannten Herausgeber signiert sein, während agent-cli eine nicht signierte ausführbare Datei in einem Projektverzeichnis ist. Die ehrliche Karte sollte beide Tatsachen nennen. Übertragen Sie die Signatur des Terminals nicht auf den nicht signierten untergeordneten Prozess, als hätte das Terminal für ihn gebürgt.

Dasselbe Problem tritt bei Shell-Funktionen und Aliasen auf. Ein Befehl, der wie agent aussieht, kann zu einer Funktion erweitert werden, die das Verzeichnis wechselt, eine Umgebungsdatei lädt, ein Paket-Skript startet und schließlich eine weitere Binärdatei ausführt. Ihre Prozesserfassung sieht nur die daraus entstehenden untergeordneten Prozesse. Wenn der eingegebene Befehl als optionaler Kontext angezeigt werden soll, erfassen Sie ihn über die Shell-Integration oder einen Shell-Hook und kennzeichnen Sie ihn als vom Benutzer eingegebenen Befehl aus dem Verlauf, nicht als Prozessidentität.

Skripte und Task Runner erzeugen die irreführendsten Ketten

Task Runner sind beliebt, weil sie eine komplizierte lokale Einrichtung in einen leicht merkbaren Befehl verwandeln. Diese Bequemlichkeit lässt ihre Prozessketten oft vertrauenswürdiger aussehen, als sie sind.

Betrachten Sie diesen gewöhnlichen Start:

zsh -l
  └─ just agent
      └─ /bin/sh -cu 'npm run agent -- --mode write'
          └─ npm run agent -- --mode write
              └─ sh -c node ./scripts/launch-agent.js --mode write
                  └─ node ./scripts/launch-agent.js --mode write
                      └─ agent-cli --mode write

Jeder mittlere Prozess hat einen legitimen Zweck. just wählt ein Rezept aus. /bin/sh interpretiert den Rezepttext. npm wählt ein Paket-Skript und startet eine Shell. Node wertet das Startskript aus. Keiner dieser Namen sagt dem Prüfer jedoch, ob die geschützte Anfrage aus einem bekannten Agent-Lauf oder aus einem anderen Befehl stammt, der zufällig dieselbe Laufzeit verwendet.

Entfernen Sie die mittleren Ebenen nicht aus dem Prüfdatensatz. Genau dort findet eine Untersuchung möglicherweise ein verändertes Paket-Skript, einen unerwarteten pre- oder post-Lifecycle-Hook, einen geänderten PATH oder ein Repository-Skript, das eine andere ausführbare Datei eingesetzt hat. Kürzen Sie sie in der Freigabeanzeige erst, nachdem Sie sie in einem unveränderlichen Ereignisdatensatz bewahrt haben.

Eine sinnvolle Anzeigeregel lautet:

1. Stellen Sie die ausführbare Datei und Argumente des anfragenden Prozesses an den Anfang.
2. Zeigen Sie den direkten Starter, wenn er die Interpretation verändert, etwa npm run deploy-agent oder make migration-bot.
3. Nennen Sie die erste erkennbare signierte Instanz als Startinstanz.
4. Halten Sie die vollständige beobachtete Vorfahrenkette in den Ereignisdetails verfügbar.

Diese Regel vermeidet zwei schlechte Gewohnheiten. Die erste besteht darin, jeden Wrapper zu verbergen, wodurch ein veränderter Task unsichtbar wird. Die zweite besteht darin, einen siebenzeiligen Baum zu zeigen, bevor der Prüfer die Anfrage beantworten kann. Wer unlesbaren Freigabekarten gegenübersteht, gibt die Form der Karte frei, nicht die Aktion.

Eine Empfehlung lehne ich ab: Geben Sie den Task Runner statt des Agents frei, weil der Aufgabenname für Menschen leichter erkennbar ist. Aufgabennamen sind oft Repository-Text. Wer den Checkout ändern kann, kann möglicherweise auch ändern, was die Aufgabe tut. Verwenden Sie den Aufgabennamen als Kontext, binden Sie eine Freigabesitzung aber an den beobachteten Agent-Prozesslauf und bewerten Sie sie neu, wenn ein neuer Lauf beginnt.

Wählen Sie die signierte Grenze sorgfältig

Der nächste signierte Vorfahr ist meist die beste erkennbare Instanz. «Der nächste» erfordert jedoch ein Urteil. Eine signierte System-Shell oder ein signierter Interpreter kann direkt über einem nicht signierten Skript stehen. Diese Shell als Instanz zu bezeichnen, erzeugt zwar eine technisch signierte Bezeichnung, sagt aber nichts darüber aus, wer den Code bereitgestellt hat.

Apples Hinweise zur Codesignatur unterscheiden zwischen der Kennung einer ausführbaren Datei und ihrer Signaturidentität und verwenden eine Designated Requirement, um die Codeidentität festzustellen. Das Werkzeug codesign kann diese Anforderung anzeigen. Nutzen Sie die Ausgabe, um eine signierte App oder einen Helfer zu identifizieren. Behandeln Sie eine Kennungszeichenfolge allein jedoch nicht als Beweis für eine Beziehung zu einem Herausgeber.

Bei einer gebündelten Anwendung prüfen Sie die ausführbare Datei oder das App-Bundle, das in der Vorfahrenkette erscheint:

codesign --display --verbose=4 --requirements - "/Applications/Example.app" 2>&1 \
  | sed -n '/Identifier=/p;/TeamIdentifier=/p;/Authority=/p;/designated =>/p'

Ein typisches Ergebnis enthält Felder dieser Form:

Identifier=com.example.editor
TeamIdentifier=AB12CDE345
Authority=Developer ID Application: Example Software (AB12CDE345)
designated => anchor apple generic and identifier "com.example.editor" and certificate leaf[subject.OU] = "AB12CDE345"

Die genauen Felder unterscheiden sich je nach Signatur und Vertriebsweg. Entscheidend ist, dass Ihr Freigabesystem eine stabile Codeidentität erfasst, wenn macOS sie bereitstellen kann, und anschließend eine für Prüfer verständliche Darstellung erzeugt, ohne die Rohbelege zu verbergen.

Beachten Sie bei der Auswahl der angezeigten Instanz diese Regeln:

• Bevorzugen Sie eine signierte grafische App oder einen eigens dafür vorgesehenen signierten Helfer, der sich tatsächlich in der Vorfahrenkette des anfragenden Prozesses befindet.
• Verwenden Sie keinen allgemeinen signierten Interpreter als Ersatz für das nicht signierte Skript, das er ausgeführt hat.
• Leiten Sie keine Zuständigkeit aus dem Verzeichnis einer ausführbaren Datei, dem Repository-Namen oder der Shell-Eingabeaufforderung ab.
• Kennzeichnen Sie nicht signierte und Ad-hoc-signierte Schritte deutlich, statt sie unter einem erkennbaren übergeordneten Prozess zu verstecken.
• Gibt es keine erkennbare signierte Instanz, sagen Sie, dass der Lauf keine verifizierte lokale Herausgeberidentität besitzt.

Ein Prozess kann in einem konzeptionellen Sinn mehrere Signaturen haben: die Signatur des App-Bundles, die Signatur eines verschachtelten Helfers und die Signatur eines Interpreters. Prüfen Sie die ausführbare Datei, die tatsächlich in der Prozessliste erscheint. Eine signierte App kann einen separat signierten Helfer starten. Ein Helfer kann eine vom Benutzer installierte Binärdatei starten. Jede dieser Ebenen ist eine eigene Identitätsfrage.

Einige Startketten sollten das Vertrauen verringern

Eine saubere Eltern-Kind-Kette ist nicht immer verfügbar, und die fehlenden Fälle sind keine nebensächlichen Ausnahmen. Gerade hier machen Freigabesysteme ihre schwerwiegendsten Zuordnungsfehler.

Ausführung aus der Ferne unterbricht die lokale Kette

Wenn ein lokaler Agent SSH aufruft, kann Ihr Mac den lokalen SSH-Client und dessen Vorfahren identifizieren. Der entfernte Befehl besitzt auf einem anderen Rechner einen eigenen Prozessbaum. Behaupten Sie nicht, ein entfernter agent-cli sei von einer lokalen IDE gestartet worden, wenn Sie keine Belege auf dem entfernten Rechner erfassen und prüfen.

Die lokale Freigabekarte kann trotzdem nützlich sein. Sie kann den lokalen anfragenden Prozess, das Ziel, sofern bekannt das entfernte Konto, und den genauen an SSH übergebenen Befehl nennen. Das reicht für die Entscheidung, ob der lokale Agent die Verbindung herstellen darf. Es reicht nicht aus, die Identität des entfernten Prozesses festzustellen.

Abgekoppelte Arbeit braucht eine neue Identitätsentscheidung

Ein untergeordneter Prozess kann setsid aufrufen, sich durch einen doppelten Fork abkoppeln oder einen Supervisor bitten, die Arbeit nach dem Ende des ursprünglichen Starters fortzuführen. Danach wird eine Freigabe, die nur an das Terminal oder die anfängliche Shell gebunden ist, zur Fiktion. Der abgekoppelte Worker benötigt einen eigenen Prozessdatensatz, eine eigene Startzeit und einen neuen Freigabebereich, sofern keine bewusst entworfene Supervisor-Beziehung besteht, die Prüfer einsehen können.

Geerbte Umgebungsvariablen können den Akteur ändern, ohne den Baum zu ändern

Derselbe node-Pfad kann wegen eines geänderten PATH, NODE_OPTIONS, sprachspezifischer Modulpfade, Proxy-Einstellungen oder Arbeitsverzeichnisses ein anderes Agent-Paket laden. Die Prozesskette zeigt nicht jeden geerbten Wert. Erfassen Sie für Untersuchungen einen eingeschränkten Kontext-Fingerabdruck: Pfad der ausführbaren Datei, Argumente, aktuelles Verzeichnis, ausgewählte Umgebungsnamen und nach einer Reduktion ihrer Werte sowie gegebenenfalls einen Digest der ausführbaren Datei.

Schreiben Sie nicht die gesamte Umgebung in eine Freigabekarte oder ein Protokoll. Umgebungen enthalten oft Tokens, Endpunkte und persönliche Pfade. Ziel ist es, Läufe zu unterscheiden, nicht einen zweiten geheimen Datenspeicher in den Protokollen anzulegen.

Ein Prüfer braucht eine kurze Aussage und überprüfbare Belege

Eine Freigabeaufforderung hat nur wenige Sekunden, um Aufmerksamkeit zu gewinnen. Stellen Sie die entscheidende Aussage an den Anfang und geben Sie dem Prüfer anschließend einen Weg, die Begründung zu untersuchen.

Eine praktische Karte könnte so aussehen:

Agent process requests an HTTP call

Requester
agent-cli --workspace /Users/maya/src/payments
PID 81234, started 14:08:31

Launched through
npm run agent > node scripts/launch-agent.js
from a signed editor process

Destination
api.example.internal / POST /deployments

Das ist kompakt genug zum Lesen und konkret genug für eine kritische Prüfung. Ein Prüfer kann die Karte ablehnen, weil das Arbeitsverzeichnis falsch ist, der Task Runner unerwartet ist, das Ziel überrascht oder die Anfrage aus einem nicht signierten Schritt stammt. Das sind echte Gründe, eine Aktion zu stoppen.

Halten Sie die vollständigen Belege hinter der Karte bereit. Bewahren Sie PID und Startzeit des anfragenden Prozesses, Pfad der ausführbaren Datei, Argumente, Vorfahrenkette, Signaturinformationen der ausgewählten Instanz und die Freigabeentscheidung auf. Wenn derselbe Agent später im freigegebenen Lauf eine weitere Anfrage stellt, sollte der Datensatz deutlich machen, dass die Sitzungsentscheidung für die Lebensdauer dieses Prozesses galt, nicht für einen frei stehenden App-Namen.

Die sitzungsbezogene Autorisierung von Sallyport basiert auf genau dieser praktischen Grenze: Der erste Aufruf eines neuen Agent-Prozesses fordert eine Freigabe an, und die Freigabe gilt nur bis zum Ende dieses Prozesses. Die Freigabekarte stellt die Codesignaturinstanz des Prozesses an die erste Stelle. Damit erhält der Prüfer einen erkennbaren Ausgangspunkt, ohne vorzugeben, dass die Signatur jeden untergeordneten Befehl erklärt.

Widerrufen Sie nach Prozesslebensdauer und machen Sie Ausnahmen ausdrücklich

Eine Sitzungsfreigabe sollte der Lebensdauer des Agent-Prozesses folgen, weil dieser Prozess die Anfrage gestellt hat. Eine Freigabe wiederzuverwenden, nur weil ein Terminal geöffnet bleibt, ein IDE-Fenster sichtbar ist oder eine Aufgabe denselben Namen trägt, erzeugt einen Freigabebereich, den niemand ehrlich prüfen kann.

Diese Regel verursacht bei kurzlebigen Wrappers zusätzlichen Aufwand. Ein Paketmanager kann für jeden Unterbefehl einen neuen Agent-Prozess starten. Lösen Sie das nicht, indem Sie die Freigabe stillschweigend auf jedes künftige npm-Kind oder jeden Prozess in einem Terminal ausweiten. Entscheiden Sie, ob der Ablauf einen stabilen, signierten Agent-Host, einen langlebigeren Prozess mit einer eindeutigen Identität oder eine Bestätigung bei jedem Aufruf der sensiblen Berechtigung benötigt.

Eine Freigabe pro Aufruf ist richtig, wenn das Risiko in jeder Nutzung liegt und nicht in der Startidentität. Ein Token für Produktivbereitstellungen, ein privater SSH-Schlüssel zu einem sensiblen Host oder eine schreibberechtigte administrative API können bei jeder Verwendung eine menschliche Entscheidung erfordern, selbst wenn die Prozessidentität bekannt ist. Die Erkennung des Prozesses verringert Verwirrung. Sie ersetzt keine Prüfung.

Der Implementierungstest ist einfach: Beenden Sie den freigegebenen Prozess, starten Sie denselben Befehl erneut und prüfen Sie, ob der zweite Lauf eine eigene Freigabe benötigt. Starten Sie danach einen anderen Befehl im selben Terminal-Tab und prüfen Sie, ob er die Entscheidung des ersten Laufs übernehmen kann. Wenn einer der Tests fehlschlägt, hat das System einen Ort oder eine Bezeichnung freigegeben, keinen Akteur.

Ein Prüfer sollte niemals einen Terminalnamen als Ersatz für die Prozessidentität akzeptieren müssen. Bewahren Sie die Kette auf, identifizieren Sie den anfragenden Lauf, zeigen Sie die stärkste erkennbare Instanz, die Sie begründen können, und lassen Sie fehlende Belege sichtbar. Das ist weniger eindrucksvoll als eine weit gefasste Regel «vertrauenswürdige IDE». Es hält jedoch stand, wenn sich ein Task-Skript, Shell-Wrapper oder entfernter Sprung als entscheidender Teil der Kette herausstellt.