# Codesignaturen für AI-Agents: Sitzungen mit Belegen freigeben

Eine Freigabeaufforderung mit dem einzigen Hinweis «AI-Agent fordert Zugriff an» bittet einen Menschen, ein Rätsel abzusegnen. Auf einem gemeinsam genutzten Entwicklungsrechner führt das dazu, dass jemand ein kopiertes Skript, ein vergessenes Terminal oder einen Prozess freigibt, der von der falschen Person gestartet wurde. Die nützlichere Frage ist enger gefasst: Welcher ausführbare Prozess fragt an, wer hat ihn signiert, wie ist er hierher gelangt und was darf er während dieses Laufs tun?

Eine Codesignatur liefert Belege für diese Entscheidung. Sie kann ein laufendes Programm einer signierenden Stelle zuordnen und zeigen, ob sich signierte Inhalte geändert haben. Sie sagt nicht, ob ein Agent einen bösartigen Prompt erhalten hat, ob ein vertrauenswürdiger Anbieter eine fehlerhafte Version veröffentlicht hat oder ob die angeforderte Aktion in der Produktion sinnvoll ist. Probleme entstehen, wenn Teams eine Signatur mit einer Garantie für das Verhalten verwechseln.

Auf einem gemeinsam genutzten Mac kannst du die signierende Stelle verwenden, um bekannte Agent-Clients zu erkennen, Überraschungen abzulehnen und jede Freigabe mit dem Prozess ablaufen zu lassen, der sie erhalten hat. Ergänze das durch klare Kontogrenzen, beschränkte Zugangsdaten und Aufzeichnungen, mit denen sich sowohl die Freigabe als auch der anschließende Aufruf rekonstruieren lassen.

## Eine Signatur identifiziert Code, nicht die dahinterstehende Absicht

Eine Codesignatur kann zeigen, wer ein bestimmtes Stück Code signiert hat und ob macOS die signierten Inhalte weiterhin verifizieren kann. Sie zeigt nicht, dass der Code Zugriff auf deine Systeme verdient. Dieser Unterschied muss in jedem Freigabeablauf sichtbar bleiben.

Apples Dokumentation zur Codesignatur, Technical Note TN2206, beschreibt Signaturen als Möglichkeit, Code zu validieren und eine designierte Anforderung auszudrücken. macOS kann diese später verwenden, um denselben Code wiederzuerkennen. Die designierte Anforderung ist wichtig, weil sie genauer ist als ein Dateiname. Eine ausführbare Datei namens `agent` kann überallhin kopiert und umbenannt werden. Ihre signierte Identität bleibt besser nachvollziehbar, solange Signaturkette und Anforderung weiterhin gültig sind.

Diese Kontinuität beantwortet eine praktische Frage: «Ist das der Client, den wir freigeben wollten?» Sie beantwortet nicht diese ebenso praktischen Fragen:

- Hat der Agent Anweisungen erhalten, die niemals die Produktion erreichen dürften?
- Hat jemand diesen Prozess absichtlich aus dem erwarteten Projektverzeichnis gestartet?
- Enthält der Prozess eine Erweiterung, ein Plugin oder eine Konfiguration, die sein Verhalten verändert?
- Gehört der angeforderte API-Aufruf zu dieser Aufgabe?
- Hat die hinter dem Aufruf liegende Zugangsinformation mehr Rechte, als die Aufgabe benötigt?

Oft greifen Menschen zum Namen eines Anbieters, als wäre er bereits ein Urteil. Das ist er nicht. Eine signierende Stelle zeigt, wer die für dieses Artefakt verwendete Signaturberechtigung kontrolliert hat. Ein großer Anbieter kann viele Programme signieren. Ein kleines internes Team kann einen völlig passenden Build signieren. Die Freigabe sollte die beobachtete Identität mit einer erklärbaren Allowlist deines Teams vergleichen, nicht mit dem vagen Gefühl, dass der Aussteller vertraut klingt.

Es gibt außerdem eine leicht zu übersehende Grenze: Die Signatur prüft den signierten Code. Sie deckt nicht automatisch alles ab, was ein Prozess später liest. Konfigurationsdateien, Prompt-Dateien, Umgebungsvariablen, Repository-Daten, heruntergeladene Erweiterungen und Antworten aus der Ferne können das Verhalten eines korrekt signierten Programms verändern. Wenn du einen Agent freigibst, weil seine Binärdatei vertraut aussieht, brauchst du weiterhin Kontrollen für seine Aktionen.

## Lies eine Freigabekarte als Zuordnungsnachweis

Eine Freigabekarte sollte der bedienenden Person genug Informationen geben, um eine Anfrage vor der Freigabe einem echten Prozess zuzuordnen. Die signierende Stelle gehört an den Anfang, weil sie schwerer zu fälschen ist als eine Prozessbezeichnung. Sie muss jedoch zusammen mit Prozesspfad und Sitzungsdetails angezeigt werden.

Für einen Prozess, der auf einem gemeinsam genutzten Rechner Zugriff anfordert, möchte ich diese Fakten an einer Stelle sehen:

- Die Identität der ausführbaren Datei oder App und ihr vollständiger lokaler Pfad.
- Die signierende Stelle oder die designierte Anforderung, anhand derer sie erkannt wird.
- Prozess-ID und übergeordneter Prozess, damit sichtbar ist, was ihn gestartet hat.
- Das macOS-Benutzerkonto, dem der Prozess gehört.
- Aktionskanal und Ziel, etwa ein API-Host oder SSH-Host.

Die ersten drei Fakten erfassen unterschiedliche Fehler. Ein vertrauter Anzeigename mit einem unerwarteten Pfad deutet oft auf eine kopierte Binärdatei oder einen Wrapper hin. Ein vertrauter Pfad mit einer unbekannten signierenden Stelle kann bedeuten, dass jemand den Prozess neu gebaut, ersetzt oder einen Symlink umgebogen hat. Eine vertraute ausführbare Datei, die von einem unerwarteten übergeordneten Prozess gestartet wurde, kann darauf hinweisen, dass ein anderes Automatisierungstool sie gestartet hat und nicht der Entwickler, der die Aufforderung gerade sieht.

Auf einem gemeinsam genutzten Mac ist das Benutzerkonto keine Nebensache. Wenn zwei Entwickler denselben Login verwenden, sagt eine Freigabe nur wenig darüber aus, welche Person den Agent gestartet hat. Der Rechner kann weiterhin zeigen, welcher Prozess den Aufruf ausgeführt hat. Dein Team hat aber bereits vor Beginn des Freigabeablaufs eine klare menschliche Grenze aufgegeben. Getrennte macOS-Konten sind günstiger, als nach einem Vorfall über den Verlauf eines Terminals zu streiten.

Gewöhne Menschen nicht daran, anhand eines Logos, eines kurzen Befehlsnamens oder einer signierenden Stelle allein freizugeben. Sie sollten ein vollständiges erwartetes Paket erkennen: freigegebener Agent-Client, erwartete signierende Stelle, erwarteter lokaler Speicherort, eigenes Konto und ein aufgabenbezogenes Ziel. Eine Karte, die den Großteil dieser Belege auslässt, macht aus einer Ein-Klick-Freigabe ein Ratespiel.

## Prüfe die ausführbare Datei, bevor du sie als Identität freigibst

Prüfe genau die App oder ausführbare Datei, die dein Team freigeben möchte, bevor jemand ihre Signatur in einem laufenden Ablauf verwendet. Erledige das bei der Einrichtung, dokumentiere das erwartete Ergebnis in eurem internen Handbuch und wiederhole die Prüfung bei einem bewusst geplanten Upgrade des Clients.

Unter macOS kann `codesign` Signaturdetails anzeigen. Die ausführliche Ausgabe wird an die Standardfehlerausgabe geschrieben. Leite sie um, wenn du ein Prüfartefakt speichern möchtest:

```sh
codesign -dv --verbose=4 /Applications/ApprovedAgent.app 2>&1
```

Die Ausgabe enthält üblicherweise Felder wie diese:

```text
Executable=/Applications/ApprovedAgent.app/Contents/MacOS/ApprovedAgent
Identifier=com.example.approved-agent
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=...
Authority=Developer ID Application: Example Developer (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
TeamIdentifier=ABCDE12345
Sealed Resources version=2 rules=13 files=...
```

Halte `Identifier`, die oberste `Authority` und `TeamIdentifier` zusammen. Die Team ID allein ist eine schwache Freigaberegel, weil eine Organisation mehrere Anwendungen signieren kann. Der Identifier allein ist ebenfalls schwächer, weil jemand ein unsigniertes Programm mit derselben Bundle-ID erstellen kann. Erst die Kette macht die Aussage brauchbar.

Prüfe danach die signierten Inhalte:

```sh
codesign --verify --deep --strict --verbose=2 /Applications/ApprovedAgent.app
```

Ein erfolgreiches Ergebnis bleibt oft ohne Ausgabe. Ein Fehler weist auf eine veränderte verschachtelte Komponente oder ein anderes Signaturproblem hin. `--deep` weist `codesign` an, verschachtelten Code rekursiv zu prüfen. Das ist als Prüfhilfe nützlich. Behandle es aber nicht als Beweis dafür, dass jede gebündelte Komponente zu deiner Sicherheitsrichtlinie passt. Apple weist darauf hin, dass die tiefe Prüfung rekursiv erfolgt und verdecken kann, dass die interne Signaturstruktur eines Bundles eine direkte Prüfung verdient.

Bei einer App, die außerhalb deines verwalteten Softwarekanals bezogen wurde, solltest du zusätzlich Gatekeeper nach seiner Bewertung fragen:

```sh
spctl --assess --type execute --verbose=4 /Applications/ApprovedAgent.app
```

`spctl` und `codesign` beantworten verwandte, aber unterschiedliche Fragen. `codesign` prüft Signaturen anhand des Artefakts. `spctl` fragt, ob die Bewertungsrichtlinie des Systems es akzeptiert. Eine erfolgreiche Bewertung ist ein nützliches Signal für die Herkunft. Sie bedeutet nicht, dass Befehle, Skripte oder Verhalten der App aus der Ferne sicher für die Produktion sind.

Dokumentiere den geprüften Pfad. Wenn jemand später `/Users/alex/bin/agent` freigibt, weil die Bezeichnung der geprüften App unter `/Applications` ähnelt, wurde die Prüfung nicht wiederholt. Der Pfad gehört zu den Belegen.

## Die Signatur eines Interpreters segnet das ausgeführte Skript nicht ab

Ein signiertes Terminal, eine signierte Laufzeitumgebung oder eine Shell kann nicht für ein beliebiges Skript bürgen, das ihr beim Start übergeben wird. Das ist die Lücke hinter vielen Freigaben, die im Gespräch vernünftig klingen, in der Praxis aber scheitern.

Stell dir einen Entwickler vor, der einen Agent mit einem Befehl wie diesem startet:

```sh
/usr/bin/python3 /Users/dev/work/demo/tools/agent_runner.py
```

Die Systemversion von Python kann eine bekannte Signatur haben. Diese Tatsache sagt etwas über die Binärdatei des Interpreters aus. Sie sagt nichts über `agent_runner.py`, die aus dem Repository importierten Dateien, die gelesene `.env`-Datei oder die über die Standardeingabe übergebenen Anweisungen. Wenn die Freigabeoberfläche nur `python3` nennt, muss ein Angreifer nicht den Interpreter verändern, sondern lediglich das Skript oder den Projektzustand.

Dasselbe Problem tritt bei `node`, Shells, Editor-Erweiterungen und generischen Automatisierungsläufen auf. Eine weit gefasste Regel wie «Prozesse freigeben, die von diesem Laufzeitanbieter signiert sind» erlaubt leicht sehr viel Verhalten, das niemand geprüft hat. Sie ist beliebt, weil sie Reibung bei Freigaben reduziert. Für jeden Kanal, der wichtige Zugangsdaten erreichen kann, ist sie falsch.

Verwende eines von zwei Modellen und dokumentiere, für welches sich dein Team entschieden hat. Das strengere Modell gibt einen signierten, speziell entwickelten Agent-Client frei, dessen Sitzungsprozess das zugreifende Programm ist. Das flexiblere Modell erlaubt Interpreter, behandelt aber jeden Skriptstart als eigene Sitzung und zeigt neben der Signatur des Interpreters auch Skriptpfad, Projektverzeichnis, Argumente und übergeordneten Prozess an.

Mit Standardwerkzeugen kannst du den grundlegenden Kontext eines laufenden Prozesses prüfen:

```sh
ps -p 4821 -o pid=,ppid=,user=,command=
ps -p 4812 -o pid=,ppid=,user=,command=
```

Der erste Befehl könnte den Agent-Prozess zeigen, der zweite seinen übergeordneten Prozess. Vergleiche die Befehlszeile mit der Arbeit des Entwicklers. Stammt das Kind aus einem Terminal im erwarteten Projekt, passen die Belege zusammen. Stammt es von einem unbeaufsichtigten Scheduler, einem Browser-Helfer oder einem anderen Agent, solltest du die Anfrage nicht länger als gewöhnliche Entwicklerfreigabe behandeln.

Bei einem skriptbasierten Client sollte der Digest des Skripts Teil des Freigabedatensatzes sein. Eine einfache lokale Prüfung reicht, um Änderungen sichtbar zu machen:

```sh
shasum -a 256 /Users/dev/work/demo/tools/agent_runner.py
```

Ein Digest macht ein Skript nicht vertrauenswürdig. Er liefert deinem Team aber eine konkrete Antwort auf die Frage, ob sich das freigegebene Skript zwischen zwei Läufen geändert hat. Speichere den erwarteten Digest nur für eine geprüfte Version oder einen kontrollierten Projektzustand. Mache daraus kein Ritual, bei dem Hashes aus Chatnachrichten kopiert werden.

## Auf gemeinsam genutzten Rechnern kommen Kontogrenzen vor Freigaberegeln

Ein gemeinsam genutzter Entwicklungs-Mac ist beherrschbar, wenn jede Person ein eigenes Konto verwendet und jeder Agent-Lauf einen eindeutigen Besitzer hat. Wenn alle denselben Login verwenden, kann die signierende Stelle die fehlende Zuordnung nicht reparieren.

Richte für jeden Entwickler ein eigenes macOS-Konto ein und vermeide ein gemeinsames Administratorkonto für die tägliche Arbeit. Der Agent-Prozess sollte unter dem Konto der Person laufen, die ihn gestartet hat. Projektdateien, Terminalverlauf, Umgebungsvariablen und Freigabeentscheidungen haben dann einen nachvollziehbaren Besitzer. Gemeinsame Repositorys erfordern keine gemeinsamen Betriebssystemkonten.

Eine praktikable Einrichtung trennt außerdem sensible Ziele. Verwende getrennte Zugangsdaten und Bezeichnungen für Entwicklung, Staging und Produktion, damit die Absicht für die bedienende Person sichtbar ist. Eine Freigabe für `inventory-staging` sollte nicht unbemerkt die Produktionszugangsdaten auswählen, nur weil beide auf denselben API-Client verweisen. Wenn die Bezeichnung der Zugangsdaten die Umgebung verschleiert, kann der Mensch im entscheidenden Moment keine gute Wahl treffen.

Auch der physische Zugriff zählt. Eine Person an einem entsperrten, gemeinsam genutzten Mac kann unter dem aktiven Konto einen Prozess starten und darauf warten, dass der Besitzer eine Freigabeaufforderung bestätigt. Sperre den Bildschirm beim Weggehen, verlange nach dem Aufwachen eine neue Anmeldung und lasse kein privilegiertes Terminal in einem gemeinsam genutzten Raum offen. Das sind unspektakuläre Kontrollen. Genau deshalb werden sie oft übersprungen, bis ein vermeidbares Durcheinander bereinigt werden muss.

Löse das Risiko gemeinsam genutzter Rechner nicht mit einer riesigen Liste freigegebener Signaturstellen. Diese Liste wächst meist, bis sie Editoren, Laufzeitumgebungen, Paketmanager, Build-Tools und Hilfsanwendungen enthält. Dann sagt sie nur noch, dass der Rechner für Entwicklung verwendet wird. Halte die freigegebene Menge bei Agents, die externe Aktionen anfordern können, klein und dokumentiere, warum jede Identität dazugehört.

## Die Sitzungsfreigabe sollte an einen Prozess gebunden sein, nicht dauerhaft an eine Person

Eine Sitzungsfreigabe sollte einen beobachteten Agent-Prozess für die Dauer dieses Prozesses autorisieren und beim Beenden ablaufen. Das ist ein sinnvoller Ausgleich zwischen einer Entscheidung für jede harmlose Anfrage und einer dauerhaften Berechtigung, die auch nach Abschluss der Arbeit bestehen bleibt.

Die Prozessgrenze ist wichtiger als ein Zeitlimit im Kalender. Ein Agent, der beendet und neu gestartet wird, erzeugt einen neuen Ausführungskontext. Er kann ein anderes Arbeitsverzeichnis, eine geänderte Binärdatei, andere Erweiterungen, einen anderen übergeordneten Prozess oder eine andere Person an der Tastatur haben. Eine neue Autorisierung nach jedem Neustart gibt der bedienenden Person eine weitere Gelegenheit, diese Änderungen zu erkennen.

Hier verdient die Codesignatur ihren Platz. Der Freigabeablauf kann die signierende Stelle zuerst anzeigen, weil sie beim Erkennen eines erwarteten Clients hilft. Die Bindung an die Sitzung verhindert zugleich, dass diese Wiedererkennung zu einer unbefristeten Genehmigung wird. Wenn der Agent-Prozess endet, sollte auch die Freigabe verschwinden. Wenn sich ein verdächtiges Verhalten zeigt, braucht die bedienende Person eine sofortige Möglichkeit, die Sitzung zu widerrufen, bevor sie die Signatur ausführlich untersucht.

Halte Autorisierung und Authentifizierung getrennt. Touch ID oder ein Passwort können beweisen, dass ein anwesender macOS-Benutzer die Freigabe erteilt hat. Sie identifizieren nicht den Prozess. Die Codesignatur kann bei der Prozessidentität helfen. Keine der beiden Methoden entscheidet, ob Ziel und Aktion angemessen sind. Eine gute Freigabekarte zeigt alle drei Arten von Belegen, statt sie gleichzusetzen.

Bei gewöhnlicher Arbeit im Repository kann eine Sitzungsentscheidung wiederholte Lesevorgänge gegen eine Entwicklungs-API abdecken. Für eine Aktion, die eine Deployment-Konfiguration ändert, Zugangsdaten rotiert, Datensätze löscht oder eine SSH-Verbindung zu einem Produktionshost öffnet, solltest du für diesen Aufruf eine neue Entscheidung verlangen. Reibung gehört dorthin, wo sich die Konsequenz ändert, nicht zufällig nach Ablauf eines Timers.

## Die signierende Stelle verhindert nicht die Fehler, die viele von ihr erwarten

Eine gültige Signaturkette kann nicht verhindern, dass ein vertrauenswürdiger Client schlechte Eingaben erhält, ein kompromittiertes Entwicklerkonto bösartigen Code signiert oder ein freigegebener Prozess eine unkluge Anfrage stellt. Behandle diese Fälle als getrennte Fehlerwege und setze jeweils die passende Kontrolle davor.

Der erste Weg ist ein Angriff über Prompt oder Repository-Anweisung. Ein Code-Assistent liest einen bösartigen Kommentar, der ihn auffordert, eine Konfigurationsdatei über eine HTTP-Anfrage herauszugeben. Die ausführbare Datei kann genau der freigegebene, korrekt signierte Client sein. Die Freigabe muss Ziel und angeforderten Kanal anzeigen, denn die Signatur liefert keinen Beleg für die Anweisung, der der Agent gefolgt ist.

Der zweite Weg ist ein legitimes Update, das dein Team nicht geprüft hat. Ein Anbieter kann eine neue Version unter derselben Signatur veröffentlichen. Wenn du jede künftige Version dieser Stelle ohne Prüfung ihrer Identität und Herkunft freigibst, besteht deine gesamte Richtlinie nur noch aus dem Besitz des Anbieters. Für lokale Werkzeuge mit geringem Risiko kann das akzeptabel sein. Für einen Agent, der Produktionszugangsdaten verwenden kann, reicht es nicht.

Der dritte Weg ist die Manipulation lokaler Prozesse. Eine signierte App kann ein Plugin laden, eine Umgebungsvariable übernehmen oder mit einem übergeordneten Prozess laufen, der überraschende Argumente liefert. Die Schutzmechanismen von macOS verringern einige Formen der Manipulation. Ein Freigabesystem muss trotzdem den tatsächlichen Prozesskontext anzeigen. Wenn Belege widersprüchlich sind, lehne die Anfrage ab und prüfe den Rechner. Erfinde keine harmlose Erklärung, nur weil die signierende Stelle vertraut klingt.

Der vierte Weg sind übermäßige Berechtigungen. Ein korrekt identifizierter Client kann Zugangsdaten verwenden, die viel mehr dürfen, als die Aufgabe erfordert. Beschränke Zugangsdaten auf die API, den Host, das Repository und die Umgebung, die der Agent benötigt. Eine Codesignatur kann dir sagen, welcher Client eine Zugangsinformation verwendet hat. Sie kann deren Berechtigungen nachträglich nicht verkleinern.

Deshalb ist «signiert bedeutet sicher» eine schädliche Empfehlung. Sie klingt einfach und erzeugt weniger Aufforderungen. Gleichzeitig fördert sie Freigaben ohne Ziel, Zusammenfassung der Aktion oder Sitzungsgrenze. Ein Signatursignal hilft einem Menschen, bekannten von unbekanntem Code zu unterscheiden. Es darf den Rest der Entscheidung niemals verdrängen.

## Für nicht rückgängig zu machende oder kritische Zugangsdaten gehört die Freigabe auf jeden Aufruf

Verlange für jede Verwendung einer Zugangsinformation eine menschliche Entscheidung, wenn ein einzelner Aufruf Folgen haben kann, die eine Sitzungsfreigabe nicht stillschweigend erlauben sollte. Entscheidend ist die Auswirkung der Aktion, nicht ob die ausführbare Datei des Agents vertrauenswürdig aussieht.

Nutze eine Freigabe pro Aufruf für Zugangsdaten, mit denen Produktionsdaten geschrieben oder gelöscht, Identitäten oder Berechtigungen geändert, externe Verpflichtungen eingegangen, Software veröffentlicht oder sensible SSH-Umgebungen betreten werden können. Die bedienende Person sollte Bezeichnung der Zugangsdaten und Ziel zum Zeitpunkt der Verwendung sehen. Eine allgemeine Meldung wie «Secret verwenden» verlangt unter Druck zu viel Erinnerung.

Halte Aufgaben mit geringen Folgen praktikabel. Wer jeden Lesezugriff auf eine Test-API freigeben muss, wird lernen, ohne Lesen zu klicken. Das macht die Kontrolle wirkungslos und wichtige Aufforderungen leichter übersehbar. Sitzungsfreigaben eignen sich gut für wiederholte, begrenzte Arbeit an einem Entwicklungsziel, wenn die Prozessidentität erwartet wird.

Die Entscheidungskette sollte so einfach sein, dass Menschen sie auch nach einer anstrengenden Woche erklären können. Zuerst verweigert ein gesperrter Zugangsdaten-Tresor jede Aktion. Danach benötigt ein neuer Agent-Prozess eine Sitzungsautorisierung. Schließlich verlangen ausgewählte Zugangsdaten bei jeder Verwendung eine Freigabe. Verstecke diese Entscheidungen nicht in einer eigenen Richtliniensprache, die nur eine Person versteht. Verborgene Ausnahmen lassen Regeln für gemeinsam genutzte Rechner allmählich verfallen.

Sallyport setzt dieses Modell mit drei Kontrollen direkt um: Ein gesperrter Tresor verweigert Aktionen, ein neuer Agent-Prozess fordert standardmäßig eine Sitzungsautorisierung an und ausgewählte Zugangsdaten können bei jeder Verwendung eine Freigabe verlangen. Die Freigabekarte zeigt zuerst die Codesignatur des Prozesses an. Das ist der richtige Ausgangspunkt, wenn mehrere Benutzer einen Mac gemeinsam verwenden.

## Zeichne die Freigabe und den Aufruf als getrennte Ereignisse auf

Du brauchst getrennte Datensätze für Agent-Sitzungen und einzelne Aktionen, weil keiner von beiden allein jede Frage eines Vorfalls beantworten kann. Ein Sitzungsdatensatz erklärt, welcher Prozess wann eine Autorisierung erhielt und wann sie endete. Ein Aktionsdatensatz erklärt, was dieser Prozess nach der Freigabe versucht hat, über welchen Kanal oder zu welchem Ziel und mit welchem Ergebnis.

Eine sinnvolle Untersuchungsfolge sieht so aus:

1. Finde den Sitzungsdatensatz des Prozesses, der Zugriff angefordert hat.
2. Prüfe Benutzerkonto, Pfad der ausführbaren Datei, signierende Stelle, übergeordneten Prozess und Zeitpunkt der Freigabe.
3. Finde die während dieser Sitzung ausgeführten Aufrufe und vergleiche die Ziele mit der zugewiesenen Aufgabe.
4. Widerrufe die Sitzung, falls sie noch aktiv ist. Deaktiviere oder rotiere danach die betroffene Zugangsinformation, wenn die Aufrufe einen Missbrauch zeigen.
5. Sichere die Datensätze, bevor du Projektdateien änderst oder den Client neu installierst.

Die Reihenfolge ist wichtig. Teams beginnen oft mit dem Lesen des Codes und verlieren dabei die Belege für das tatsächlich Geschehene. Stelle zuerst die Abfolge von Autorisierung und Aktion fest. Prüfe danach ausführbare Datei, Repository-Zustand, Shell-Verlauf und relevante Konfiguration.

Manipulationsnachweise sind hier wertvoll. Ein Audit-Datensatz, den ein lokaler Prozess umschreiben kann, bietet wenig Sicherheit, wenn genau dieser Prozess Teil des untersuchten Ereignisses ist. Eine Hashverkettung gibt Prüfern eine Möglichkeit, Änderungen oder das Entfernen von Einträgen innerhalb der aufgezeichneten Folge zu erkennen. Sie beweist jedoch nicht, dass jedes mögliche Ereignis erfasst wurde. Benenne diese Grenze klar. Manipulationsnachweise sind keine Allwissenheit.

Sallyport führt Sitzungs- und Aktivitätsjournale in einem verschlüsselten, hashverketteten Audit-Log zusammen. `sp audit verify` prüft die Kette offline, ohne eine Tresorzugangsinformation zu benötigen. Dadurch wird eine routinemäßige Prüfung nach einem Vorfall oder vor der Übergabe der Datensätze an eine andere prüfende Person praktikabel.

## Mache Freigabeentscheidungen reproduzierbar statt persönlich

Ein Team sollte erklären können, warum eine Agent-Sitzung freigegeben wurde, ohne sich auf die Erinnerung der Person zu verlassen, die geklickt hat. Schreibe für jeden erlaubten Agent-Client ein kurzes Freigabeprofil und bewahre es zusammen mit den Betriebsanweisungen des Repositorys auf.

Das Profil sollte erwarteten App- oder Programmpfad, Identifier, signierende Stelle, normalen übergeordneten Prozess, vorgesehene Benutzerkonten, erlaubte Umgebungen und Zugangsdaten nennen, die bei jedem Aufruf eine Entscheidung erfordern. Das ist keine Bürokratie um ihrer selbst willen. Es gibt neuen Teammitgliedern einen beobachtbaren Standard und der Bereitschaftsperson eine Grundlage, eine ungewöhnliche Anfrage abzulehnen, ohne über Geschmack zu diskutieren.

Überarbeite das Profil, wenn sich einer dieser Punkte ändert: Der Agent-Client wird aktualisiert, das Team übernimmt einen neuen Laufzeit-Wrapper, eine Zugangsinformation erhält stärkere Berechtigungen oder ein bisher lokaler Ablauf erreicht einen gemeinsam genutzten Dienst. Wenn sich die Signaturidentität ändert, halte inne und prüfe die Änderung über die Softwarequelle, der dein Team vertraut. Normalisiere keine unerwartete signierende Stelle, indem du einmal klickst und die Untersuchung auf später verschiebst.

Führe auf dem gemeinsam genutzten Mac eine gezielte Fehlerübung durch. Starte den freigegebenen Client unter dem erwarteten Konto und bestätige angezeigte Signatur und Sitzungsverhalten. Starte danach ein nicht freigegebenes Skript über einen signierten Interpreter, starte den Client unter einem anderen Konto und fordere Zugangsdaten an, die für eine Freigabe pro Aufruf markiert sind. In jedem Fall sollte das korrekte Verhalten für die bedienende Person offensichtlich sein. Wenn sich die Aufforderungen zu ähnlich sehen, verbessere die angezeigten Informationen, bevor jemand einen echten Fehler macht.

Codesignaturen sind nützlich, weil sie einen vagen Prozessnamen durch überprüfbare Belege ersetzen. Beschränke ihre Aufgabe darauf. Gib den bekannten Prozess für die anstehende Arbeit frei, halte den Umfang der Zugangsdaten klein und sorge dafür, dass sich eine verdächtige Sitzung widerrufen lässt, solange die Belege noch erhalten sind.