Lokale KI-Agenten und CI-Jobs brauchen unterschiedliche Zugriffsmodelle

Ein Entwicklerrechner und ein Build-Runner können beide Shell-Befehle ausführen, APIs aufrufen und Code pushen. Wer sie als dieselbe Sicherheitsumgebung behandelt, landet schnell bei einem Deployment-Credential an einem Ort, an dem weder eine Person noch ein Dienst sinnvoll dafür verantwortlich gemacht werden kann.

Lokale KI-Agenten arbeiten in einer betreuten Umgebung. Eine Person kann eine Eingabeaufforderung sehen, einen Diff prüfen, eine ungewöhnliche Anfrage ablehnen und einen Prozess beenden, der sich auffällig verhält. CI-Jobs laufen, weil ein Ereignis eingetreten ist: ein Push, ein Pull Request, ein Tag, ein geplanter Lauf oder ein manueller Start. Der Job braucht eine maschinenprüfbare Berechtigung, die an dieses Ereignis gebunden ist. Er kann nicht auf die Freigabe eines Entwicklers für jeden einzelnen Aufruf warten. Ebenso sollte er nicht die dauerhaft vorhandenen Berechtigungen eines Entwicklers erben, nur weil der Workflow ausgeführt wurde.

Diese Unterscheidung ist nicht akademisch. Sie entscheidet darüber, ob ein Agent ein Geheimnis erhält, ob ein Token Minuten oder Monate existiert, was ein Audit-Eintrag aussagen muss und ob eine kompromittierte Abhängigkeit zu einem Produktionsvorfall werden kann.

Menschliche Anwesenheit verändert die Bedeutung einer Freigabe

Eine Freigabe auf einem Arbeitsplatzrechner kann eine sinnvolle Sicherheitskontrolle sein, weil eine Person anwesend ist und die unmittelbare Aktion beurteilen kann. Die Freigabe muss den Aufrufer so gut beschreiben, dass dieses Urteil möglich wird. «Ein Agent möchte eine HTTP-Anfrage stellen» ist ein schlechter Beleg. «Ein von dieser Instanz signierter Prozess, der in dieser Sitzung gestartet wurde, möchte das Produktions-Deployment-Credential verwenden» gibt der zuständigen Person etwas Konkretes zum Annehmen oder Ablehnen.

Dieses Modell hat eine klare Grenze: Eine Freigabe bedeutet, dass ein Mensch Verantwortung für einen laufenden Prozess übernimmt. Sie ersetzt keine Identität. Wenn ein schädlicher Prozess den vertrauenswürdigen Aufrufer imitieren, das Ziel verbergen oder eine Freigabe nach einer Änderung seiner Aufgabe wiederverwenden kann, ist die Eingabeaufforderung nur noch Theater.

Auf einem Entwicklerrechner brauche ich drei getrennte Zusagen:

• Der geschützte Speicher bleibt gesperrt, bis der lokale Benutzer ihn entsperrt.
• Die erste Anfrage eines neuen Prozesses erfordert eine Sitzungsentscheidung.
• Für sensible Zugangsdaten kann bei jeder Verwendung eine Entscheidung verlangt werden.

Diese Kontrollen beantworten unterschiedliche Fragen. Die Sperre entscheidet, ob überhaupt eine Aktion stattfinden darf. Die Sitzungsautorisierung entscheidet, ob dieser Prozess während dieses Laufs handeln darf. Die Freigabe pro Aufruf entscheidet, ob ein bestimmtes Credential zu folgenreich ist, um es beiläufig wiederzuverwenden. Teams fassen alle drei Kontrollen oft zu einer einzigen Schaltfläche «Agentenzugriff erlauben» zusammen und stellen später fest, dass diese Schaltfläche weit mehr freigegeben hat, als der Entwickler beabsichtigte.

Ein lokaler Agent sollte außerdem Ergebnisse erhalten, kein Credential-Material. Wenn der Agent eine API abfragen muss, kann eine Komponente außerhalb des Agenten das Credential hinzufügen, die Anfrage ausführen und die Antwort zurückgeben. So kann eine Prompt-Injection im Agenten nicht einfach einen API-Schlüssel in ein Terminal, einen Patch oder einen Chatverlauf schreiben. Ein Geheimnis zu maskieren, nachdem es in den Kontext eines Agenten gelangt ist, bietet nicht denselben Schutz. Der Agent kann es codieren, an einen anderen Host senden oder in einer Anfrage verwenden, bevor ein Maskierungsmechanismus es überhaupt sieht.

Sallyport verwendet dieses betreute Modell auf macOS: Sein Tresor bleibt hinter einem absoluten Tor, und es kann eine Autorisierung für eine Prozesssitzung oder für jede Verwendung eines ausgewählten Credentials verlangen. Das ist sinnvoll, wenn ein Entwickler anwesend ist. Für einen unbeaufsichtigten Runner wäre es die falsche Grundlage.

Ein CI-Job braucht eine überprüfbare Identität

Ein CI-Job kann menschliche Absicht nicht bei Bedarf vorlegen. Er braucht eine Workload-Identität, also eine Identität, die aus überprüfbaren Fakten über den Job abgeleitet wird und nicht aus einem Geheimnis, das in die Job-Umgebung kopiert wurde.

Zu diesen Fakten gehören bei einem Deployment-Workflow typischerweise CI-Aussteller, Repository oder Projekt, Commit oder Ref, Workflow-Identität, Umgebung und vorgesehene Zielgruppe. Der Zieldienst prüft die signierte Assertion und tauscht sie gegen ein kurzlebiges Credential. Das ist der nützliche Teil der OIDC-Föderation: Der Runner weist nach, woher dieser Job stammt, ohne einen wiederverwendbaren Cloud-Schlüssel in seinem Secret Store mitzuführen.

GitHub Actions dokumentiert dieses Muster über seinen OIDC-Token-Endpunkt und die Berechtigung id-token: write. Der Name dieser Berechtigung führt leicht in die Irre. Sie erlaubt dem Workflow, ein Identitätstoken anzufordern. Allein gewährt sie jedoch keine Deployment-Berechtigung. Die Cloud-Rolle oder der Zieldienst muss Tokens weiterhin ablehnen, deren Aussteller, Zielgruppe, Subject oder andere Claims nicht zum vorgesehenen Workflow passen.

An dieser zweiten Hälfte scheitern viele Konfigurationen. Eine Rolle, die jedes Token aus einem Repository akzeptiert, überträgt jedem passenden Workflow in diesem Repository zu viel Autorität. Eine Dokumentationsvorschau, ein Release-Workflow und ein Produktions-Deployment sollten nicht allein deshalb gleichgestellt sein, weil sie dieselbe Quellcodeverwaltung verwenden.

Verwende Claims, damit die Rolle eine einzelne Jobklasse beschreibt. Die genaue Syntax hängt von CI-Anbieter und Cloud ab, aber die Richtlinie sollte einfache Fragen beantworten:

• Welches Repository darf diese Rolle anfordern?
• Welche Workflow-Datei oder geschützte Umgebung darf sie anfordern?
• Welcher Branch, welches Tag oder welche Release-Bedingung darf sie anfordern?
• Welche Zielgruppe muss die Assertion nennen?
• Wie lange darf das ausgestellte Credential verwendbar bleiben?

Schreibe keine Richtlinienbedingungen, die du nicht in einem echten Token geprüft hast. Gib die Claims in einer sicheren Testumgebung aus, vergleiche sie mit der Vertrauensrichtlinie und teste Ablehnungsfälle. Menschen testen erfolgreiche Deployments und lassen den gefährlichen Pfad, einen Pull Request aus einem nicht vertrauenswürdigen Branch, als Annahme stehen.

Geheimnisse und Identitäten lösen unterschiedliche Probleme

Ein Geheimnis beweist, dass jemand es besitzt. Eine Identitäts-Assertion macht eine Aussage über die Workload, die Zugriff angefordert hat. Beide können am Ende zu einem Bearer-Token führen, aber die Fehlerwege unterscheiden sich stark.

Ein gespeichertes CI-Secret weiß normalerweise nicht, warum der Job es erhalten hat. Wenn ein Workflow DEPLOY_TOKEN lesen kann, können ein geändertes Skript, eine kompromittierte Action, ein schädlicher Pull-Request-Pfad oder ein Log-Befehl dieses Token überall dort verwenden, wo seine Berechtigungen es erlauben. Eine Rotation begrenzt, wie lange das Geheimnis nützlich bleibt, beschränkt aber nicht den Kontext seiner einzelnen Verwendung.

Kurzlebige Föderation macht CI nicht auf magische Weise sicher. Ein kompromittierter Job kann sein gültiges Token innerhalb seiner Lebensdauer weiterhin verwenden. Der Vorteil ist der kleinere Schadensradius: Der Angreifer muss einen geeigneten Job ausführen, die Regeln für Aussteller und Claims erfüllen und handeln, bevor das Credential abläuft. Außerdem kannst du die akzeptierende Rolle widerrufen oder ändern, ohne jedes kopierte Geheimnis finden zu müssen.

Verwechsle kurzlebige Credentials nicht mit geringen Berechtigungen. Ein Token, das zehn Minuten gültig ist und jede Produktionsdatenbank löschen kann, ist weiterhin unvertretbar. Zeitbegrenzungen reduzieren die Dauerhaftigkeit. Der Berechtigungsumfang begrenzt den Schaden. Du brauchst beides.

Beim lokalen Agentenzugriff besteht das umgekehrte Problem. Ein Entwickler kann dasselbe lokale Werkzeug in vielen Repositories und Aufgaben verwenden. Dadurch wird ein einzelner, umfassender API-Schlüssel zu einem attraktiven Ziel für einen kompromittierten Agenten. Das sicherste lokale Design hält diesen Schlüssel außerhalb des Agentenkontexts und erlaubt nur den konkreten API-Aufruf oder SSH-Befehl, den der Benutzer freigegeben hat. Wenn der externe Dienst fein abgestufte Tokens unterstützt, solltest du sie dort ebenfalls einsetzen. Ein geschützter Tresor kann ein übermäßig mächtiges Token nicht verbessern, sobald die Anfrage den Rechner verlässt.

Der gefährliche Komfort ist ein Token für beide Welten

Das persönliche Token eines Entwicklers in CI zu verwenden, ist beliebt, weil sich damit ein blockiertes Deployment schnell fortsetzen lässt. Gleichzeitig ist es eine der schlechtesten Methoden, Verantwortlichkeit zu verwischen.

Ein persönliches Token reicht oft weiter, als die Pipeline es benötigt. Es kann einem Mitarbeiter gehören, der das Team wechselt, das Unternehmen verlässt, es vom Laptop aus verwendet und dessen Zugriff durch persönliche Mitgliedschaften statt durch Deployment-Aufgaben geprägt ist. Taucht es in CI auf, kann ein Audit-Log zwar zeigen, dass das Token gehandelt hat. Es kann aber nicht wahrheitsgemäß sagen, ob die Aktion vom Entwickler oder von einem Release-Job ausging.

Der umgekehrte Fehler kommt ebenfalls vor. Teams geben einem lokalen Agenten ein CI-Deployment-Secret, damit er «dasselbe testen» kann. So erhält interaktive Codegenerierung eine unbeaufsichtigte Produktionsfähigkeit, oft mit weniger Prüfungen als im Release-Workflow. Auch die Reaktion auf Vorfälle wird dadurch quälend schwierig: Hat der Agent das Credential verwendet, ein Shell-Skript oder ist der kopierte Wert in ein anderes Werkzeug gelangt?

Gib jeder Umgebung ihre eigene Autorisierungsgrenze. Ein lokaler Entwickler kann interaktiven, widerrufbaren Zugriff auf einen Entwicklungsendpunkt erhalten. Ein Release-Job kann eine föderierte Rolle bekommen, die auf eine geschützte Produktionsumgebung begrenzt ist. Ein Pull-Request-Job kann überhaupt keine Schreibberechtigung haben. Das sind keine Unbequemlichkeiten, die man glätten sollte. Sie liefern später den Nachweis, mit dem du erklären kannst, warum eine Aktion erlaubt war.

Eine nützliche Namensregel lautet: Credential-Namen sollten sowohl Akteur als auch Zweck erkennen lassen. ci-release-prod-deploy sagt einem Prüfer viel mehr als deploy-token. Noch besser ist, wenn der CI-Job überhaupt kein Token mit diesem Namen speichert. Er fordert eine identitätsgebundene Rolle an, deren Vertrauensrichtlinie denselben Zweck festlegt.

Der Zustand des Runners macht temporären Zugriff zu Rückständen

Ein Job kann ein temporäres Credential verwenden und trotzdem dauerhafte Probleme hinterlassen. Häufige Lecks finden sich in Logs, Shell-Trace-Ausgaben, zwischengespeicherten Home-Verzeichnissen, Docker-Layern, Workspace-Artefakten und Dateien, die von Drittanbieter-Actions geschrieben wurden.

Selbst gehostete Runner verdienen besondere Vorsicht, weil sie Zustand zwischen Jobs behalten können. Ein Job, der nicht vertrauenswürdigen Code auscheckt, kann eine veränderte ausführbare Datei platzieren, einen gemeinsamen Cache ändern, einen zurückgebliebenen Workspace untersuchen oder darauf warten, dass ein privilegierter Workflow den Host wiederverwendet. Eine Trennung nach Repository-Namen hilft nicht, wenn Jobs dasselbe Betriebssystemkonto, denselben Container-Socket oder dasselbe Dateisystem nutzen.

Kurzlebige Runner entfernen eine große Klasse von Rückständen, weil der Runner nach dem Job verschwindet. Die Eingaben des Workflows müssen trotzdem kontrolliert werden. Ein privilegierter Job, der Skripte aus einem nicht vertrauenswürdigen Pull Request ausführt, übergibt weiterhin Autorität an nicht vertrauenswürdigen Code, selbst auf einem frischen Rechner.

GitHub Actions warnt davor, dass pull_request_target im Kontext des Basis-Repositorys läuft und Zugriff auf Secrets oder Schreibberechtigungen haben kann. Das Ereignis hat einen legitimen Zweck: Maintainer können einen Pull Request aus einem Fork kennzeichnen oder kommentieren. Das Problem entsteht, wenn ein durch dieses Ereignis ausgelöster Workflow den Head-Commit des Pull Requests auscheckt und dessen Skripte ausführt. Der Workflow hat dann vertrauenswürdige Credentials mit angreiferkontrolliertem Code kombiniert.

Halte das Muster unspektakulär:

• Führe nicht vertrauenswürdigen Pull-Request-Code ohne Deployment-Berechtigung aus.
• Reserviere den Zugriff auf geschützte Umgebungen für geprüfte Refs und kontrollierte Workflow-Pfade.
• Pinnen Drittanbieter-Actions, wo es dein Prozess erlaubt, auf unveränderliche Commit-Referenzen.
• Halte Geheimnismaterial aus Caches, Artefakten und Diagnoseausgaben heraus.
• Zerstöre sensible Runner-Instanzen nach dem Job.

Der erste und der vierte Punkt verhindern mehr reale Vorfälle als ausgefeilte Token-Namenskonventionen. Ein perfekt begrenztes Credential ist trotzdem verloren, wenn ein Shell-Befehl es ausgibt oder ein Artefakt seine Konfigurationsdatei enthält.

Eine Deployment-Identität sollte in einer Datei prüfbar sein

Ein Workflow sollte sichtbar machen, wie er externe Autorität anfordert. Dieses Beispiel für GitHub Actions fordert eine OIDC-Identität nur im Deployment-Job an und deklariert eine Produktionsumgebung. Es enthält absichtlich kein gespeichertes Cloud-Credential.

name: deploy

on:
  push:
    tags:
      - "v*"

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@<full-commit-sha>
      - name: Request deployment identity
        run: |
          token=$(curl -sS \
            -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
            "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=deploy.example.internal")
          test -n "$token"
      - name: Deploy
        run: ./scripts/deploy.sh

Der eigentliche Austausch nutzt normalerweise eine Action oder eine Cloud-CLI, statt die Antwort in einer Shell-Variable zu speichern. Wichtig ist hier die Form der Anfrage: GitHub stellt ein einmaliges Anfrage-Token und eine URL bereit, der Workflow fordert eine bestimmte Zielgruppe an und das Ziel entscheidet anschließend, ob diese Identität eine Rolle übernehmen darf. Der Runner sollte das daraus entstehende Identitätstoken niemals als allgemeines API-Credential behandeln.

Deine cloudseitige Vertrauensrichtlinie muss ein Token ablehnen, wenn seine Claims diesen Release-Kontext nicht identifizieren. Kopiere kein Provider-Beispiel und belasse es dabei. Provider-Beispiele beginnen oft bewusst breit, weil sie für viele Benutzer funktionieren müssen. Begrenze Repository, Umgebung, Branch oder Tag sowie Zielgruppe, bevor die Rolle Produktion verändern kann.

Wenn ein Ziel OIDC nicht direkt prüfen kann, schalte einen kleinen Credential-Broker davor. Der Broker prüft die CI-Assertion, ordnet Claims eng definierten Aktionen zu, stellt ein temporäres Ziel-Credential aus und protokolliert diese Zuordnung. Löse diese Einschränkung nicht, indem du ein dauerhaftes Ziel-Secret in jeden Workflow legst, der den Dienst benötigt.

Bei SSH wird der Unterschied besonders deutlich

SSH-Schlüssel eignen sich schlecht als gemeinsame CI-Ausstattung. Ein privater Schlüssel in einem CI-Secret kann sich aus jedem Job authentifizieren, der ihn lesen darf. Sein öffentlicher Teil sagt dem Ziel nur selten, welche Repository-Revision die Verbindung angefordert hat. Erzwungene Befehle, Quellenbeschränkungen und getrennte Konten können den Schaden begrenzen, aber die grundlegende Identität bleibt ein wiederverwendbarer privater Schlüssel.

Für lokale Arbeit kann SSH ein interaktives Tor brauchen, weil ein Entwickler sehen kann, dass ein Agent eine Verbindung zu einem bestimmten Host herstellen möchte. Der private Schlüssel sollte in geschütztem Speicher bleiben, und der Agent sollte einen konkreten Befehl anfordern, statt direkten Zugriff auf den Schlüssel zu erhalten. Der Host muss weiterhin seine eigenen Kontoberechtigungen und Befehlsbeschränkungen durchsetzen. Die lokale Freigabe kontrolliert den Ausgangspunkt. Sie macht einen gefährlichen entfernten Befehl nicht sicher.

Für CI solltest du kurzlebige SSH-Zertifikate bevorzugen, wenn deine SSH-Zertifizierungsstelle und deine Zielsysteme sie unterstützen. Der Job nutzt Workload-Föderation, um ein Zertifikat mit kurzer Gültigkeit, einem eingeschränkten Principal und möglicherweise einem erzwungenen Befehl anzufordern. Das Ziel prüft die Zertifizierungsstelle, statt dauerhaft einen kopierten privaten Schlüssel zu akzeptieren.

Wenn Zertifikate nicht verfügbar sind, verwende ein eigenes Deployment-Konto und einen dedizierten privaten Schlüssel pro Deployment-Klasse. Beschränke dieses Konto in authorized_keys und auf dem Server. Eine minimale Einschränkung sieht so aus:

command="/usr/local/bin/receive-release",no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ci-release

Diese Zeile verhindert, dass der Schlüssel eine beliebige interaktive Shell öffnet, und zwingt den Server, ein einziges Empfängerprogramm auszuführen. Sie identifiziert das Quell-Repository nicht von selbst. Wenn die Release-Entscheidung vom Repository-Kontext abhängt, kombiniere sie mit einem vermittelten, kurzlebigen Schlüssel oder einem anderen verifizierten Workload-Signal.

Setze in einem CI-Skript nicht StrictHostKeyChecking=no, nur damit SSH funktioniert. Dadurch wird die Identitätsprüfung des Servers genau dort abgeschaltet, wo Runner leicht umgeleitete Verbindungen ermöglichen. Stelle bekannte Host-Schlüssel über einen kontrollierten Mechanismus bereit, rotiere sie bewusst und lasse einen Job fehlschlagen, wenn sich die Host-Prüfung unerwartet ändert.

Audit-Aufzeichnungen müssen unterschiedliche Fragen beantworten

Ein Aktionslog, das nur «Deployment erfolgreich» sagt, ist Betriebsausgabe und kein ausreichender Sicherheitsnachweis. Du musst rekonstruieren können, wer oder was Autorität erhalten hat, welche Anfrage gestellt wurde und ob der Datensatz selbst später verändert wurde.

Bei einem betreuten lokalen Agenten solltest du lokale Prozessidentität, Sitzungsbeginn, Freigabeentscheidung, Credential-Bezeichnung oder Aktionsklasse, Ziel, Anfragezeit und Ergebnis erfassen. Speichere keine Geheimniswerte und keine vollständigen sensiblen Nutzdaten. Eine Prozesssignatur oder Codesignatur-Instanz ist nützlicher als ein beliebiger Prozessname, weil Namen leicht kopiert werden können.

Für CI solltest du CI-Anbieter, Run-ID, Repository, Workflow-Referenz, Commit-SHA, den auslösenden Akteur, soweit verfügbar, Runner-Klasse, OIDC-Subject und Zielgruppe, Zielrolle, sicher speicherbare Aktionsparameter und Ergebnis erfassen. So kann ein Ermittler ein markiertes Release von einem manuell erneut gestarteten Job unterscheiden und einen vertrauenswürdigen Workflow von einer versehentlich zu breit vergebenen Berechtigung.

Halte Autorisierungslogs von Anwendungslogs getrennt. Anwendungslogs können veränderbar, stichprobenartig erfasst oder im normalen Betrieb gelöscht werden. Eine Autorisierungsspur braucht ein Anhängen-ohne-Überschreiben-Verhalten und unabhängige Prüfung. Hash-Verkettung erkennt Änderungen an der Reihenfolge, wenn du die Kette aufbewahrst und mit erwarteten Datensätzen vergleichst. Sie verhindert jedoch nicht, dass ein Angreifer künftige Einträge unterbindet. Übertrage die Aufzeichnungen deshalb, wenn das Design es erlaubt, von der kompromittierten Maschine weg.

Sallyport erstellt Sitzungs- und Einzelaktionsjournale aus einem schreibgeschützten, verschlüsselten und Hash-verketteten Audit-Log. sp audit verify prüft die Kette offline, ohne einen Tresorschlüssel zu benötigen. Das ist ein nützlicher Nachweis für Aktionen betreuter Agenten. CI sollte in den Systemen, die seine Identitäten ausstellen und akzeptieren, eine entsprechende an die Workload gebundene Spur erzeugen.

Freigabeermüdung ist ein Fehler des lokalen Designs

Eine Freigabe pro Aufruf kann lokale Credentials mit großer Wirkung schützen. Wenn aber für jeden harmlosen Lesezugriff eine Eingabeaufforderung erscheint, lernen Menschen, Freigaben ohne Lesen zu bestätigen. Dann wird die Kontrolle zum Ritual, und ein Angreifer muss nur auf Routinearbeit warten.

Verwende eine Freigabe pro Aufruf für Aktionen, deren Folgen schwer umkehrbar sind: Schreibzugriffe in Produktion, DNS-Änderungen, organisationsweite Administration, erzwungene Pushes in der Quellcodeverwaltung oder Befehle auf sensiblen Hosts. Nutze eine Sitzungsautorisierung für wiederholte Aktionen mit geringem Risiko, die ein Entwickler während eines Agentenlaufs vernünftigerweise delegieren kann. Halte das Tresortor getrennt, damit ein gesperrter Rechner alle Aktionen verweigert, auch wenn noch eine alte Sitzungsfreigabe besteht.

CI hat seine eigene Form der Ermüdung: manuelle Freigabetore, die bei jedem Job erscheinen und bestätigt werden, weil der Zeitplan für Releases wichtiger geworden ist. Eine Freigabe der geschützten Umgebung kann für ein Produktions-Deployment sinnvoll sein. Sie sollte aber ein eindeutig identifiziertes Release-Artefakt und Ziel freigeben. Sie sollte keinen Workflow mit nicht vertrauenswürdigem Code, keine Rolle mit weit gefassten Claims und keinen Runner mit unbekanntem Zustand kompensieren.

Eine praktische Prüfung stellt eine unangenehme Frage: Was könnte einen Monat lang laufen, wenn diese Freigabe automatisch angeklickt würde? Bei lokalen Agenten verkleinerst du die freigegebene Aktionsfläche, bis die Antwort vertretbar ist. Bei CI entfernst du die Freigabe aus gewöhnlichen Maschinenaktionen und bindest die Autorität stattdessen an die Identität des Jobs.

Trenne die Pfade vor der nächsten Credential-Anfrage

Wenn ein Agent oder eine Pipeline Zugriff anfordert, klassifiziere den Aufrufer, bevor du einen Mechanismus für Geheimnisse auswählst. Ist eine Person anwesend und kann sie die Aktion prüfen? Ist der Aufrufer eine wiederholbare Workload mit Claims, die du validieren kannst? Kann der Aufrufer ein begrenztes Ergebnis statt eines Credentials erhalten? Passt die Berechtigung des Ziels zu einer eindeutig benannten Aufgabe?

Wenn der Aufrufer ein lokaler Agent ist, schütze Credentials außerhalb seines Kontexts, erhalte einen sinnvollen Freigabepfad und protokolliere jede Aktion so, dass ein Entwickler sie prüfen kann. Wenn der Aufrufer CI ist, verwende kurzlebige Föderation, binde Rollen an Workflow-Claims, isoliere den Runner und erfasse die Workload-Fakten, die den Aufruf autorisiert haben.

Lass ein gemeinsames Token diese Grenze nicht verwischen, nur weil es heute schneller geht. Der nächste Vorfall wird dich zwingen, sie wiederherzustellen, während du herauszufinden versuchst, ob tatsächlich eine Person, ein Agent oder ein Runner gehandelt hat.