Ereignisse außerhalb der Weboberfläche tragen im Audit-Log von GitHub Angaben zur Authentifizierung. Zwei Felder ordnen eine solche Aktion zu: actor, das handelnde Konto, und hashed_token, ein SHA-256-Hash des verwendeten Tokens. Ein Coding Agent kann am Entwicklerrechner gh aufrufen. Er kann auch git aufrufen, wenn gh auth setup-git gh als Credential-Helper eingerichtet hat. In diesem Setup nutzt der Agent in beiden Fällen das Token, das gh auth login im Credential-Store abgelegt hat. Die Anmeldung läuft dabei standardmäßig über den Browser, das Token ist also nicht zwingend ein Personal Access Token. Dann stehen im Log dasselbe Konto und derselbe Hash wie bei jedem Push, den der Entwickler selbst ausführt. Ein Prüfer, der wissen will, ob eine Änderung von einem Menschen oder von einem Agenten stammt, findet in diesen Feldern keine Antwort. Die Anzeige von Token-Daten zu Git-Ereignissen ist bei GitHub noch eine Public Preview (Stand: 15. September 2026).
Gemeint ist in diesem Text durchgehend die Identität gegenüber Zielsystemen wie Git-Hostern, CI und MCP-Servern. Die Anmeldung beim Modellanbieter ist ein eigenes Thema. Wer Agenten gerade erst im Team einführt, findet den Rahmen dafür im Einführungsleitfaden für KI-Coding-Agents.
Ein geteiltes Token unterscheidet Mensch und Agent nicht
Das ist kein Sonderfall einzelner Teams. Die Cloud Security Alliance hat im Januar 2026 online 228 IT- und Security-Fachleute befragt, im Auftrag von Aembit, einem Anbieter von Zugriffsverwaltung für Agenten. 68 % der Befragten können die Aktivitäten von Menschen und Agenten nicht klar voneinander unterscheiden. 31 % lassen Agenten unter menschlichen Nutzeridentitäten arbeiten. Die Stichprobe ist klein und der Auftraggeber verkauft die passende Lösung. Die Ergebnisse passen dennoch zum beschriebenen Mechanismus im Audit-Log.
„Der Agent nutzt mein Token“ reicht nicht, um die Lücke genau zu benennen. Dafür braucht es zwei Begriffe, die im Alltag oft durcheinandergehen. Der eine beschreibt ein Programm, das als Mensch auftritt. Der andere beschreibt ein Programm, das im Auftrag dieses Menschen handelt.
Nutzerkonto, Service Account, Agent Identity: wer im Token steht
Eine Agent Identity ist eine eigene, eindeutig identifizierbare Identität für einen KI-Agenten. Technisch ist sie eine Workload Identity, also die Identität eines laufenden Dienstes statt einer Person. Für sie gelten eigene Regeln für Lebenszyklus, Verantwortung und Audit. Sie kennzeichnet den Agenten statt eines Menschen, lässt sich aber einem verantwortlichen Menschen zuordnen. Handelt der Agent im Auftrag eines Menschen, ist auch dieser Auftraggeber erkennbar. Das schließt nicht aus, dass auch ein Service Account einem Menschen zugeordnet ist.
Service Account und Agent Identity fallen beide unter den Oberbegriff Non-Human Identity. Das OWASP-Projekt Non-Human Identities Top 10 meint damit Identitäten von Anwendungen, Workloads, APIs, Bots und automatisierten Systemen, die kein Mensch steuert und die oft an keinen Menschen gebunden sind. KI-Agenten nennt die Fassung 2025 nicht eigens. Sie gehören trotzdem in diese Kategorie, denn Microsoft Entra und Google Cloud bauen ihre Agentenidentitäten beide auf Workload-Identitäten auf.
| Nutzerkonto | Service Account | Agent Identity | |
|---|---|---|---|
| Wer authentifiziert sich? | ein Mensch | ein Programm, teils mehrere Workloads mit demselben Konto | der Agent selbst, bei Google standardmäßig mit nicht geteilter Identität |
| Wer trägt die Verantwortung? | die Person | nicht zwingend ein benannter Mensch | ein benannter Mensch, bei Microsoft verpflichtend als Sponsor |
| Wie lange gilt das Credential? | Sitzung oder Token, Ablauf je nach Richtlinie | langlebige Schlüssel sind möglich | Laufzeit je nach Produkt und Konfiguration, bei Google ohne langlebige Schlüssel |
| Wem ist die Aktion zuordenbar? | der Person | dem Konto, einem Menschen nur über eine dokumentierte Zuordnung | dem Agenten und bei delegierten Aktionen zusätzlich der beauftragenden Person |
Die Unterscheidung, auf die es hier ankommt, steht schon in RFC 8693 vom Januar 2020. Der Standard für OAuth 2.0 Token Exchange regelt, wie ein Dienst ein Token gegen ein anderes eintauscht. In Abschnitt 1.1 unterscheidet er zwei Fälle. Bei Impersonation erhält A alle Rechte von B und ist in diesem Kontext von B nicht zu unterscheiden. Bei Delegation behält A eine eigene, von B getrennte Identität und handelt in Vertretung von B.
Im Token zeigt sich Delegation am Claim act (Abschnitt 4.1). Dieses Feld hält fest, dass delegiert wurde, und benennt den handelnden Akteur.
Die OpenID Foundation hat das im Oktober 2025 in einem Whitepaper auf Agenten übertragen. Bei einem echten On-behalf-of-Ablauf enthält das Token demnach zwei unterscheidbare Identitäten: die des Nutzers im Feld sub und die des Agenten in act oder azp. Impersonation nennt das Papier undurchsichtig, weil sie Verantwortungslücken erzeugt.
Im Delegationsbeispiel rechts bezeichnet sub den Menschen und act den handelnden Agenten. So kann das Zielsystem beide unterscheiden.
Für Coding Agents folgt daraus ein einfacher Maßstab. Nennt das Token den Menschen als Subjekt und den Agenten als handelnden Akteur, etwa über sub und act, handelt der Agent im Auftrag. Steht dort nur der Mensch, ist es Impersonation, ganz gleich, wie sorgfältig der Agent arbeitet. Ob ein Coding Agent beim Zugriff auf ein Zielsystem als eigener Akteur erkennbar ist, hängt vom jeweiligen Setup ab. Zunächst geht es um den lokalen Einsatz auf dem Entwicklerrechner.
Lokal arbeitet der Agent mit den Git-Zugangsdaten des Entwicklers
Für den Agentenmodus von GitHub Copilot schreibt die VS-Code-Dokumentation: „Commands and tools run with your credentials.“ Der Agent bekommt also dieselben Berechtigungen wie der angemeldete Mensch.
Claude Code hat lokal ebenfalls keine eigene Git-Identität. Die Doku zu GitHub Enterprise Server verweist auf „the machine's existing git credentials“ und auf eine eingerichtete gh CLI (Stand: September 2026). Für den Hoster ist das reine Impersonation, denn der Agent legt das Token des Menschen vor.
Was dieses Token darf, darf auch der Agent. Ein klassisches GitHub Personal Access Token kann laut GitHub auf alle Repositories aller Organisationen zugreifen, für die sein Besitzer berechtigt ist, soweit die Scopes des Tokens und die Richtlinien der Organisation das zulassen. Über den Credential-Helper aus der Einleitung gilt das auch für jeden git push.
Es gibt auch Tokens mit engerem Zuschnitt. Fine-grained PATs lassen sich bei GitHub auf einen Owner und einzelne Repositories begrenzen, und für Ressourcen einer Organisation brauchen sie standardmäßig deren Freigabe. Ein Ablaufdatum ist für GitHub-PATs keine Pflicht. Organisationen können aber per PAT-Policy eine Höchstlaufzeit von 1 bis 366 Tagen erzwingen.
GitLab ist strenger. Dort brauchen neue Personal Access Tokens regulärer Nutzer ein Ablaufdatum, voreingestellt sind höchstens 365 Tage. Seit GitLab 17.6 lässt sich das Maximum unter bestimmten Voraussetzungen auf 400 Tage erweitern. Für Project und Group Access Tokens legt GitLab jeweils einen eigenen Bot-Nutzer an, dem die Beiträge zugeordnet werden. Der lokale Agent nimmt trotzdem das Token, das auf der Maschine eingerichtet ist.
Als Spur bleibt der Commit. Claude Code setzt standardmäßig den Trailer Co-Authored-By: <Modellname> <noreply@anthropic.com>. Die Einstellungsreferenz zeigt direkt daneben, wie man ihn entfernt: „To hide all attribution, set commit and pr to empty strings“ (Stand: September 2026).
Jedes Werkzeug hat hier eine andere Voreinstellung. Bei Cursor ist die Attribution standardmäßig eingeschaltet, Enterprise-Admins können sie zentral abschalten (Stand: September 2026). VS Code hat den Standardwert von git.addAICoAuthor zwischen Version 1.110 und 1.119 dreimal geändert, seit 1.119 steht er für Commits über die Git-Oberfläche von VS Code auf off.
Technisch ist ein Trailer nur eine Textzeile in der Commit-Nachricht. Jeder kann sie schreiben oder löschen, und der Hoster prüft sie nicht.
Im gezeigten Setup nutzen Mensch und Agent dasselbe Token. Die Felder actor und hashed_token unterscheiden ihre Aktionen deshalb nicht. Der Commit-Trailer ist nur ein nicht authentifizierter Hinweis.
Wie viel trotzdem an dieser Zeile hängt, zeigt der State of Secrets Sprawl 2026 von GitGuardian. Der Herstellerbericht wertet geleakte Secrets in Claude-Code-Commits gesondert aus und erkennt diese Commits am Co-Autor-Trailer. GitGuardian warnt selbst davor, die Ergebnisse als bloßes Versagen des Werkzeugs zu deuten.
Die Auswertung erfasst nur öffentliche Repositories, und Agenten-Commits ohne Trailer erkennt sie nicht als solche. Selbst diese Messung hängt an einer Zeile, die ein leerer String in den Einstellungen unterdrückt.
Man kann einwenden, ein beaufsichtigter Agent sei wie die IDE ein Werkzeug und brauche deshalb ebenso wenig ein eigenes Konto. Die OpenID Foundation räumt ein, dass die bestehende Infrastruktur heute noch reicht, weil Agenten noch relativ einfach sind und oft von Menschen beaufsichtigt werden. Der Druck wachse erst mit mehr Autonomie und mit Sub-Agenten.
An der nächsten Stelle ist mehr Ordnung zu erwarten, denn für MCP-Server gibt es eine Spezifikation mit einem eigenen Kapitel zur Autorisierung.
MCP Auth in der Praxis: ein Token für alle
Nach der Autorisierungsspezifikation der MCP-Revision 2026-07-28 sind geschützte HTTP-Server OAuth-2.1-Resource-Server, also Dienste, die Zugriffstokens eines separaten Autorisierungsservers prüfen. Sie müssen sicherstellen, dass ein Token tatsächlich für sie ausgestellt wurde.
Außerdem ist Token Passthrough verboten. Ein Server darf das Token des Clients also nicht an Upstream-APIs weiterreichen. Die Security Best Practices begründen das mit Nachvollziehbarkeit. In den Logs nachgelagerter Systeme sähe es sonst so aus, als kämen die Anfragen von einer anderen Quelle mit einer anderen Identität.
Für lokale stdio-Server gilt ein anderer Ansatz. Laut Spezifikation ist Autorisierung für MCP-Implementierungen insgesamt optional. Lokale stdio-Server sollten ihre Zugangsdaten aus der Umgebung beziehen, statt dem beschriebenen Autorisierungsverfahren zu folgen. Wer den Server einrichtet, legt fest, welches Token dort liegt und wem es gehört.
Im Release v1.12.1 vom 8. September 2026 meldet sich der GitHub MCP Server beim lokalen Einsatz standardmäßig per OAuth an. Ist GITHUB_PERSONAL_ACCESS_TOKEN gesetzt, hat das dort hinterlegte Token aber Vorrang. Die Beispiele im README zeigen das PAT weiterhin in der JSON-Konfiguration.
Was dann im Log des Zielsystems steht, dokumentiert Atlassian für den eigenen Rovo MCP Server. Laufen Tool-Aufrufe über ein API-Token unter einem Service Account oder technischen Nutzer, ordnen die Logs die Aktionen diesem Konto zu und nicht den einzelnen Endnutzern.
Beim Postgres-Referenzserver des MCP-Projekts (seit Mai 2025 archiviert) ist das schon so gebaut. Die Zugangsdaten stehen im Connection String, jede Abfrage läuft unter demselben Datenbanknutzer. Welche Person eine Abfrage ausgelöst hat, lässt sich damit grundsätzlich nicht feststellen.
Dazu kommt eine Beobachtung aus der Praxis: In Teamkonfigurationen steht oft ein einziges Token, das alle nutzen. Am Zielsystem erscheint das ganze Team dann als ein Konto. Wie verbreitet solche Konfigurationen sind, misst keine Studie. Welche Anforderungen an Scope, Tokens und Audit ein MCP-Server erfüllen sollte, fasst der Grundlagenbeitrag zu MCP-Servern zusammen.
Laut Post-Mortem von Railway vom 29. April 2026 fand ein KI-Agent auf der Festplatte ein langlebiges Token mit kontoweitem Zugriff und rief damit volumeDelete für eine Produktionsdatenbank auf. Die API sah ein gültiges Token, sonst nichts.
Im gezeigten Setup erscheint das Team bei einem geteilten Token unter demselben Konto. Nutzerbezogenes OAuth macht die einzelne Person erkennbar, aber noch nicht den handelnden Agenten.
Welche Identität das Zielsystem protokolliert, hängt also vom Authentifizierungsweg ab. Nutzerbezogenes OAuth und geteilte technische Konten sind dabei unterschiedliche Fälle. Was das Protokoll darüber hinaus bietet, etwa die seit Juni 2026 stabile Enterprise-Managed Authorization, ordnet der Beitrag zu MCP als Control Plane für Agenten ein. In den beschriebenen Betriebsmodellen weist das Log des Zielsystems das Konto aus, zu dem die verwendeten Zugangsdaten gehören. In den hier geprüften Setups zeigt das Log Agent und Mensch nur dann getrennt, wenn die Plattform die Delegation selbst protokolliert.
In CI und Cloud handeln Agenten schon im Auftrag
Bei GitLab steht die Antwort auf die Prüferfrage wörtlich im Audit-Event. Laut Audit-Event-Schema speichert GitLab seit Version 19.3 dort <Service Account> on behalf of @<user> als Autor und zusätzlich die human_author_id der Person. Die composite identity der GitLab Duo Agent Platform vereint die Identitäten des Service Accounts und des auslösenden Menschen in einem Token. Dabei gilt die restriktivere der beiden Rollen. Commits macht der Service Account, Merge Requests werden dem Menschen zugeordnet. Die composite identity selbst ist seit GitLab 18.8 (Januar 2026) allgemein verfügbar.
Die Grenze folgt auf dem Fuß. Chat in UI und IDE ist ausgenommen, und ein gewöhnlicher Pipeline-Job kennt überhaupt keinen Agenten. Das CI_JOB_TOKEN erhält die Zugriffsstufe der Person, die die Pipeline ausgelöst hat. Die ID Tokens tragen deren user_login, aber keinen Agenten-Claim. Ein Agent, der als Skript im Job läuft, erbt diese Zugriffsstufe.
GitHub trennt beim Copilot cloud agent (bis April 2026 „Copilot coding agent“) beide Rollen. Die Commits nennen Copilot als Autor und sind signiert. Die beauftragende Person ist als Co-Autor angegeben. Sie darf den Pull Request nicht genehmigen, und Copilot selbst kann weder genehmigen noch mergen. Seit dem 1. September 2026 kann Copilot Code Review in einer Public Preview allerdings Freigaben erteilen, die auf die Pflichtfreigaben angerechnet werden. Die Funktion ist standardmäßig deaktiviert. Ob das auch für PRs des Cloud Agent gilt, ist nicht dokumentiert.
Belastbarer als der Co-Autor-Eintrag ist das Audit-Log. Seit Februar 2026 enthalten die Einträge die Felder actor_is_agent und user. Damit lässt sich laut GitHub-Changelog erkennen, in wessen Auftrag der Agent handelt. Sitzungen in VS Code und in der Copilot CLI erfasst das Log laut GitHub noch nicht (Stand: September 2026).
Keine einzelne Spur belegt die Beteiligung vollständig. Der Beitrag zur Incident Response bei KI-generiertem Code zeigt deshalb, wie diese Felder nach einem Vorfall zusammen mit anderen Spuren ausgewertet werden müssen.
Cursor bietet ein kurzlebiges Credential mit einer eigenen Agentenkennung. Das OIDC-Token eines Cursor Cloud Agent gilt fünf Minuten und trägt immer eine cloud_agent_id. Dazu kommen owner_user_id und owner_email, sofern bekannt. Eintauschen lässt es sich bei AWS, GCP, Azure und Vault. Wo CI-Plattform und Zielsystem es unterstützen, gehört dieses Muster in die CI: Workload Identity Federation per OIDC statt langlebiger Secrets.
Die großen Identitätsplattformen reichen bislang nicht bis dorthin. Microsoft Entra Agent ID nutzt einen eigenen On-Behalf-Of-Ablauf mit eigenen Claims, eine Anbindung an GitHub, Azure DevOps oder CI ist nicht auffindbar. Google Cloud Agent Identity speichert für den Zugriff auf GitHub nur OAuth-Tokens von Nutzern. Mit Okta lässt sich eine Agentenidentität gegenüber MCP-Servern nutzen, nicht aber gegenüber Git-Hostern oder CI-Systemen.
Claude Code GitHub Actions: eigene App, Auftraggeber nur per Prompt
Die claude-code-action tauscht standardmäßig das OIDC-Token des Workflows gegen ein kurzlebiges, auf das Repository begrenztes Token der Claude GitHub App. Im Git-Log steht dann claude[bot]. Die auslösende Person steht nur in einer Co-authored-by-Zeile. Diese Zeile schreibt das Modell, weil der Prompt es vorgibt. Erzwungen wird sie nicht (Stand: Commit 9cdae7f vom 12. September 2026).
In CI ist die GitHub App damit die bessere Wahl: Wer der Action ein eigenes github_token mitgibt, lässt ihre Kommentare unter der Identität dieses Tokens erscheinen. Ist das ein Personal Access Token des Entwicklers, stehen die Kommentare des Agenten unter dessen Konto.
Unter den geprüften Setups protokollieren nur GitLab Duo und der Copilot cloud agent, welcher Agent im Auftrag welcher Person handelt. Cursor nennt einen Owner, der nicht unbedingt der Auftraggeber der jeweiligen Aktion ist.
Bei GitLab Duo und beim Copilot cloud agent bildet das Log Delegation also ab: Es nennt pro Aktion den Agenten und den Menschen, in dessen Auftrag er handelt. Cursor schreibt eine Agentenkennung ins Token und ergänzt Angaben zum Owner, sofern sie bekannt sind. Diese Angaben belegen nicht automatisch, wer den Auftrag für die jeweilige Aktion erteilt hat. In den geprüften Beispielen hängt die Zuordnung von bestimmten Plattformfunktionen ab. Eine getrennte Zuordnung von Agent und Mensch im Audit-Log fehlt bei den hier betrachteten lokalen Sitzungen, Pipeline-Skripten und der Action mit Prompt-Trailer. Wie schwer diese Lücke wiegt, wenn ein Prüfer Identifizierbarkeit verlangt, behandelt keine der hier ausgewerteten Herstellerdokumentationen.
Mensch oder Agent? Was DORA und NIS2 tatsächlich verlangen
Wer in den geprüften Stellen von DORA, NIS2 oder ISO/IEC 27001 ein pauschales Verbot geliehener oder geteilter Identitäten sucht, findet keins. Eingeschränkt werden geteilte Identitäten trotzdem, auf unterschiedliche Weise: DORA setzt auf Minimierung und jederzeitige Zuordnung, die NIS2-Durchführungsverordnung auf Genehmigung und Dokumentation.
Die Delegierte Verordnung (EU) 2024/1774 enthält die technischen Regulierungsstandards zum IKT-Risikomanagement unter DORA. In Art. 20 Abs. 1 verlangt sie, zugreifende Menschen und Systeme eindeutig zu identifizieren und zu authentifizieren. Art. 21 lit. c wird konkreter: Generische und geteilte Nutzerkonten sind so weit wie möglich einzuschränken, und Nutzer müssen für ihre Aktionen in IKT-Systemen jederzeit identifizierbar sein. Erwägungsgrund 14 lässt geteilte Konten ausnahmsweise zu, wenn die Verantwortlichkeit gewahrt bleibt.
Wie ein Coding Agent im Sinne von Art. 20 einzuordnen ist, untersucht dieser Beitrag nicht. Eine ausdrückliche Pflicht, im Hoster-Log Mensch und Agent zu unterscheiden, findet sich in den geprüften Stellen ebenfalls nicht. Bei der Zuordnung nach Art. 21 lit. c stößt das Hoster-Log aus dem ersten Abschnitt aber an eine technische Grenze: Es nennt zu jeder Aktion einen Nutzer, doch Konto und Token-Hash zeigen nicht, ob er selbst gehandelt hat oder ein Agent mit seinem Token.
Die NIS2-Durchführungsverordnung (EU) 2024/2690 verlangt im Anhang unter Nr. 11.5.2 eindeutige Identitäten auch für Systeme. Identitäten, die mehreren Personen zugewiesen sind, lässt Nr. 11.5.3 nur zu, wenn sie geschäftlich oder betrieblich nötig sind. Dann braucht es ein ausdrückliches Genehmigungsverfahren und eine Dokumentation.
Nach § 30 Abs. 3 BSIG ist diese Verordnung allerdings nur für einzelne Einrichtungsarten bindend, etwa Cloud-Anbieter, Rechenzentren und Managed Service Provider. Für alle anderen ist sie eine Auslegungshilfe. § 30 Abs. 2 Nr. 9 BSIG selbst fordert Konzepte für die Zugriffskontrolle, von eindeutigen Identitäten spricht er nicht ausdrücklich (Stand: September 2026).
ISO/IEC 27001:2022 behandelt das Thema in A.5.16 (Identitätsmanagement), A.5.18 (Zugangsrechte), A.8.2 (privilegierte Zugangsrechte) und A.8.15 (Protokollierung). Laut Erläuterungen von ISMS.online lassen die Hinweise in ISO/IEC 27002 zu 5.16 geteilte Identitäten ebenfalls nur als genehmigte, dokumentierte Ausnahme zu.
Damit hat die Lücke aus dem vorigen Abschnitt einen Preis. Beim Copilot cloud agent oder bei GitLabs composite identity zeigt das Log, welcher Agent für welchen Menschen gehandelt hat. Bei einer lokalen Sitzung unter dem Token des Entwicklers geben Konto und Token-Hash im Hoster-Log das nicht her. Welche weiteren Nachweise ein Finanzunternehmen unter DORA dann vorlegen kann, muss es gesondert klären.
Computergestützte GMP-Systeme kennen das Prinzip seit Langem. Annex 11 des EU-GMP-Leitfadens sieht in der Fassung vom Januar 2011 (Abschnitt 12.4) vor, dass solche Systeme festhalten, welcher Bediener Daten eingibt oder ändert und wann. Eine Pflicht, Commits so zuzuordnen, folgt daraus nicht. Die Logik lässt sich trotzdem übertragen.
Der Agent gehört ins Berechtigungskonzept, nicht in einen Sonderprozess
Die hier betrachteten DORA- und RTS-Stellen begründen keinen eigenen Agenten-Prozess neben dem Änderungsprozess, solange dieser die beteiligten Rollen abdeckt. Näher liegt es, den Agenten als Rolle in das bestehende Berechtigungskonzept aufzunehmen. Er bekommt eigene, begrenzte Rechte, und ein Mensch verantwortet seine Aktionen. Seine Änderungen durchlaufen dann dieselben Freigabeschritte wie alle anderen. So beschreibt es der Beitrag zu Coding Agents in der Versicherungs-IT unter DORA für den Änderungsprozess.
Ordnet ein Log jede Aktion eines Agenten der beauftragenden Person zu, unterliegt das nach § 87 Abs. 1 Nr. 6 BetrVG der Mitbestimmung des Betriebsrats. Das gilt aus demselben Grund schon für Commit- und SSO-Logs mit Nutzerkennung. Neu ist deshalb nur ein weiterer Auswertungszweck, nicht die Form der Überwachung. Welche Regelung dafür nötig ist, hängt davon ab, was die bestehende Betriebsvereinbarung schon abdeckt.
Wie eng sich diese Rolle heute zuschneiden lässt, hängt davon ab, wo der Agent läuft.
Was Teams jetzt umstellen, gestaffelt nach Umgebung
Das Zielmodell ist Delegation im Sinne von RFC 8693: Bei jeder Aktion sind der Agent und der Mensch angegeben, der ihn beauftragt hat. Wie weit sich dieses Ziel heute umsetzen lässt, hängt von der Umgebung ab. Alle Werkzeugangaben geben den Stand September 2026 wieder.
- Lokal: Unterscheidbarkeit. Jeder Agenteneinsatz bekommt ein eigenes Token statt des Entwickler-Tokens, bei GitHub ein Fine-grained PAT, bei GitLab ein Project Access Token. Least Privilege heißt hier: Zugriff nur auf die Repositories, die der Agent für diesen Einsatz braucht. GitHub-Organisationen erzwingen per PAT-Policy eine Höchstlaufzeit und schließen klassische PATs von ihren Ressourcen aus. Im GitHub-Audit-Log erscheint das eigene Token mit eigenem
hashed_token. - MCP-Server: Personenbezug. Remote-Server authentifizieren jeden Nutzer einzeln per OAuth, statische Tokens in geteilten Konfigurationsdateien entfallen. Beim GitHub MCP Server gehört die PAT-Variable deshalb nicht in die Konfiguration, sonst hat das dort hinterlegte Token Vorrang vor dem OAuth-Login. Auch bei den Credentials für stdio-Server werden die Berechtigungen eng begrenzt, wie beim lokalen Agenten-Token. Token Passthrough bleibt tabu.
- CI und Cloud: eigene Identität plus Mensch. Der Agent handelt als GitHub App, als Service Account oder als composite identity. Die beauftragende Person soll im Audit-Log und als Co-Autor im Commit genannt werden. Wer die Aufgabe vergeben hat, genehmigt den Pull Request nicht selbst, wie beim Copilot cloud agent.
Ein beaufsichtigter lokaler Agent braucht heute also kein eigenes Agentenkonto, wohl aber ein eigenes, eng begrenztes Token. Der Co-Autor-Trailer bleibt ein nützlicher, aber nicht authentifizierter Hinweis. Für sich allein belegt er keine Agentenidentität.
Lokal wird aus „Mensch oder Agent?“ damit die Frage „welches Token?“. Die Aktion ist unterscheidbar, aber nicht delegiert. Der Mensch ist dem Fine-grained PAT nur als dessen Besitzer zugeordnet.
Solange GitHub für Sitzungen in VS Code und der Copilot CLI keine Audit-Einträge mit Agent und beauftragendem Menschen dokumentiert, bleibt das Delegationsmodell dort vorerst eine Anforderung an die Anbieter.
