Agenten-Identität: Wie Mittelständler Authentifizierung und Zugriffsrechte für KI-Agenten regeln

Der erste KI-Agent in einem Mittelständler loggt sich meist mit demselben Service-Account ein, den 2017 jemand für einen nächtlichen DATEV-Export angelegt hat. Der zweite Agent loggt sich mit demselben ein. Beim dritten nutzt ihn die halbe IT. Sechs Monate später fragt ein externer Auditor, wer dienstags um 02:14 den Lieferanten-Stammdatensatz geändert hat - und niemand kann sagen, ob es ein Mensch, ein Agent oder beide gleichzeitig waren.

Das ist der Moment, in dem die meisten Mittelstands-Teams entdecken, dass sie keine Agenten-Identität haben. Sie haben Sammel-Accounts, ungesteuerte Secrets und einen Audit-Trail, der bei der ersten genauen Prüfung zusammenbricht. Laut GitGuardians 2026er Bericht sind allein 2025 28,6 Millionen neue Secrets in öffentlichen GitHub-Commits geleakt, KI-assistierter Code etwa doppelt so häufig wie der Schnitt¹. Branchenumfragen beziffern auf 88 Prozent der Unternehmen, die bereits einen KI-Agenten-Sicherheitsvorfall hatten⁴. Das Muster ist konsistent: Die Technologie ging schneller live als die Identitäts-Governance.

Dieser Leitfaden behandelt, was Agenten-Identität wirklich ist, die drei Authentifizierungs-Flows (Workload-zu-Workload, On-Behalf-of-User, Agent-zu-Agent), den 2026 etablierten Stack aus SPIFFE plus OAuth 2.1 plus MCP, die sieben Fehlermuster, die Mittelstands-Projekte entgleisen lassen, und einen 90-Tage-Plan vom Sammel-Service-Account zur erstklassigen Agenten-Identität. Geschrieben für IT-Verantwortliche, Plattform-Engineers und den Geschäftsführer, der unterschreibt, wenn etwas schiefgeht.

Warum Agenten-Identität jetzt zählt

Sechs konkrete Gründe, warum Agenten-Identität vom Zukunftsproblem zum 2026-Lieferobjekt geworden ist.

• Agenten sind bereits überall - Branchenberichte prognostizieren, dass bis Ende 2026 30 Prozent der Unternehmen auf KI-Agenten setzen werden, die unabhängig handeln, Transaktionen auslösen und Aufgaben für Menschen oder Systeme erledigen¹. Die Agenten sind deployt; was fehlt, ist die Identitäts-Governance.
• Das Non-Human-Identity-Verhältnis ist explodiert - Maschinen-Identitäten übersteigen menschliche 25- bis 50-fach in modernen Unternehmen, mit beschleunigtem Wachstum durch Agenten-Skalierung¹. Die Mittelstands-IT, die 200 Mitarbeitende verwaltete, verwaltet jetzt 5.000 bis 10.000 Non-Human-Identities.
• Secrets leaken im industriellen Maßstab - GitGuardian fand 28,6 Millionen neue Secrets in öffentlichen GitHub-Commits 2025, ein 34-Prozent-Anstieg zum Vorjahr und der größte in der Berichts-Historie. KI-assistierter Code leakt etwa doppelt so häufig wie der GitHub-Schnitt¹.
• 88 Prozent der Unternehmen hatten 2026 einen Vorfall - Branchenumfragen finden 82 Prozent der Führungskräfte zuversichtlich, dass ihre Policies unautorisierte Agent-Aktionen verhindern, während 88 Prozent der Organisationen bereits Vorfälle hatten, die diese Policies nicht verhindern konnten⁴. Die Zuversichts-Lücke ist die Lücke.
• Supply-Chain-Angriffe treffen jetzt Agent-Plattformen - Am 19. April 2026 hat Vercel offengelegt, über Context AI gebrochen worden zu sein, das selbst kompromittiert war⁶. Agent-Plattformen haben Drittanbieter-Abhängigkeiten, die zur Identitäts-Angriffsfläche werden.
• Least Privilege ist die größte verfügbare Risikoreduktion - Organisationen mit Least Privilege für KI-Agenten melden 17 Prozent Vorfallsrate, ohne 76 Prozent⁴. Keine andere Einzelmaßnahme kommt dem nahe.

Die Sammel-Account-Falle (und wie Mittelstands-Teams hineinfallen)

Das Muster, das 90 Prozent der Mittelstands-Identitätsvorfälle erzeugt, ist nicht böswillig - es ist Bequemlichkeit, die sich über Monate aufstaut. Fünf Schritte, die ein Mittelstands-IT-Team von sauber zu kompromittiert führen, jeder gut gemeint.

1. Schritt 1 - Der erste Agent geht live - Das Team braucht einen Agenten, der SAP liest. Sie nutzen den bestehenden nächtlichen Export-Service-Account, weil neue Accounts Compliance-Freigabe brauchen und sie diese Woche shippen wollen.
2. Schritt 2 - Der zweite Agent recycelt den Account - Ein anderes Team baut einen HR-Agenten und fragt die IT um SAP-Lese-Zugang. IT gibt denselben Service-Account, weil die Berechtigungen schon da sind.
3. Schritt 3 - Berechtigungen häufen sich - Jeder neue Agent braucht etwas anderen Zugriff. Der Service-Account erhält mehr Rechte, um alle zu bedienen. Im vierten Monat hat er mehr Privilegien als jeder Mensch in der Firma.
4. Schritt 4 - Der Audit-Trail kollabiert - Wenn etwas passiert, zeigt das Log den Service-Account-Namen. Niemand kann sagen, welcher Agent was tat. Forensik wird Raterei.
5. Schritt 5 - Der Kill Switch versagt - Ein Sicherheitsvorfall verlangt einen Agenten zu widerrufen. Den Service-Account zu widerrufen bricht jeden anderen Agenten. Das Team wählt, mit dem Vorfall zu leben, statt Produktion zu brechen.

Warum die Falle schwer aus Versehen zu vermeiden ist

• Service-Accounts fühlen sich richtig an - Sie funktionieren seit den 1990ern. Die meisten Mittelstands-IT-Teams haben kein mentales Modell für „Identität pro Agent", weil es nie nötig war.
• Compliance-Reibung ist real - Eine neue Identität anzulegen, läuft durch Freigabe, Namenskonvention, Eigentümer-Zuweisung, periodische Rezertifizierung. Eine bestehende wiederzuverwenden sind zwei Klicks.
• Tooling ist gespalten - Microsoft Entra, AWS IAM, SAP-Berechtigungen, DATEV-Rechte, eigene APIs - jedes hat sein eigenes Modell. Ohne Non-Human-Identity-Schicht heißt „eine Identität pro Agent" N-fache Identitätsarbeit pro Agent.
• Niemand besaß die Frage - Identität gehörte zur IT, Agenten zu einem Fachbereich, Sicherheit zu InfoSec. Agenten-Identität saß in der Naht und bekam nie einen Eigentümer.

Was Agenten-Identität wirklich ist

Streifen Sie die Anbieter-Sprache ab und Agenten-Identität hat eine einfache Definition. Sie ist die kryptographische und organisatorische Aufzeichnung, die einen KI-Agenten über alle Systeme hinweg eindeutig identifiziert, getrennt von jedem Menschen, getrennt von jedem anderen Agenten, mit fünf Pflichtattributen.

• Eindeutiger Identifikator - Ein kryptographisch verifizierbarer Name (SPIFFE-ID, X.509-Zertifikat, OIDC-Subject), den keine andere Identität im System teilt. Generische Namen wie „ai-agent-1" reichen nicht; die ID muss zu einer spezifischen Agent-Definition und -Version rückführbar sein.
• Benannter Eigentümer - Ein bestimmter Mensch (oder eine rotierende Rolle), verantwortlich für den Agenten. Wenn der Eigentümer das Unternehmen verlässt, wird der Agent geflagged - genauso, wie ein Austritt eine Account-Prüfung auslöst³.
• Gescopte Berechtigungen - Der Mindest-Zugriff für die Aufgabe, ausgedrückt als Ressourcen-Scopes, nicht als Rollen. Rollen häufen sich an; gescopte Berechtigungen sind atomar und einzeln widerrufbar.
• Begrenzte Lebensdauer - Tokens, die automatisch rotieren (Minuten bis Stunden, keine Monate), mit klarer Gesamtlebensdauer für den Agenten selbst. Kein Agent läuft ewig; er wird verlängert oder ausgemustert.
• Audit-Trail - Jede Aktion zurückzuführen auf diese spezifische Agenten-Identität, mit dem Menschen (falls vorhanden), in dessen Auftrag sie handelte, und dem Kontext, der das rechtfertigte. Aggregierte Logs „ai-agent-1 hat X getan" reichen nicht.

Die drei Authentifizierungs-Flows, die jeder Agenten-Stack braucht

Der 2026-Konsens, in MCP, A2A und den großen Non-Human-Identity-Plattformen reflektiert, teilt Agenten-Authentifizierung in drei Flows. Jeder löst ein anderes Problem mit einem anderen Muster. Sie zu vermischen ist der zweithäufigste Mittelstands-Fehler nach der Sammel-Account-Falle.

Flow 1: Workload-zu-Workload (der Agent beweist, dass er er selbst ist)

• Was es ist - Ein Service oder Agent identifiziert sich gegenüber einem anderen Service in Ihrer Infrastruktur. Kein Mensch im Loop. Der Empfänger will kryptographischen Beweis, dass der Aufrufer wirklich der ist, der er behauptet.
• Standard-Muster - SPIFFE-ID und SVID, ausgestellt von SPIRE. Jeder Agent erhält einen eindeutigen Identifikator und ein kurzlebiges X.509- oder JWT-Credential, automatisch rotiert¹⁵.
• Wo es passt - Agent ruft interne Microservices, Agent liest aus internen Datenbanken, Agent ruft andere Agenten in Ihrer VPC.
• Was es ersetzt - Langlebige API-Keys und Sammel-Service-Accounts. SPIFFE eliminiert beides.

Flow 2: On-Behalf-of-User (der Agent handelt als bestimmter Mensch)

• Was es ist - Der Agent handelt mit der Autorität eines bestimmten menschlichen Nutzers. Das empfangende System muss wissen, dass der Agent legitim ist UND wer der Mensch ist.
• Standard-Muster - OAuth 2.1 mit On-Behalf-of-Flow (RFC 8693 Token Exchange). Der Agent präsentiert eigene Identität plus delegiertes Nutzer-Token; der Resource-Server verifiziert beide.
• Wo es passt - Agent liest Kunden-E-Mail im Auftrag eines Account-Managers, Agent schreibt in CRM-Datensatz im Auftrag eines Vertrieblers, Agent verarbeitet HR-Datensatz im Auftrag einer HR-Business-Partnerin.
• Was es ersetzt - Agenten, die „einfach Zugriff" auf Nutzerdaten haben. On-Behalf-of bewahrt den Audit-Trail und stellt sicher, dass Aktionen dem richtigen Menschen zurechenbar sind.

Flow 3: Agent-zu-Agent und Agent-zu-MCP-Server

• Was es ist - Ein Agent ruft einen anderen Agenten (oft über Organisationsgrenzen) oder einen MCP-Server, um ein Tool zu nutzen. Der Standard erwähnt Cross-Trust-Boundary-Szenarien explizit.
• Standard-Muster - MCP-Authorization auf Basis von OAuth 2.1 mit PKCE und RFC 8707 Resource Indicators²⁰. Für reines Agent-zu-Agent ergänzen Google A2A und Anthropic-Agent-Kommunikation eigene Schichten.
• Wo es passt - Agent ruft MCP-Server für SAP, DATEV, SharePoint oder externe Tools. Agent in Multi-Agent-Workflow. Agent empfängt Anfragen vom Einkaufs-Agenten eines Kunden.
• Was es ersetzt - Vorgegebene API-Tokens, Anbieter-spezifische Authentifizierungsschemata, individuelle Pro-Tool-Verdrahtung.

SPIFFE, OAuth 2.1 und MCP: Der 2026-Stack

Die drei Standards haben sich in spezifische Schichten eingependelt, die gut zusammenkomponieren. Keiner ist neu; die Kombination ist das Neue.

SPIFFE und SPIRE für Workload-Identität

• Was es ist - SPIFFE (Secure Production Identity Framework for Everyone) ist der Standard, SPIRE die Referenz-Implementierung. Jede Workload erhält eine SPIFFE-ID wie spiffe://yourcompany.de/agents/customer-service/v3 und ein kurzlebiges kryptographisches Credential (SVID), das sie beweist¹⁵.
• Warum es für Agenten zählt - SPIFFE-IDs sind an Workloads gebunden, nicht an Personen, ideal für KI-Agenten und andere Non-Human-Entitäten. Jeder Agent erhält eine eindeutige kryptographische Identität, die Herkunft, Fähigkeiten und Vertrauensstufe beweist¹⁷.
• Mittelstands-Muster - SPIRE-Server (managed oder selbst gehostet) in Ihrer Umgebung betreiben, SPIFFE-IDs an jeden Agenten und jedes Tool ausgeben, mit Cloud und SaaS föderieren, wo unterstützt.

OAuth 2.1 mit PKCE und Resource Indicators

• Was es ist - OAuth 2.1 konsolidiert die OAuth-2.0-Best-Practices und entfernt die Legacy-Teile. PKCE (Proof Key for Code Exchange) ist Pflicht; Implicit Flow ist weg. RFC 8707 Resource Indicators binden ein Token an einen bestimmten Resource-Server und verhindern Wiederverwendung über Systeme²².
• Warum es für Agenten zählt - Wenn ein Agent ein Token für SAP hat, kann es nicht gegen DATEV abgespielt werden. Der Schadensradius eines kompromittierten Tokens ist begrenzt.
• Mittelstands-Muster - Jede externe API, jeder MCP-Server, jedes Tool, das der Agent ruft: OAuth 2.1 mit Resource Indicators, kurzlebige Tokens, automatisch erneuert.

MCP-Authorization für Tool-Zugriff

• Was es ist - Die Model-Context-Protocol-Authorization-Spezifikation, basierend auf OAuth 2.1, steuert, wie ein Agent einen MCP-Server für Tools ruft²⁰. Bis März 2026 hat MCP 97 Millionen monatliche SDK-Downloads überschritten und wird von jedem großen KI-Anbieter unterstützt.
• Warum es für Agenten zählt - MCP wird die Default-Schnittstelle zwischen Agent und Tool. Ist MCP-Auth richtig, wird der Rest des Tool-Sicherheitsmodells einfacher. Ist es falsch, wird die Tool-Oberfläche zur neuen Angriffsfläche.
• Mittelstands-Muster - Jeden MCP-Server als OAuth-Resource-Server behandeln. Resource Indicators für jedes Token. Nutzer-Identität durch den Agenten propagieren, sodass der Audit-Trail bei einem Menschen endet, nicht bei „dem Agenten".

Eine Referenz-Architektur für Mittelstands-Agent-IAM

Die Komponenten, die sich 2026 für produktive Agenten-Identität etabliert haben. Keine ist neu; der Wert liegt darin, die richtige Kombination für den Mittelstands-Kontext zu wählen und sinnvoll zu verdrahten.

1. Identitäts-Provider für Menschen - Microsoft Entra ID, Okta oder Keycloak. Bei den meisten Mittelständlern bereits da. Bleibt die Wahrheitsquelle für menschliche Identität und der Föderations-Anker für On-Behalf-of-Flows.
2. Workload-Identitätsschicht - SPIRE-Server (managed bei HashiCorp, Tetrate oder selbst gehostet), gibt SPIFFE-IDs und SVIDs an jeden Agenten und jedes Tool aus. Das kryptographische Substrat, auf dem alles andere aufbaut.
3. Non-Human-Identity-Plattform - Astrix, Entro, Oasis oder vergleichbar. Inventar, Eigentum, Lebenszyklus, Kill Switch. Die Glasscheibe, durch die ein Mensch tausende Agenten steuern kann.
4. Secrets-Manager - HashiCorp Vault, AWS Secrets Manager, Azure Key Vault oder 1Password Business. Nie Credentials in Prompts oder Code; zur Laufzeit über den Secrets-Manager injizieren.
5. OAuth-2.1-Authorization-Server - Auth0, Keycloak, Microsoft Entra oder selbst gehostet. Token-Ausgabe mit PKCE und Resource Indicators für jeden externen API-Aufruf.
6. MCP-Server-Register - Liste jedes MCP-Servers, den Ihre Agenten rufen dürfen, mit den OAuth-Scopes, die jeder verlangt. Quartalsweise mit Sicherheit reviewed.
7. Agent-Aktivitäts-Observability - Jede Aktion jeder Agenten-Identität in einem SIEM (Splunk, Elastic, Sentinel) mit SPIFFE-ID, On-Behalf-of-Nutzer, Ziel-Ressource und Ergebnis.
8. Kill-Switch-Service - Die einzige API, die eine Agenten-Identität auf suspendiert flippt, die Änderung in Sekunden an jedes nachgelagerte System propagiert und einen Audit-Eintrag produziert.

Least-Privilege-Autorisierung in der Praxis

Least Privilege ist die größte messbare Risikoreduktion in agentischer KI - 17 Prozent Vorfallsrate damit, 76 Prozent ohne⁴. Sechs konkrete Muster, die das Prinzip in ein Mittelstands-Operating-Model übersetzen.

• Ressourcen-Scope, nicht Rolle - Agenten Zugriff auf bestimmte Ressourcen geben (dieser Kunden-Datensatz, diese Kostenstelle, dieser Datumsbereich), nicht auf breite Rollen (Vertrieb, Finanzen, HR). Ressourcen-Scopes sind atomar; Rollen häufen sich an.
• Just-in-Time-Provisionierung - Der Agent erhält die Berechtigungen, die er braucht, in dem Moment, in dem er sie braucht, so lange er sie braucht. Token-TTLs in Minuten, nicht Wochen. Die Branchen-Empfehlung ist konsistent: kurzlebig, JIT, eng gescopt¹.
• Read-only per Default - Jeder neue Agent geht read-only live. Schreibrechte werden explizit erteilt, pro Ressourcentyp, mit klarem Rollback-Pfad. Die meisten Pilotprojekte brauchen nie Schreibrechte; die, die welche brauchen, sollen sie begründen.
• Pro-Umgebung-Tokens - Sandbox, Staging und Produktion haben jeweils ihren eigenen Token-Aussteller. Ein Token, das aus Sandbox entkommt, kann Produktion nicht berühren. RFC 8707 Resource Indicators machen das kryptographisch durchsetzbar.
• Verhaltens-Decken - Rate-Limits pro Agenten-Identität, pro Minute und pro Tag. Ein Agent, der plötzlich versucht, 10.000 Kunden-Datensätze zu lesen, wird blockiert, nicht freigegeben. Die Decke ist das Sicherheitsnetz unter Least Privilege.
• Quartals-Rezertifizierung - Jede Agenten-Identität jedes Quartal reviewed: noch nötig, noch korrekt gescopt, Eigentümer noch da. Was 30 Tage nicht genutzt wurde, wird suspendiert; was 90 Tage suspendiert ist, wird gelöscht.

Identitäts-Lebenszyklus und der Kill Switch

Eine Agenten-Identität hat sechs Lebenszyklus-Status. Für die unglücklichen Pfade zu designen zählt mehr als für den glücklichen - weil die unglücklichen Pfade die Momente sind, in denen Audit, Compliance und Sicherheit brechen.

1. Beantragt - Ein Team beantragt eine neue Agenten-Identität. Eigentümer benannt, Geltungsbereich entworfen, Business-Case angehängt. Compliance-Review hängt an.
2. Provisioniert - SPIFFE-ID ausgegeben, OAuth-Client registriert, Secrets erstellt, Scopes angehängt. Der Agent kann jetzt laufen.
3. Aktiv - Agent ist in Produktion. Tokens rotieren automatisch, Aktivität wird geloggt, Verhalten wird gegen Baseline überwacht.
4. Rezertifiziert - Quartalsweiser Review bestätigt, dass der Agent noch nötig, noch korrekt gescopt, noch Eigentümer hat. Was rezertifizierung nicht besteht, wandert auf suspendiert.
5. Suspendiert - Identität bleibt im System, aber jede Autorisierungsprüfung gibt in Sekunden „verweigert" zurück. Der Kill-Switch-Status. Reversibel.
6. Ausgemustert - Identität entfernt. Tokens widerrufen. Audit-Logs nach Aufbewahrungs-Policy bewahrt. SPIFFE-ID nie wiederverwendet.

Der Kill-Drill

Der Kill Switch zählt nur, wenn er funktioniert. Drei Praktiken, die Drills von Theater unterscheiden.

• Quartals-Feueralarm - Einen produktiven Agenten zufällig wählen, über die IAM-Plattform suspendieren, messen, wie lange bis jedes nachgelagerte System ihn verweigert. Ziel: unter 60 Sekunden. Wenn länger, vor dem echten Vorfall fixen.
• Eine Wahrheitsquelle - Eine Plattform besitzt den Suspendiert-Status. SAP, DATEV, MCP-Server, eigene APIs - alle abonnieren ihn. Kein System hat eine eigene unabhängige Allow-List, die einen Kill überleben könnte.
• Propagierung stresstesten - Die IAM-Plattform muss den Suspendiert-Status ohne Mensch im Loop propagieren. Wenn ein Mensch SAP-Basis anrufen muss, um einen Agenten zu widerrufen, haben Sie keinen Kill Switch; Sie haben ein Helpdesk-Ticket.

Die 7 Identitäts-Fallen, die Mittelstands-Projekte entgleisen lassen

Das Fehlermuster ist konsistent genug, um es zu nummerieren. Jede ist vermeidbar; fast alle treten in den ersten sechs Monaten des Agenten-Rollouts auf.

1. Agenten teilen einen Service-Account - Die Ursünde. Audit kollabiert, Kill Switch wird nukleare Option, Berechtigungen häufen sich. Fix: eine Identität pro Agent vom ersten Deployment. Die Reibung ist real, die Alternative ist schlimmer.
2. Langlebige Secrets in Code oder Prompts - API-Keys hartkodiert in Agent-Definitionen, Secrets in Prompts zum Debuggen, Credentials in Screenshots. GitGuardian fand 28,6 Millionen solcher Leaks 2025¹. Fix: Secrets-Manager + Scanning + Rotation bei Fund, nicht danach.
3. Kein Kill Switch oder einer, der nicht funktioniert - Die IAM-Plattform suspendiert den Agenten, aber SAP akzeptiert sein altes Token weiter, weil es nicht abgelaufen ist. Fix: kurzlebige Tokens (Minuten), Revocation-Propagierung, Quartals-Drill.
4. Identitäts-Propagierung vergessen - Agent ruft MCP-Server, MCP-Server loggt nur Agent-Identität, nicht den Nutzer, für den er handelte. Audit-Trail endet bei „dem Agenten". Fix: Nutzer-Identität end-to-end propagieren, überall loggen.
5. Berechtigungen erteilt, nie widerrufen - Jeder Agent häuft mit der Zeit Berechtigungen an. Niemand räumt auf. Nach einem Jahr hat der Agent mehr Zugriff als der CFO. Fix: Quartals-Rezertifizierung, automatischer Ablauf ungenutzter Berechtigungen.
6. Drittanbieter-Abhängigkeiten ungesteuert - Memory-Anbieter, Observability-Anbieter, Embedding-Anbieter - jeder hält eine Identität für Ihren Agenten. Der Vercel-Context-AI-Vorfall im April 2026 ist das kanonische Beispiel⁶. Fix: Identität pro Anbieter, getrennter Kill Switch pro Anbieter, Supply-Chain-Sorgfalt.
7. Kein Eigentümer - Der Agent wurde von einem inzwischen aufgelösten Team gebaut. Niemand weiß, welchen Geltungsbereich er braucht oder ob er noch existieren soll. Fix: Jede Agenten-Identität hat einen benannten Menschen oder eine rotierende Rolle; Agenten ohne Eigentümer werden automatisch suspendiert.

EU-KI-Verordnung, DSGVO und ISO 27001

Agenten-Identität sitzt am Schnittpunkt dreier deutscher Mittelstands-Compliance-Regime. Keines erwähnt „Agenten-Identität" explizit; alle erfordern sie implizit.

EU-KI-Verordnung

• Artikel 4 (KI-Kompetenz) - Angemessene KI-Kompetenz für alle Nutzer und Steuerer von KI-Tools²⁶. Inklusive das Plattform-Team, das die IAM betreibt, und das Sicherheits-Team, das den Kill-Drill fährt.
• Artikel 14 (menschliche Aufsicht) - Designte menschliche Aufsicht für Hochrisiko-Systeme²⁷. Agenten-Identität ist das technische Substrat, das Aufsicht überhaupt eingreifen lässt - ohne sie ist „den Agenten suspendieren" unmöglich.
• Mittelstands-Aktion - Jede Agenten-Identität auf einen bestimmten Aufsichts-Kontakt mappen. Der Kontakt ist der Mensch, den Artikel 14 nennt, wenn er fragt, wer diese KI beaufsichtigt.

DSGVO

• Auftragsverarbeitung (Artikel 28) - Jeder externe Identitäts-Provider, MCP-Server-Anbieter und Observability-Anbieter braucht einen unterzeichneten AVV. Liste kurz halten; jährlich reviewen.
• Recht auf Auskunft und Löschung (Artikel 15 und 17) - Identitäts-Propagierung durch den Agenten-Stack ist, was „jede Aktion einem bestimmten Nutzer zurechenbar" technisch möglich macht. Ohne sie wird das Erfüllen von Auskunfts- und Löschanträgen Raterei.
• Mittelstands-Aktion - Identitäts-Propagierung als harte Architekturanforderung. Der Audit-Trail muss bei einem Menschen enden, nicht bei „dem Agenten".

ISO 27001 und BSI C5

• A.9 Zugriffskontrolle - ISO 27001:2022 Controls 5.15 bis 5.18 decken Identitätsmanagement, Zugriffsrechte und Privileged-Access-Management ab. Non-Human-Identities sitzen klar im Geltungsbereich²⁹.
• BSI C5 - Der deutsche Cloud-Computing-Compliance-Katalog verlangt Authentifizierungs- und Autorisierungs-Controls, die für Non-Human-Identities gleichermaßen gelten²⁸.
• Mittelstands-Aktion - Agenten-Identität in die ISO-27001-Statement-of-Applicability aufnehmen. Den Kill-Drill als Control-Test dokumentieren.

Betriebsrat

• Warum es zählt - On-Behalf-of-Flows bedeuten, dass ein Agent mit der Autorität eines bestimmten Mitarbeitenden handelt. Der Betriebsrat hat ein berechtigtes Interesse an der Policy, die das steuert.
• Mittelstands-Aktion - Ein-Seiten-Policy, die beschreibt, was Agenten im Auftrag welcher Mitarbeitenden tun dürfen, einmal abgezeichnet, auf jeden Agenten angewendet.

Ein 90-Tage-Implementierungsplan

Die Arbeit teilt sich in drei 30-Tage-Sprints. Bis Tag 90 hat ein Mittelstands-Team jeden produktiven Agenten auf einer eindeutigen Identität, mit funktionierendem Kill Switch und dokumentierter Audit-Story.

Tage 0-30: Inventar und die erste Identität

• Jeden Agenten und Sammel-Account inventarisieren - Liste jedes KI-Agenten, MCP-Servers und Sammel-Service-Accounts derzeit im Einsatz. Die meisten Teams finden 3- bis 10-mal mehr als erwartet.
• IAM-Plattform wählen - Astrix, Entro, Oasis oder selbst gehostetes SPIRE plus Secrets-Manager. Entscheidung in Woche eins, Integration in Wochen zwei und drei.
• Secrets-Manager aufsetzen - HashiCorp Vault, falls nicht schon vorhanden. Erste 5 Secrets aus Code und Prompts heraus migrieren.
• Erste Agenten-Identität ausstellen - Ein Pilot-Agent bekommt eigene SPIFFE-ID, gescopte Berechtigungen, benannten Eigentümer, kurzlebiges Token. Prozess dokumentieren.
• Policy setzen - Ein-Seiten-Dokument zu Namensgebung, Eigentum, Geltungsbereich, Lebensdauer, Kill Switch. Von Compliance und Betriebsrat reviewt.

Tage 31-60: Migrieren, propagieren, drillen

• Jeden bestehenden Agenten migrieren - Eine Identität pro Agent. Sammel-Service-Accounts ausmustern, sobald Agenten umgezogen sind.
• Identitäts-Propagierung verdrahten - Durch jeden MCP-Server, jede interne API, jedes externe Tool. Der Audit-Trail muss bei einem Nutzer enden, nicht beim Agenten.
• Ersten Kill-Drill fahren - Einen unkritischen Agenten suspendieren, Propagierung messen. Was länger als 60 Sekunden braucht, fixen.
• Audit-Log zentralisieren - Jede Agenten-Aktion in einem SIEM mit SPIFFE-ID, On-Behalf-of-Nutzer, Ressource, Ergebnis.
• Plattform-Team schulen - Artikel-4-Modul zu NHI, OAuth 2.1, SPIFFE, MCP-Authorization und dem Kill-Drill selbst.

Tage 61-90: Härten, rezertifizieren, zweite Welle

• Drittanbieter stresstesten - Für jeden Memory-, Observability- und Embedding-Anbieter: getrennte Identität, getrennter Kill Switch, Supply-Chain-Sorgfalt.
• Least Privilege überall durchsetzen - Jede Agenten-Identität auf zu breite Scopes auditieren. Reduzieren, bis jede nur tut, was sie braucht.
• Quartals-Rezertifizierungs-Prozess - Dokumentiert, Eigentümer zugewiesen, automatischer Ablauf ungenutzter Berechtigungen.
• Nächste 5 Agenten anschließen - Jetzt per Default auf den Identitäts-Schienen. Neue Agenten erben das Framework, statt eigenes zu erfinden.
• Audit-Story dokumentieren - Ein-Seiten-Diagramm zu Identitätsfluss, Kill Switch, Rezertifizierung, Supply Chain. Das Artefakt für den Auditor.

Wie Superkind in Agenten-Identität passt

Superkind baut maßgeschneiderte KI-Agenten für den Mittelstand mit Identität als erstklassigem Architektur-Bestandteil statt nachträglich. Wir besitzen typischerweise den SPIFFE-Rollout, die OAuth- und MCP-Verdrahtung, den Kill-Switch-Drill und die Audit-Story für die Agenten, die wir ausliefern.

• Eine Identität pro Agent vom ersten Tag - SPIFFE-ID, benannter Eigentümer, gescopte Berechtigungen, kurzlebige Tokens. Keine Sammel-Service-Accounts, keine Ausnahmen.
• OAuth-2.1- plus MCP-Authorization-Verdrahtung - Jeder externe Tool-Call ressourcen-gebunden, jede Nutzer-Aktion propagiert, jedes Token kurzlebig.
• Secrets-Manager-Integration - HashiCorp Vault oder der Manager, den Sie schon nutzen. Credentials erscheinen nie in Prompts, Code oder Screenshots.
• Kill-Switch-Design und -Drill - Eine API, Propagierung unter 60 Sekunden, quartalsweiser Drill als Service, den wir das erste Jahr mit Ihrem Team fahren.
• Identitäts-Propagierung durch den Agenten-Stack - SAP, DATEV, SharePoint, eigene APIs - der Audit-Trail endet bei einem Menschen, nicht beim Agenten.
• Drittanbieter-Governance - Getrennte Identität pro Memory-, Observability- und Embedding-Anbieter. Supply-Chain-Sorgfalt als dauerhafte Praxis, nicht einmalige Prüfung.
• EU-KI-VO- und DSGVO-Abstimmung - Artikel-4-Kompetenz, Artikel-14-Aufsicht, Artikel-28-AVV-Papier als Teil des Engagements.
• ISO 27001- und BSI-C5-Mapping - Identitäts-Controls auf Ihren bestehenden Zertifizierungs-Geltungsbereich gemappt.

Entscheidungs-Framework: Ist unsere Agenten-Identität bereit?

Eine Sechs-Dimensionen-Prüfung, die einer Mittelstands-IT-Führung und einem Geschäftsführer hilft, die Bereitschafts-Frage in einer Steering-Sitzung zu beantworten.

Die meisten Mittelständler 2026 landen in der „nicht bereit"-Spalte auf drei oder mehr Dimensionen. Die richtige Antwort ist nicht zu warten. Die richtige Antwort ist, die Nicht-bereit-Spalten als die ersten 90 Tage des Agent-IAM zu fixen, nicht als Voraussetzungen, um überhaupt einen Agenten zu deployen.

Häufig gestellte Fragen

Verwandte Artikel

• KI-Agenten-Sicherheit: Prompt Injection, Datenabfluss und die OWASP LLM Top 10
• Persistenter Kontext für KI-Agenten: Was Mittelstands-IT-Teams 2026 über Memory-Design wissen müssen
• Software 3.0 im Mittelstand: Warum Programmieren jetzt Prompten heißt
• Human-in-the-Loop: Vertrauen in KI-Agenten aufbauen
• Souveräne KI für den Mittelstand: Warum EU-Datenresidenz zum Wettbewerbsvorteil wird
• EU-KI-Verordnung 2026: Was der Mittelstand vor August wissen muss
• Schatten-KI im Mittelstand: Der Governance-Leitfaden
• SAP und KI-Agenten: Der pragmatische Weg durch S/4HANA, ECC und Business One

Henri Jung

Co-Founder von Superkind. Henri hilft Mittelständlern und Konzernen, maßgeschneiderte KI-Agenten zu deployen, die wirklich zur Arbeitsweise ihrer Teams passen. Er brennt dafür, die Lücke zwischen dem, was KI kann, und dem Wert, den sie in echten Unternehmen schafft, zu schließen. Er glaubt, der Mittelstand hat alles, was er braucht, um in KI zu führen - er braucht nur den richtigen Ansatz.