Sicherheit von Fast User Switching für Aktionen lokaler KI-Agenten

Ein gemeinsam genutzter Mac verändert die Bedeutung von «lokaler» Berechtigung. Fast User Switching ermöglicht es, mehrere Benutzersitzungen gleichzeitig angemeldet zu lassen. Dadurch können die Person an der Tastatur, ein Agent-Prozess, ein Berechtigungstresor und eine Genehmigungsaufforderung zu unterschiedlichen Sicherheitskontexten gehören. Wer sie als eine Identität behandelt, macht aus einer gewöhnlichen Übergabe schnell einen ungeprüften Aufruf in der Produktionsumgebung.

Die praktische Regel ist klar: Kontoinhaberschaft, Tresorzugriff und Genehmigungsbefugnis müssen an dieselbe macOS-Benutzersitzung gebunden bleiben. Ein Benutzerwechsel ist keine Erlaubnis, den Agent-Lauf einer anderen Person fortzusetzen. Er ist ein Signal zu prüfen, welcher Prozess noch existiert, wessen Berechtigungsnachweise er anfordern kann und wer die nächste Aufforderung sehen oder erfüllen kann.

Bei Fast User Switching geht es um parallele Sitzungen

Die Sicherheit von Fast User Switching ist wichtig, weil macOS das vorherige Konto angemeldet lassen kann, während eine andere Person dieselbe Hardware nutzt. Apple beschreibt Fast User Switching im macOS-Benutzerhandbuch als Möglichkeit, zwischen Konten zu wechseln, ohne den anderen Benutzer abzumelden. Genau darin liegt der Nutzen. Es bedeutet aber auch, dass ein Wechsel nicht beweist, dass die vorherige Arbeit beendet wurde.

Viele stellen sich einen Laptop wie einen einzelnen Stuhl vor: Eine Person steht auf, eine andere setzt sich hin und die Kontrolle geht über. Ein gemeinsam genutzter Mac mit aktiviertem Benutzerwechsel ähnelt eher mehreren Räumen in einem Gebäude. Der sichtbare Schreibtisch zeigt, wem die Konsole gerade gehört. Er zeigt nicht, ob in einem anderen angemeldeten Konto noch ein Terminal, eine Editor-Erweiterung, ein lokaler Dienst oder ein Agent-Starter läuft.

Diese Unterscheidung wird ernst, sobald ein Agent eine API aufrufen oder eine SSH-Verbindung herstellen kann. Der Agent könnte vor dem Mittagessen unter Alex' Konto gestartet worden sein. Danach wechselt Sam in das eigene Konto und sieht einen sauberen Schreibtisch. Alex' Prozess kann weiter existieren, seine Aufgabenwarteschlange kann noch Arbeit enthalten und ein Genehmigungsstatus kann für diesen Lauf weiterhin gültig sein. Der Mac hat diese Berechtigung nicht an Sam übertragen, aber nachlässige Software kann den Unterschied schwer erkennbar machen.

Behandeln Sie Bildschirmsperre, Benutzerwechsel und Prozessbeendigung nicht als Synonyme. Sie lösen unterschiedliche Probleme.

• Eine Bildschirmsperre blockiert die beiläufige Nutzung des aktuell sichtbaren Schreibtischs.
• Ein Benutzerwechsel ändert das aktive Konsolenkonto und lässt eine andere Anmeldesitzung bestehen.
• Beim Abmelden fordert macOS das Ende der grafischen Sitzung dieses Benutzers und seiner Prozesse an.
• Durch den Widerruf eines Agent-Laufs verliert dieser Lauf die Erlaubnis für weitere externe Aufrufe.

Der letzte Punkt wird von Teams oft vergessen. Eine Agent-Sitzung sollte ihre eigene Lebensdauer und ihren eigenen Widerrufsweg haben. Wenn sie nur die Lebensdauer eines Terminalfensters oder die unklare Vorstellung vom «Computer des Entwicklers» übernimmt, verhält sie sich auf einem Mac mit mehreren Benutzern problematisch.

Fast User Switching ist nicht automatisch unsicher. Unsicher wird es, wenn ein lokales Aktionssystem davon ausgeht, dass jeder laufende Prozess und jeder Mensch, der den Computer bedienen könnte, zu derselben Person gehört. Diese Annahme gilt nur auf einem persönlichen Mac mit einem einzigen aktiven Konto. Selbst dort scheitert sie, sobald jemand anderes das Anmeldepasswort kennt oder einen entsperrten Arbeitsplatz nutzt.

Der aktive Konsolenbenutzer darf nicht die Berechtigungen eines anderen Kontos erben

Der aktive Konsolenbenutzer sollte nur die Berechtigungsnachweise und Genehmigungen steuern, die seinem eigenen Konto zugewiesen sind. Ein lokaler Berechtigungstresor gehört zu einer Identität, nicht zum physischen Computer. Wenn eine App den Tresor systemweit verfügbar macht, erhält jeder Benutzer, der die Oberfläche der App erreichen kann, einen Weg zu den Berechtigungen einer anderen Person.

Hier vermischen Teams zwei unterschiedliche Aussagen. «Das Geheimnis gelangt nie in den Agenten» betrifft die Offenlegung des Geheimnisses. «Nur die richtige Person kann die Aktion genehmigen» betrifft die Berechtigung. Sie brauchen beides. Eine perfekte Grenze für Geheimnisse hilft nicht, wenn ein anderer angemeldeter Benutzer deren Nutzung genehmigen kann oder eine alte Sitzung weiterhin genehmigt ist, nachdem die betreffende Person den Arbeitsplatz verlassen hat.

Machen Sie die Bindung in Ihrem Design und Ihren Betriebsregeln ausdrücklich:

1. Speichern Sie die Berechtigungsnachweise jeder Person unter deren macOS-Konto, mit getrenntem Tresormaterial und separater lokaler Authentifizierung.
2. Verlangen Sie, dass der Tresor von dem Konto entsperrt wird, dem der Berechtigungsnachweis gehört, bevor ein externer Aufruf erfolgen kann.
3. Lassen Sie eine Genehmigung nur für einen Agent-Prozess in einem Konto gelten und beenden Sie sie, sobald dieser Prozess endet oder eine zuständige Person sie widerruft.
4. Lassen Sie nicht zu, dass ein Wechsel in ein anderes Konto eine Aufforderung erfüllt, die im ersten Konto entstanden ist.
5. Erfassen Sie bei jeder Autorisierung und jedem Aufruf den Kontokontext und den ursprünglichen Prozess.

Der schwierige Sonderfall ist eine Supportkraft mit Administratorzugriff auf dem Mac. Administratorrechte können viele lokale Bedingungen ändern, sollten aber nicht zur beiläufigen Nutzung der API-Berechtigungsnachweise einer anderen Person führen. Fragen Sie, ob das System eine neue Authentifizierung durch den Eigentümer des Berechtigungsnachweises erzwingt und ob der Prüfdatensatz den Kontowechsel sichtbar macht. Wenn die Antwort unklar ist, ist auch das Design unklar.

Touch ID macht diesen Punkt deutlicher, nicht einfacher. Eine Fingerabdruckgenehmigung sollte die Person bestätigen, die für das aktive Konto und die in der Aufforderung angezeigte Aktion autorisiert ist. Sie darf nicht zu einem allgemeinen Signal für körperliche Anwesenheit werden, das jede registrierte Person nutzen kann, um die Berechtigungen eines anderen Kontos einzusetzen. Hardwaregestützte lokale Authentifizierung bietet nur dann eine starke Sperre, wenn die App die Identität hinter dieser Sperre bewahrt.

Lösen Sie das nicht mit einer informellen Regel wie «Wir wechseln nur den Benutzer, wenn die andere Person weg ist». Gemeinsam genutzte Geräte führen zu Unterbrechungen, Wartungsarbeiten, ausgeliehenen Ladegeräten und eiligen Übergaben. Kontrollen müssen dem normalen menschlichen Verhalten standhalten, denn dann erinnern sich Menschen am wenigsten an ungeschriebene Regeln.

Ein verborgener Prozess kann die Person am Schreibtisch überdauern

Ein Benutzerwechsel kann einen lokalen Agenten am Leben lassen. Sie müssen genau so testen, wie Ihr Team Agenten startet. Manche Prozesse enden, wenn ihr übergeordnetes Terminal geschlossen wird. Andere laufen über einen Editor, einen Task-Runner, ein Anmeldeobjekt oder einen Hintergrundmechanismus weiter. macOS-Kontogrenzen schränken den Zugriff ein, versprechen aber nicht, dass jeder Prozess verschwindet, sobald ein anderer Benutzer das Anmeldefenster erreicht.

Führen Sie einen kleinen Test durch, bevor Sie autonome Arbeit auf gemeinsam genutzter Hardware erlauben. Verwenden Sie eine harmlose Agent-Aufgabe, die jede Minute einen erkennbaren lokalen Datensatz schreibt und keine Berechtigungsnachweise hält. Starten Sie sie über dasselbe Terminal, denselben Editor oder denselben Starter, den Entwickler bei der tatsächlichen Arbeit verwenden. Wechseln Sie den Benutzer, ohne sich abzumelden, warten Sie, wechseln Sie zurück und prüfen Sie, ob die Aufgabe weiterlief. Wiederholen Sie den Test nach dem Sperren des Bildschirms und nach dem Abmelden.

Halten Sie das Ergebnis in betrieblichen Begriffen fest. «Der Agent stoppt» reicht nicht. Notieren Sie den Starter, das Konto, das Ereignis, das ihn beendet hat, und die benötigte Zeit. Ein Prozess, der nach einem Benutzerwechsel weiterläuft, kann für einen lokalen Lint-Lauf akzeptabel sein. Wenn er eine Anfrage senden kann, die eine gehostete Umgebung verändert, verdient er deutlich mehr Aufmerksamkeit.

Ein häufiger Fehler wirkt zunächst harmlos. Ein Entwickler startet einen autonomen Programmiervorgang, der Issue-Kommentare erstellen und eine Testumgebung aktualisieren kann. Er genehmigt den Prozess für den Nachmittag. Dann wechselt er das Konto, damit eine andere Person den Mac nutzen kann. Der Programmiervorgang gerät nach einem vorübergehenden Fehler in eine Wiederholungsschleife und nimmt später die Arbeit wieder auf. Die zweite Person hat ihn nicht gestartet und weiß möglicherweise nicht einmal, dass er existiert. Trotzdem behält der Lauf seine gültige Genehmigung, weil die Software die Genehmigung an den Kalender, das Gerät oder eine umfassende Benutzersitzung gebunden hat statt an den ursprünglichen Prozess.

Die Lösung ist nicht allein ein kürzeres Genehmigungszeitfenster. Kurze Zeitfenster unterbrechen echte Arbeit und bringen Menschen dazu, Aufforderungen einfach durchzuklicken. Binden Sie die Genehmigung an eine Prozessinstanz. Wenn dieser Prozess endet, endet auch seine Freigabe. Wenn eine Person die Arbeit bewusst an jemand anderen übergibt, widerrufen Sie den alten Lauf und starten Sie einen neuen. Der neue Prozess erzeugt ein neues Genehmigungsereignis mit einer verantwortlichen Person.

Sie brauchen außerdem eine sichtbare Antwort auf die Frage: «Was läuft noch unter meinem Konto?» Die Antwort darf nicht vom Gedächtnis abhängen. Geben Sie Bedienern ein Sitzungsjournal, das den Lauf, seinen Genehmigungsstatus und eine direkte Widerrufsmöglichkeit anzeigt. Auf einem persönlichen Gerät ist das praktisch. Auf einem gemeinsam genutzten Mac ist es Teil der Sicherheitsgrenze.

Genehmigungsaufforderungen brauchen Prozessidentität, kein freundliches Etikett

Eine Genehmigungsaufforderung muss genügend Informationen anzeigen, um den tatsächlichen Aufrufer von einer Nachahmung zu unterscheiden. Eine Bezeichnung wie «Programmierassistent» ist nutzlos, wenn zwei Erweiterungen, zwei Shells oder ein kopiertes Skript diese Bezeichnung verwenden können. Die zuständige Person muss den ursprünglichen Prozess sehen und, sofern macOS dies bereitstellt, seine Code-Signatur.

Die Code-Signatur beantwortet eine enge, aber wichtige Frage: Welche Entwickleridentität hat diesen Prozess signiert? Sie beweist nicht, dass der Prozess gute Entscheidungen treffen wird. Sie hilft jedoch, eine Anfrage von einem nicht signierten Tool, einer anderen Version oder einem unerwarteten Hilfsprozess zu erkennen. Das ist deutlich besser, als eine anonyme Anfrage zu genehmigen, nur weil sie an einem hektischen Nachmittag auftaucht.

Die Aufforderung sollte auch den Berechtigungsnachweis oder die Aktionskategorie so benennen, dass ein Mensch sie beurteilen kann. «Berechtigungsnachweis X verwenden» zwingt die Person, eine gedankliche Tabelle zu durchsuchen. «HTTP-Anfrage an die Bereitstellungs-API mit dem Berechtigungsnachweis für den Staging-Publisher senden» ermöglicht eine Entscheidung. Vermeiden Sie es, in jede Aufforderung den vollständigen Anfrageinhalt zu packen. Große Aufforderungen erzeugen Genehmigungsmüdigkeit und legen Daten offen, die nicht in eine Desktop-Benachrichtigung gehören. Zeigen Sie Aktion, Ziel, Methode und Identität des Berechtigungsnachweises so an, dass sie schnell erfasst werden können.

Eine Genehmigung pro Sitzung und eine Genehmigung pro Aufruf lösen unterschiedliche Probleme. Eine Genehmigung pro Sitzung sagt: «Ich erkenne diesen Agent-Prozess und erlaube seinen begrenzten Lauf.» Eine Genehmigung pro Aufruf sagt: «Ich prüfe diese konkrete Nutzung dieses Berechtigungsnachweises.» Ersetzen Sie die zweite nicht durch die erste, nur weil die erste weniger unterbricht.

Verwenden Sie eine Genehmigung pro Aufruf, wenn Folgen schwer rückgängig zu machen sind: bei einem Berechtigungsnachweis, der Produktionsdaten ändern, Ressourcen löschen, extern veröffentlichen oder eine breit angelegte Administrationsoberfläche erreichen kann. Eine Genehmigung pro Aufruf verursacht Reibung. Diese Reibung gehört an den Punkt, an dem ein Mensch innehalten sollte.

Verwenden Sie eine Genehmigung pro Sitzung für Aufgaben, bei denen der Prozess eindeutig erkennbar ist und der verwendete Berechtigungsnachweis begrenzte Auswirkungen hat. Die Sitzung muss enden, wenn der Prozess endet. Eine pauschale Freigabe für «Agenten auf diesem Mac» ist eine Regelungslücke mit freundlichem Namen.

Die verbreitete Empfehlung, Genehmigungen auf einem vertrauenswürdigen lokalen Entwicklungsgerät abzuschalten, ist für gemeinsam genutzte Macs falsch. Sie ist beliebt, weil Aufforderungen den Arbeitsfluss unterbrechen und Entwickler lokale Prozesse für privat halten. Fast User Switching beseitigt diese Voraussetzung. Ein lokaler Computer kann mehrere aktive Benutzerkontexte enthalten, und ein vertrauter Prozess kann lange weiterlaufen, nachdem seine zuständige Person die Tastatur verlassen hat.

Gemeinsam genutzte Macs brauchen eine Übergabe, die Berechtigungen beendet

Eine ordentliche Übergabe beendet die Berechtigung der bisherigen Person, bevor die nächste mit der Arbeit beginnt. Das Weiterreichen eines Terminal-Tabs, einer Aufgabenbeschreibung oder einer Chatnachricht überträgt keine Verantwortlichkeit. Die übernehmende Person braucht einen neuen Prozess und eine eigene Genehmigung für jede Nutzung eines Berechtigungsnachweises.

Nutzen Sie diese Vorgehensweise, wenn jemand anderes eine lokale Agent-Aufgabe übernehmen muss:

1. Stoppen Sie den aktuellen Agenten, wenn er noch Entscheidungen trifft. Lassen Sie ihn seine normalen Arbeitsdateien schreiben, aber während der Übergabe keine externen Systeme mehr aufrufen.
2. Widerrufen Sie die alte Agent-Sitzung in ihrem Sitzungsdatensatz. Bestätigen Sie, dass sich der Sitzungsstatus geändert hat, bevor die ursprüngliche Person den Arbeitsplatz verlässt.
3. Sperren Sie den Tresor der ursprünglichen Person oder melden Sie dieses Konto ab, wenn der Mac für längere Zeit bei der nächsten Person bleibt.
4. Lassen Sie die übernehmende Person in ihr eigenes macOS-Konto wechseln und dort einen neuen Agent-Prozess starten.
5. Verlangen Sie eine neue Genehmigung, die den neuen Prozess identifiziert, und prüfen Sie den Aufgabenstatus, bevor externe Aktionen erlaubt werden.

Diese Vorgehensweise klingt streng, bis eine unklare Übergabe zum ersten Mal eine Anfrage sendet. Die Kosten für einen Neustart des Agents sind gering im Vergleich dazu, nachträglich herauszufinden, wer eine Änderung genehmigt hat. Wenn ein Ablauf keinen Neustart verkraftet, braucht er ein bewusst geplantes Mehrbenutzerdesign und keine zufällige Übergabe über einen gemeinsam genutzten Schreibtisch.

Vermeiden Sie gemeinsame Konten, um Übergaben zu beschleunigen. Ein gemeinsames Login zerstört die Belege, die Sie später brauchen. Sie können nicht feststellen, welche Person den Tresor entsperrt, welches Terminal den Prozess gestartet oder wessen Entscheidung den Aufruf genehmigt hat. Getrennte macOS-Konten lösen nicht jedes Problem, bewahren aber eine nützliche Grenze und einen brauchbaren Datensatz.

Teams brauchen auch eine Regel für abwesende Verantwortliche. Wenn ein Agent-Prozess unter dem Konto einer nicht verfügbaren Person läuft, sollte niemand ihn durch Aktionen in deren Konto am Leben halten. Stoppen Sie ihn, widerrufen Sie ihn und starten Sie ihn unter dem Konto einer anwesenden verantwortlichen Person neu. Die Arbeit kann warten. Eine unbeaufsichtigte Berechtigung zum Ändern externer Systeme sollte es nicht.

Das Sperren des Tresors sollte Aktionen stoppen, bevor Aufforderungen erscheinen

Eine Tresorsperre muss jede Aktion verweigern, solange der Tresor gesperrt ist, auch wenn ein Agent-Prozess zuvor eine Sitzungsfreigabe erhalten hat. Das ist der Unterschied zwischen der Berechtigung zum Ausführen und der aktuellen Erlaubnis, einen Berechtigungsnachweis zu verwenden. Die erste stellt fest, welchen Prozess die Person erkennt. Die zweite fragt, ob der Tresor gerade verfügbar ist.

Sallyport verwendet diese Reihenfolge bewusst: Die Tresorsperre ist absolut. Unter macOS nutzt Sallyport im gesperrten Zustand Secure Enclave und Touch ID, während gesperrte Aktionen verweigert werden. Dadurch kann eine alte Agent-Genehmigung nach dem Sperren der Sitzung nicht als Ersatz für den Zugriff auf den Tresor dienen.

Halten Sie die Kontrollen in Ihrem mentalen Modell getrennt. Die Tresorsperre schützt das Berechtigungsmaterial. Die Sitzungsfreigabe erkennt einen bestimmten Agent-Lauf. Die Genehmigung pro Aufruf fügt für ausgewählte Berechtigungsnachweise eine direkte Prüfung hinzu. Wenn eine Kontrolle die Aufgabe einer anderen übernimmt, können Bediener eine Ablehnung nicht mehr nachvollziehbar einordnen.

Machen Sie beispielsweise Aufforderungen pro Aufruf nicht zum einzigen Schutz für einen weitreichenden Berechtigungsnachweis. Eine Person kann nach dem Wechsel zurück zu einem überfüllten Schreibtisch versehentlich die falsche Anfrage genehmigen. Der gesperrte Tresor sollte die Aktion bereits blockieren, bis der Eigentümer des Berechtigungsnachweises sich lokal authentifiziert hat. Danach kann die Aufforderung pro Aufruf die engere Frage stellen: Verdient diese konkrete Nutzung eine Genehmigung?

Lassen Sie den Tresor ebenso wenig dauerhaft entsperrt, weil eine lange Programmieraufgabe ihn später benötigen könnte. Dadurch wird eine kurze Unaufmerksamkeit zu einer Zeitspanne, in der ein alter Prozess handeln kann. Entsperren Sie den Tresor für überwachte Arbeit und sperren Sie ihn, wenn die verantwortliche Person den Arbeitsplatz verlässt oder den Mac an jemand anderen übergibt. Wenn ein Auftrag wirklich unbeaufsichtigte Berechtigungen braucht, verlagern Sie ihn in eine Umgebung, die für Dienstidentitäten, begrenzte Berechtigungsnachweise und eindeutige betriebliche Verantwortlichkeit ausgelegt ist. Eine gemeinsam genutzte persönliche Sitzung ist nicht der richtige Ort, um einen Server zu imitieren.

Der Begriff «Human in the Loop» verschleiert oft die Identitätsfrage. Welche Person? Unter welchem Konto? Genehmigt sie welchen Prozess? Eine Aufforderung, die diese Fragen nicht beantworten kann, bietet keine sinnvolle Kontrolle. Sie erzeugt lediglich einen Datensatz darüber, dass jemand auf eine Schaltfläche geklickt hat.

Prüfdatensätze klären den zeitlichen Ablauf, nicht die Genehmigungsentscheidung

Ein manipulationssicherer Prüfpfad ermöglicht es, einen Agent-Lauf nach einer strittigen Aktion zu rekonstruieren. Er kann aber keine falsche Genehmigung in dem Moment verhindern, in dem sie erteilt wird. Verwenden Sie das Protokoll, um Reihenfolge und Verantwortlichkeit zu klären, und verbessern Sie anschließend die Kontrolle, die die Aktion ermöglicht hat. Betrachten Sie die Prüfhistorie nicht als Ersatz für einen gesperrten Tresor oder eine klare Genehmigungsgrenze.

Der Datensatz braucht zwei Ansichten, weil Bediener zwei unterschiedliche Fragen stellen. Ein Sitzungsjournal beantwortet: «Welcher Agent-Lauf wurde genehmigt und kann ich ihn widerrufen?» Ein Aktivitätsjournal beantwortet: «Welcher Aufruf erfolgte über welchen Kanal und wann?» Beide Datensätze sollten aus einer einzigen Quelle stammen, die nur Anhänge zulässt, statt aus zwei unabhängigen Datenbanken, deren Inhalte auseinanderlaufen können.

Sallyport erstellt beide Journale aus einem verschlüsselten, hashverketteten Prüfprotokoll, das schreibgeschützt ist. Dadurch teilen sich Aktivitäts- und Laufhistorie eine einzige Quelle. Die Offline-Prüfung ist über diesen Befehl verfügbar:

sp audit verify

Führen Sie diese Prüfung durch, wenn Sie einen Mac archivieren, eine strittige Übergabe untersuchen oder einen exportierten Prüfdatenspeicher erhalten. Der Verifizierer prüft die Kette über dem Geheimtext und benötigt den Entschlüsselungsnachweis nicht. Das ist auf gemeinsam genutzten Macs wichtig: Eine untersuchende Person kann prüfen, ob die Datensätze noch eine gültige Historie bilden, ohne die API-Tokens oder das SSH-Material zu erhalten, auf die sich die Historie bezieht.

Die Verifizierung zeigt, ob die Kette intern konsistent geblieben ist. Sie beweist nicht, dass jedes Ereignis klug war, dass eine Person jede Aufforderung verstanden hat oder dass das Gerät selbst nicht kompromittiert wurde. Formulieren Sie die Aussage genau. Eine verifizierte Kette macht das unbemerkte Bearbeiten früherer Datensätze schwerer. Sie macht aus einem unsicheren gemeinsamen Konto aber kein sicheres.

Vergleichen Sie bei einer Untersuchung den Kontokontext, die Prozessidentität, den Zeitpunkt der Sitzungsfreigabe, das Entsperren des Tresors und die Reihenfolge der einzelnen Aufrufe. Eine nützliche Frage lautet nicht nur: «Hat ein Agent das getan?» Fragen Sie, ob dasselbe Konto Eigentümer des Tresors, des Agent-Prozesses und der Genehmigung war. Wenn diese Angaben voneinander abweichen, haben Sie eine Grenze gefunden, die Aufmerksamkeit braucht.

HTTP- und SSH-Aufrufe bringen unterschiedliche Risiken in gemeinsamen Sitzungen mit sich

HTTP- und SSH-Aktionen setzen beide Berechtigungen ein, hinterlassen aber unterschiedliche betriebliche Spuren und scheitern auf unterschiedliche Weise. HTTP-Berechtigungsnachweise verweisen oft auf einen entfernten Dienst mit weitreichender API-Reichweite. SSH-Berechtigungsnachweise können eine Shell auf einem entfernten Host öffnen, wo eine einzige akzeptierte Verbindung mehrere Befehle ausführen kann. Behandeln Sie beide nicht gleich, nur weil sie von demselben lokalen Agenten stammen.

Prüfen Sie bei HTTP Ziel, Methode und Umfang des Berechtigungsnachweises. Eine Leseanfrage an eine eng begrenzte Entwicklungs-API verdient eine andere Regel als eine Schreibanfrage an einen Endpunkt zur Verwaltung von Umgebungen. Der Agent sollte die Aktion über ein lokales Gateway anfordern, das den Berechtigungsnachweis selbst einfügt. So erhält der Agent das Ergebnis und nicht das Träger-Token. Das begrenzt die Offenlegung des Geheimnisses, verringert aber nicht die Auswirkungen einer genehmigten zerstörerischen Anfrage.

Konzentrieren Sie sich bei SSH auf Hostidentität, Kontoidentität und Absicht des Befehls. Eine Verbindung zu einem Entwicklungs-Host mit einem eingeschränkten Konto unterscheidet sich deutlich von einer Verbindung zu einem gemeinsam genutzten Produktionskonto. Wenn der Berechtigungsnachweis eine interaktive Shell gewährt, behandeln Sie ihn als weitreichende Berechtigung, auch wenn der erste Befehl harmlos aussieht. Der nächste muss es nicht sein.

Fast User Switching fügt beiden Kanälen eine lokale Bedingung hinzu. Ein aktiver Agent-Prozess aus einem Konto darf nicht einfach weiter HTTP-Anfragen senden oder SSH-Sitzungen öffnen, nur weil ein anderer Benutzer den Mac aktiviert hat. Das Gateway muss die Anfrage dem ursprünglichen Prozess zuordnen und verlangen, dass der Eigentümer des Tresors die Sperre erfüllt. Der Bildschirm der zweiten Person darf nicht zur Genehmigungsfläche für den Lauf der ersten Person werden.

Verwenden Sie getrennte Berechtigungsnachweise für verschiedene Personen, wenn Verantwortlichkeit wichtig ist. Ein gemeinsames Bereitstellungs-Token erschwert die Unterscheidung zwischen einem Prozessproblem und einem Problem bei der Benutzerübergabe. Individuelle Berechtigungsnachweise und kontobezogene Tresoreinträge machen die Prüfgeschichte nützlich, wenn Sie die tatsächliche verantwortliche Person ermitteln müssen.

Manche Arbeitslasten gehören nicht auf einen gemeinsam genutzten Arbeitsplatz

Ein gemeinsam genutzter Mac eignet sich für überwachte lokale Entwicklungsarbeit mit eng begrenzten Berechtigungsnachweisen und bewussten Genehmigungen. Er eignet sich schlecht für einen lange laufenden autonomen Agenten mit der Befugnis, Produktionssysteme zu verändern, weitreichende Administrations-APIs zu erreichen oder ohne anwesende Person entfernte Shells offen zu halten.

Die Grenze verläuft nicht danach, wie clever der Agent ist. Entscheidend ist, ob die Arbeit weiter handeln kann, nachdem die verantwortliche Person die Konsole verlassen hat. Wenn das möglich ist, verwenden Sie eine dafür ausgelegte Umgebung. Geben Sie der Arbeitslast eine eigene Dienstidentität, eine festgelegte verantwortliche Person, begrenzte Berechtigungsnachweise und Datensätze, die das Betriebsteam prüfen kann, ohne die Desktop-Sitzung einer anderen Person zu übernehmen.

Verwechseln Sie ein Serverdesign nicht mit dem Design einer lokalen App. Ein Server hat ein anderes Bedrohungsmodell, andere Lebenszykluskontrollen und andere Erwartungen an die unbeaufsichtigte Ausführung. Eine Menüleisten-App auf dem Mac kann einem Entwickler eine enge menschliche Kontrolle über lokale Aktionen geben. Sie sollte nicht nur deshalb ein System für kopflose Automatisierung imitieren, weil eine Aufgabe über Nacht weiterlaufen soll.

Machen Sie für den bereits vorhandenen gemeinsam genutzten Mac die erste Regel konkret: Kein Agent behält externe Berechtigungen über eine Übergabe ohne anwesende verantwortliche Person hinweg. Testen Sie, was einen Benutzerwechsel überlebt, erzwingen Sie die Tresorsperre, wenn der Eigentümer des Berechtigungsnachweises den Arbeitsplatz verlässt, und widerrufen Sie alte Läufe, statt darauf zu hoffen, dass die nächste Person sie bemerkt. An diesem Punkt ist Fast User Switching nicht mehr nur eine praktische Desktop-Funktion, sondern erhält die Sicherheitsbehandlung, die es braucht.