KI-Agenten unter menschlichen Namen: Identitaet wird zur ersten Verantwortungsluecke
Wenn KI-Agenten mit ausgeliehenen Zugangsdaten von menschlichen Nutzern arbeiten, verschwimmt die Verantwortung. Audit-Logs zeigen dann den falschen Verursacher, und klar zuzuordnende Agenten-Identitaeten fehlen bislang weitgehend.
Ihr KI-Agent hat die Berechtigung zu handeln. Wer hat die Berechtigung, Verantwortung zu uebernehmen?
Stellen Sie sich das Audit-Protokoll nach einem Zwischenfall vor. Ein Datensatz wurde geaendert, eine Berechtigung erweitert, ein Workflow ausgefuehrt. Das Protokoll nennt alice. Alice war in einer Besprechung und hat das System nie beruehrt. Ein Agent, der mit von ihr geliehenen Zugangsdaten lief, hat es getan. Das ist die erste Verantwortungsluecke: Ihre Aufzeichnungen muessen sagen, wer oder was gehandelt hat.
Wenn ein Agent unter den Zugangsdaten eines Menschen laeuft, nennt die Aufzeichnung nur den Menschen. Rig Securitys CEO Guy Kozliner brachte es so auf den Punkt: "Heute sind die aktivsten Identitaeten in einem Unternehmen KI-Agenten, und sie handeln unter menschlichen Namen." (Biometric Update)
Rig Securitys These ist, dass Sicherheitsteams nicht erkennen koennen, ob eine Person oder ein Agent eine Aktion ausgefuehrt hat, und dass sie den Agenten nicht stoppen koennen, ohne die Person zu blockieren. Diese beiden Probleme sind echte technische Probleme, ganz gleich was Sie von der Verkaufsrede halten: Sowohl die Zuschreibbarkeit als auch der Widerruf brechen, wenn sich Agent und Mensch eine Identitaet teilen.
So sieht das in einem Protokoll aus. Zunaechst der Eintrag, den die meisten Systeme heute schreiben:
{ "time": "2026-10-20T09:14:02Z", "user": "alice", "action": "update", "resource": "customers/4412" } Enter fullscreen mode Exit fullscreen mode Nichts daran sagt aus, dass ein Agent beteiligt war. Nun dasselbe Ereignis mit dem Agenten als eigenstaetigem Akteur und Alice als delegierendem Menschen (eine illustrative Skizze, kein Standard):
{ "time": "2026-10-20T09:14:02Z", "agent": "support-triage-agent", "delegated_by": "alice", "action": "update", "resource": "customers/4412" } Enter fullscreen mode Exit fullscreen mode Dieselbe Aktion, aber jetzt koennen Sie die Fragen "War es Alice?" und "Welcher Agent?" getrennt beantworten und einen von beiden deaktivieren, ohne den anderen zu beruehren.
In JumpClouds Q4 2026 Pulse Report, ueber den BankInfoSecurity am 2026-10-09 berichtete, haben 59 Prozent der befragten Organisationen, die Agenten nutzen, ihre IAM-Richtlinien fuer Menschen noch nicht vollstaendig auf nicht-menschliche Nutzer ausgedehnt. Dieselbe Umfrage ergab, dass 55 Prozent der Organisationen Agenten einsetzen oder testen, die Systeme, Berechtigungen, Datensaetze oder Workflows veraendern koennen. (BankInfoSecurity)
Delineas 2026 AI Policy Enforcement Report deutet in dieselbe Richtung: 99,7 Prozent der Organisationen haben eine formale Richtlinie fuer den KI-Datenzugriff, aber nur etwa die Haelfte prueft Zugriffe in Echtzeit gegen diese Richtlinie. Der Bericht fand auch heraus, dass 55 Prozent einen Tag oder laenger brauchen, um zu erkennen, dass ein Agent seinen Rahmen ueberschritten hat, und dass 87 Prozent der IT-Fuehrungskraefte angeben, dass ein KI-Tool oder Agent im vergangenen Jahr auf sensible Daten ausserhalb seines vorgesehenen Rahmens zugegriffen hat.
Eine Einschraenkung: Dies sind Zahlen aus zweiter Hand, und ich habe die zugrunde liegenden Berichte nicht gesehen. Der BankInfoSecurity-Artikel nennt weder Stichprobengroesse, Geografie noch Erhebungszeitraum der JumpCloud-Umfrage, und JumpCloud ist ein Anbieter von Verzeichnis- und IT-Management-Software. Behandeln Sie die Zahlen als Richtung, nicht als Messung: Richtlinien existieren auf dem Papier, waehrend Durchsetzung und Erkennung langsamer sind als die Agenten.
Dieselbe JumpCloud-Umfrage fragte, wie Organisationen mit risikoreichen Agentenaktionen umgehen. 46 Prozent der Organisationen mit Agentennutzung lassen sie automatisch laufen und pruefen die Protokolle erst danach. 29 Prozent erlauben sie mit begrenzter oder ohne Pruefung. 18 Prozent verlangen eine vorherige menschliche Freigabe.
Die Pruefung im Nachhinein ist ein legitimes Design. Aber sie funktioniert nur, wenn das Protokoll Aktionen zuordnen kann. Wenn der Eintrag fuer alles alice lautet, wird bei der nachtraeglichen Pruefung das Falsche geprueft.
Die NIST-Forscher Bill Fisher und Ryan Galluzzo sagen, wie von BankInfoSecurity berichtet, Agenten sollten als eigenstaetige Entitaeten mit eindeutigen Kennungen, Zugangsdaten und Berechtigungen behandelt werden, die an den sie betreibenden Nutzer oder das betreibende System geknuepft sind.
Sie warnten ausserdem vor geteilten menschlichen Zugangsdaten, statischen API-Schluesseln und langlebigen Bearer-Tokens und verwiesen auf OAuth 2.0 und SPIFFE fuer kurzlebige, eng begrenzte Zugangsdaten.
In der Praxis bedeutet "eine eigene Identitaet", dass sich der Agent als er selbst authentifiziert und die Zugangsdaten, die er haelt, eng begrenzt und schnell ablaufend sind. Unten ist eine Skizze einer Token-Anfrage fuer solche Zugangsdaten. Es ist kein funktionierender Ablauf: actor_sub ist ein Name, den ich erfunden habe, verwenden Sie also das Claim, das Ihr Identity Provider fuer Delegation unterstuetzt.
# sketch only: the issued token should expire within minutes, not days POST /oauth/token Content-Type: application/x-www-form-urlencoded grant_type=client_credentials &client_id=support-triage-agent &scope=customers.read customers.update &actor_sub=alice Enter fullscreen mode Exit fullscreen mode Entscheidend ist die Form: Der Agent ist der Client, der Scope ist auf das beschraenkt, was dieser Job benoetigt, die Lebensdauer ist kurz, und der delegierende Mensch wird im Token mitgefuehrt, damit er bis ins Audit-Protokoll gelangt.
Ein Hinweis zu den Quellen: Ich konnte das NIST-Material fuer die beiden obigen NIST-Punkte nicht direkt lesen, daher stuetzen sie sich auf die Berichterstattung von BankInfoSecurity. Pruefen Sie die Originalquelle, bevor Sie darauf eine Richtlinie aufbauen.
Der Forrester-Analyst Andras Cser sagte, Agenten sollten innerhalb bestehender IAM-Frameworks verwaltet werden, und dass Entscheidungen den menschlichen Nutzer, den Agenten und die bearbeitete Ressource bewerten sollten. Das ist eine nuetzliche Einschraenkung: Sie brauchen kein paralleles Identitaetssystem, Sie muessen das vorhandene erweitern, damit es einen Agenten neben dem Menschen darstellen kann.
Zu den Protokollierungsdaten nannte Cser Agent und Runtime; die Liste im BankInfoSecurity-Artikel geht weiter: der delegierende Mensch, Zeitstempel, Aktionen, Zugangsdaten, Ressourcenkennungen und Gruendecodes.
Dieser Eintrag erweitert die fruehere Skizze um den Rest dieser Liste (die Feldnamen stammen von mir, zur Illustration):
{ "timestamp": "2026-10-20T09:14:02Z", "agent": "support-triage-agent", "runtime": "worker-pool-3", "delegating_human": "alice", "action": "update", "credential": "token:7f3a (expires 2026-10-20T09:29:02Z)", "resource": "customers/4412", "reason_code": "TICKET_ESCALATION" } Enter fullscreen mode Exit fullscreen mode Jedes Feld beantwortet eine Frage, die nach einem Zwischenfall jemand stellen wird: welcher Agent, laufend wo, fuer wen, was tuend, mit welcher Zugangsdaten, an welcher Ressource, und warum.
NISTs NCCoE veroeffentlichte am 2026-02-05 ein Konzeptpapier zur Identitaet und Autorisierung von Software- und KI-Agenten. Oeffentliche Kommentare waren bis zum 2026-04-02 eingereicht, die Kommentarfrist ist nun geschlossen. (NIST) Das Papier listet Identifikation, Autorisierung sowie Pruefung und Nichtabstreitbarkeit von KI-Agenten unter seinen Themen fuer Rueckmeldungen auf.
Ueberinterpretieren Sie es nicht. Das NCCoE sagte, es sei daran interessiert, ein Projekt zu starten, das demonstriert, wie Identitaetsstandards und bewaehrte Verfahren auf Software-Agenten angewendet werden koennen. Das ist ein Vorschlag fuer ein Demonstrationsprojekt, kein fertiger Standard, Sie koennen sich also noch nicht darauf als Compliance-Anforderung berufen.
Auch der Markt bewegt sich. Rig Security trat aus der Tarnung mit 12 Millionen Dollar Seed-Finanzierung hervor, berichtet am 2026-09-30, und RSA startete RSA Agent ID, eine plattform fuer agentische Sicherheitsidentitaeten, die auf regulierte Sektoren wie Behoerden, Finanzdienstleistungen und kritische Infrastruktur abzielt. Beides stammt aus der Berichterstattung eines einzigen Mediums, lesen Sie es also als Aufmerksamkeit der Anbieter, nicht als Beweis fuer Reife.
Streiten Sie ueber Verantwortung, nachdem Sie die Zuschreibbarkeit behoben haben, nicht vorher. Eine kurze Checkliste:
Csers Satz ist der, den man im Kopf behalten sollte: "Am Ende der Geschichte muss jemand stehen."
Also eine Frage: Wenn Ihr Agent heute etwas in der Produktion veraendert, kann Ihr Protokoll sagen, welcher Agent es getan hat und fuer wen?
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Your AI agent has permission to act. Who has permission to take responsibility?
Picture the audit log after an incident. A record was changed, a permission was widened, a workflow ran. The log says alice. Alice was in a meeting and never touched the system. An agent, running on credentials it borrowed from her, did it. That is the first accountability gap: your records must say who, or what, acted.
When an agent runs under a human's credentials, the record names only the human. Rig Security's CEO Guy Kozliner put it this way: "Today, the most active identities in an enterprise are AI agents, and they are acting under human names." ( Biometric Update )
Rig Security's claim is that security teams cannot tell whether a person or an agent performed an action, and cannot stop the agent without blocking the person. Those two problems are real engineering problems whatever you think of the sales pitch: attribution and revocation both break when the agent and the human share one identity.
Here is what that looks like in a log. First, the record most systems write today:
{ "time": "2026-10-20T09:14:02Z", "user": "alice", "action": "update", "resource": "customers/4412" } Enter fullscreen mode Exit fullscreen mode Nothing in it says an agent was involved. Now the same event with the agent as its own actor and Alice as the delegating human (an illustrative sketch, not a standard):
{ "time": "2026-10-20T09:14:02Z", "agent": "support-triage-agent", "delegated_by": "alice", "action": "update", "resource": "customers/4412" } Enter fullscreen mode Exit fullscreen mode Same action, but now you can answer "was it Alice?" and "which agent?" separately, and you can disable one without touching the other.
In JumpCloud's Q4 2026 Pulse Report, as reported by BankInfoSecurity on 2026-10-09, 59% of agent-using respondents have not fully extended their human IAM policies to non-human users. The same survey found that 55% of organizations use or test agents that can change systems, permissions, records or workflows. ( BankInfoSecurity )
Delinea's 2026 AI Policy Enforcement Report points the same way: 99.7% of organizations have a formal policy governing AI data access, but only about half check access against that policy in real time. It also found that 55% take a day or longer to detect an agent exceeding its scope, and 87% of IT leaders say an AI tool or agent accessed sensitive data beyond its intended scope in the past year.
A caveat: these are secondhand figures, and I have not seen the underlying reports. The BankInfoSecurity article does not state the JumpCloud survey's sample size, geography or fieldwork dates, and JumpCloud is a vendor of directory and IT management software. Treat the numbers as direction, not measurement: policies exist on paper, while enforcement and detection are slower than the agents.
The same JumpCloud survey asked how organizations handle high-risk agent actions. 46% of agent-using organizations let them run automatically and review logs afterward. 29% allow them with limited or no review. 18% require prior human approval.
Reviewing afterward is a legitimate design. But it only works if the log can attribute actions. If the record says alice for everything, the after-the-fact review is reviewing the wrong thing.
NIST researchers Bill Fisher and Ryan Galluzzo, as reported by BankInfoSecurity, say agents should be treated as first-class entities with unique identifiers, credentials and entitlements tied to the user or system operating them.
They also warned against shared human credentials, static API keys and long-lived bearer tokens, and pointed to OAuth 2.0 and SPIFFE for short-lived, tightly scoped credentials.
In practice, "its own identity" means the agent authenticates as itself and the credential it holds is narrow and expires quickly. Below is a sketch of a token request for such a credential. It is not a working flow: actor_sub is a name I made up, so use whatever claim your identity provider supports for delegation.
# sketch only: the issued token should expire within minutes, not days POST /oauth/token Content-Type: application/x-www-form-urlencoded grant_type=client_credentials &client_id=support-triage-agent &scope=customers.read customers.update &actor_sub=alice Enter fullscreen mode Exit fullscreen mode What matters is the shape: the agent is the client, the scope is limited to what this job needs, the lifetime is short, and the delegating human is carried in the token so it can reach the audit log.
A note on sourcing: I could not read the NIST material directly for the two NIST points above, so they rest on BankInfoSecurity's reporting. Check the original before you build policy on them.
Forrester analyst Andras Cser said agents should be managed within existing IAM frameworks, and that decisions should assess the human user, the agent and the resource acted on. That is a useful constraint: you do not need a parallel identity system, you need to extend the one you have so it can represent an agent next to the human.
On what to log, Cser named agent and runtime; the BankInfoSecurity article's list goes further: the delegating human, timestamps, actions, credentials, resource identifiers and reason codes.
This record extends the earlier sketch with the rest of that list (field names are mine, for illustration):
{ "timestamp": "2026-10-20T09:14:02Z", "agent": "support-triage-agent", "runtime": "worker-pool-3", "delegating_human": "alice", "action": "update", "credential": "token:7f3a (expires 2026-10-20T09:29:02Z)", "resource": "customers/4412", "reason_code": "TICKET_ESCALATION" } Enter fullscreen mode Exit fullscreen mode Each field answers a question someone will ask after an incident: which agent, running where, for whom, doing what, with which credential, to which resource, and why.
NIST's NCCoE published a concept paper on software and AI agent identity and authorization on 2026-02-05. Public comments were due 2026-04-02 and the comment period is now closed. ( NIST ) The paper lists identification, authorization, and auditing and non-repudiation of AI agents among its topics for feedback.
Don't over-read it. The NCCoE said it is interested in launching a project to demonstrate how identity standards and best practices can be applied to software agents. That is a proposal for a demonstration project, not a finished standard, so you cannot point to it as a compliance requirement yet.
The market is moving too. Rig Security emerged from stealth with $12 million in seed funding, reported on 2026-09-30, and RSA launched RSA Agent ID, an agentic security identity platform aimed at regulated sectors such as government, financial services and critical infrastructure. Both come from a single outlet's reporting, so read them as vendor attention, not proof of maturity.
Argue about responsibility after you have fixed attribution, not before. A short checklist:
Cser's line is the one to keep in mind: "There needs to be somebody at the end of the story."
So, one question: when your agent changes something in production today, can your log say which agent did it and for whom?