Leitfaden zur Sicherung von KI-Agenten: Identity & Access Management, Secrets Management, Autorisierung. Best Practices 2026.
Die ersten KI-Assistenten, die in Unternehmen eingesetzt wurden, hatten eine relativ passive Rolle. Sie beantworteten Fragen, fassten Dokumente zusammen oder generierten Inhalte. Ihre Auswirkungen beschränkten sich auf die Erstellung von Informationen.
Agentenbasierte Architekturen ändern diese Logik grundlegend.
Heute kann ein Agent ein Jira-Ticket öffnen, einen CRM aktualisieren, einen CI/CD-Workflow starten, eine E-Mail versenden, eine Stripe-Rückerstattung auslösen oder mehrere API-Aufrufe autonom hintereinander ausführen.
Ab dem Moment, in dem ein Agent auf echte Systeme einwirkt, wird eine Frage unvermeidlich:
Wer handelt tatsächlich?
Das ist keine Frage des Modellanbieters, des Frameworks oder des Protokolls. Das ist eine architektonische Frage.
Eine neue kategorie von identität
Jahrelang basierten Sicherheitsarchitekturen auf zwei Kategorien von Identitäten:
- menschliche Benutzer;
- technische Identitäten (Anwendungen, Services, Microservices).
KI-Agenten gehören vollständig zu keiner dieser Kategorien.
Sie denken, wählen Werkzeuge, passen ihre Aktionen an den Kontext an und führen manchmal mehrere Dutzend Operationen hintereinander aus.
Sie bilden eine neue Kategorie von Identität, die wir in diesem Artikel als agentenbasierte Identität bezeichnen werden.
Definition
Eine agentenbasierte Identität ist der Satz von Informationen, der es ermöglicht, einen Agenten zu identifizieren, festzustellen, in wessen Namen er handelt, die Grenzen seiner Autonomie zu kennen und jede seiner Entscheidungen nachzuverfolgen.
Diese Definition wird sich durch den REST des Artikels ziehen.
Ein API-schlüssel ist keine identität
Die ersten Agenten-Implementierungen folgen oft dieser Architektur.
Anwendung
│
▼
LLM API-Schlüssel
│
▼
KI-Agent
Diese Darstellung ist praktisch.
Sie ist auch irreführend.
Der API-Schlüssel identifiziert Ihre Anwendung gegenüber dem Modellanbietern.
Er identifiziert nicht den Agenten, der in Ihrem Informationssystem handelt.
Zwei Agenten können denselben API-Schlüssel teilen und völlig unterschiedliche Verantwortungen haben.
Die Identität des Agenten gehört daher zu Ihrer Architektur, nicht zum Modellanbietern.
Das modell führt nie direkt eine aktion aus
Man hört oft:
„Claude hat eine Bestellung gelöscht."
oder
„GPT hat eine Rückerstattung erstellt."
In Wirklichkeit macht ein Sprachmodell nur einen Vorschlag.
Ihre Infrastruktur entscheidet dann:
- ob diese Aktion zulässig ist;
- mit welchen Berechtigungen;
- für welchen Benutzer;
- auf welche Ressourcen.
Benutzer
│
▼
Anwendung
│
▼
Agent Runtime
│
schlägt eine Aktion vor
▼
Policy Engine
│
▼
Geschäftswerkzeug
│
▼
Zielsystem
Diese Trennung zwischen Argumentation und Ausführung ist eines der Grundprinzipien moderner agentenbasierter Architekturen.
Die echte frage ist die verantwortung
Ein Unternehmen muss mehrere Wochen nach einem Vorfall antworten können:
- Welcher Agent hat handelt?
- Für welchen Benutzer?
- In welchem Tenant?
- Welche Richtlinie hat diese Operation autorisiert?
- Welches Werkzeug wurde aufgerufen?
Ein Protokoll, das nur angibt:
„Das Modell hat updateCustomer() aufgerufen"
bietet praktisch keinen Wert.
Eine moderne Architektur muss es ermöglichen, die gesamte Entscheidungskette nachzuverfolgen.
Eine identität ist immer kontextabhängig
Derselbe Agent kann eingreifen:
- für mehrere Benutzer;
- in mehreren Organisationen;
- in mehreren Umgebungen;
- mit unterschiedlichen Berechtigungen je nach Aufgabe.
Seine Identität lässt sich daher nie auf einen einfachen Identifikator reduzieren.
Agent
├ Identität
├ Vertretener Benutzer
├ Tenant
├ Umgebung
├ Sitzung
└ Temporäre Berechtigungen
Der Kontext ist ein integraler Bestandteil der Identität.
Historische architekturen können diese problematik nicht lösen
OAuth, OpenID Connect, Kubernetes Service Accounts oder Workload-Identitäten beantworten hauptsächlich eine Frage:
Welche Komponente fordert Zugriff auf eine Ressource an?
KI-Agenten fügen eine zusätzliche Dimension hinzu:
Warum wird diese Aktion ausgeführt, in wessen Namen und innerhalb welcher Grenzen?
Diese Unterscheidung rechtfertigt eine neue Governance-Schicht.
Bevor von JWT oder rbac die rede ist
Die meisten Artikel beginnen sofort mit den Technologien:
- JWT;
- OAuth;
- RBAC;
- Vault;
- Secrets-Rotation.
Alle sind wichtig.
Aber sie kommen zu früh.
Bevor Sie eine Technologie wählen, müssen Sie definieren, was die Identität eines Agenten ist und welche Informationen sie enthalten soll.
Das ist genau der Zweck des nächsten Kapitels, das ein Agent Identity Reference Model vorstellt, das unabhängig von Anbietern, Frameworks und Sprachmodellen ist.
Zum Mitnehmen
Die Modelle werden sich entwickeln.
Die Frameworks werden sich ändern.
Die Protokolle werden erscheinen und dann verschwinden.
Jede agentenbasierte Architektur muss jedoch immer die gleiche Frage beantworten können:
Wer handelt tatsächlich, in wessen Namen, mit welchen Berechtigungen und unter welcher Kontrolle?
Definition
Ein Agent Identity Reference Model ist ein konzeptionelles Modell, das die minimalen Informationen beschreibt, die eine Plattform kennen muss, um einen Agenten zu identifizieren, festzustellen, in wessen Namen er handelt, zu entscheiden, welche Aktionen er ausführen kann, und die vollständige Rückverfolgbarkeit seiner Aktivität sicherzustellen.
Sobald man einen Agenten als echte Softwareidentität betrachtet, stellt sich sofort eine neue Frage:
Welche Informationen braucht eine Plattform wirklich, um einen Agenten handeln zu lassen?
Die meisten Implementierungen antworten mit einer Liste technischer Mechanismen: ein JWT, ein API-Schlüssel, einige Berechtigungen und manchmal eine RBAC-Rolle.
In Wirklichkeit drücken diese Mechanismen nur einen Teil der Identität aus. Damit ein Agent sicher handeln kann, müssen mehrere unabhängige Fragen beantwortet werden.
Überblick
| Schicht | Frage | Beispiele für Technologien |
|---|---|---|
| Identity | Wer ist dieser Agent? | UUID, SPIFFE ID |
| Authentication | Kann er seine Identität beweisen? | JWT, OAuth 2.0, mTLS |
| Delegation | In wessen Namen handelt er? | OAuth, OIDC |
| Authorization | Was kann er tun? | RBAC, ABAC, Cedar, OPA |
| Secrets | Wie greift er auf Ressourcen zu? | Vault, AWS Secrets Manager |
| Observability | Kann man jede Entscheidung erklären? | OpenTelemetry |
| Revocation | Kann man ihn sofort stoppen? | Token revocation |
Die schichten sind unabhängig
Ein häufiger Fehler ist das Vermischen mehrerer Verantwortungen.
Ein JWT entscheidet nicht über Berechtigungen. Eine Policy Engine beweist keine Identität. Ein Secrets Manager autorisiert keine Aktion.
Jede Schicht ist für eine einzige Verantwortung zuständig. Diese Trennung ermöglicht es, eine Technologie auszutauschen, ohne die Gesamtarchitektur in Frage zu stellen.
Schemadiagramm des modells
Identität
│
┌─────────────────┴─────────────────┐
│ │
Authentifizierung Delegation
│ │
└─────────────────┬─────────────────┘
▼
Autorisierung
│
┌────────────────┴────────────────┐
│ │
Geheimer Zugriff Beobachtbarkeit
│ │
└────────────────┬────────────────┘
▼
Widerruf
Identity ist nicht authentication
Diese beiden Konzepte werden oft verwechselt.
Die Identität beschreibt wer der Agent ist.
Die Authentifizierung überprüft dass er tatsächlich der ist, der er vorgibt zu sein.
Authentifiziert zu sein bedeutet nie, autorisiert zu sein.
Die sechs schichten
1. Identity
Jeder Agent hat einen stabilen Identifikator, eine Version, einen Eigentümer und eine Ausführungsumgebung.
agent:
id: support-agent
version: 2.3.1
owner: customer-support
environment: production
2. Authentication
Die Authentifizierung erlaubt es, diese Identität durch ein JWT, OAuth, mTLS oder eine Workload-Identität zu beweisen.
3. Delegation
Ein Agent handelt selten für sein eigenes Konto. Er handelt für einen Benutzer, einen Tenant oder einen Geschäftsprozess.
4. Authorization
Moderne Autorisierungen basieren zunehmend auf Policy Engines.
Die wichtigsten Modelle sind:
- RBAC
- ABAC
- PBAC
- ReBAC
Agentenbasierte Architekturen bevorzugen generell PBAC, das den Ausführungskontext bewerten kann.
Node.js-Beispiel:
const decision = await policyEngine.evaluate({
identity,
tool: "refundOrder",
amount: 75,
tenant: "acme",
});
if (!decision.allow) {
throw new ForbiddenError(decision.reason);
}
await refundOrder();
5. Secrets
Das Modell manipuliert niemals Secrets direkt.
Es drückt eine Absicht aus; die Anwendung ruft die Secrets von einem dedizierten Manager ab.
6. Observability
Jede Entscheidung muss rückverfolgbar sein: Identität, Vertretener Benutzer, Angewendete Richtlinie, Ergebnis und Ausführungsdauer.
7. Revocation
Jede Identität muss sofort deaktiviert werden können, um neue Aktionen zu verhindern.
Zum mitnehmen
Die Modelle ändern sich.
Die Frameworks entwickeln sich weiter.
Die Protokolle erscheinen und verschwinden dann.
Eine Architektur muss jedoch immer die gleichen Fragen beantworten können:
- Wer handelt?
- In wessen Namen?
- Was kann er tun?
- Wie schützen wir Ressourcen?
- Wie können Entscheidungen erklärt werden?
- Wie stoppt man diesen Agenten sofort?
Solange diese Fragen beantwortet werden, bleibt Ihre Architektur gültig, unabhängig vom verwendeten Modellanbietern oder Framework.
Das im vorherigen Kapitel vorgestellte Agent Identity Reference Model ist absichtlich technologieunabhängig.
Es beantwortet eine architektonische Frage:
Welche Informationen sind erforderlich, um einen Agenten zu sichern?
Dieses Kapitel beantwortet eine andere Frage:
Wie implementiert man dieses Modell konkret in einer modernen Anwendung?
Die gute Nachricht ist, dass es nicht notwendig ist, einen völlig neuen Sicherheits-Stack zu erfinden. Die meisten Unternehmen haben bereits die notwendigen Bausteine.
Eine referenzarchitektur
Benutzer
│
▼
Identity Provider
│
▼
Geschäftsanwendung
│
▼
Agent Runtime
┌───────────────┼────────────────┐
▼ ▼ ▼
Policy Engine Secret Manager Observability
│
▼
Tool Gateway
│
┌────┼───────────────┐
▼ ▼ ▼
CRM PostgreSQL Stripe
Das Sprachmodell ist absichtlich nicht das Zentrum des Diagramms.
Es produziert Vorschläge.
Die Runtime wendet Sicherheitsrichtlinien an.
Die runtime wird zum kontrollpunkt
Jeder Werkzeugaufruf muss als Sicherheitsentscheidung behandelt werden.
Bevor eine Aktion ausgeführt wird, muss die Runtime mehrere Fragen beantworten:
- Wer ist der Agent?
- Für welchen Benutzer handelt er?
- Welcher Tenant ist betroffen?
- Ist diese Aktion autorisiert?
- Werden die Sicherheitsgrenzen eingehalten?
Mit anderen Worten, die Runtime wird zu einem Policy Enforcement Point (PEP).
Ein node.js-middleware statt verteilter logik
Eine gute Praxis ist es, Kontrollen zu zentralisieren.
export async function authorizeTool(ctx, toolName) {
const decision = await policyEngine.evaluate({
identity: ctx.identity,
tool: toolName,
tenant: ctx.tenant,
delegatedUser: ctx.user.id
});
if (!decision.allow) {
throw new ForbiddenError(decision.reason);
}
return decision;
}
Dann nutzt jedes Werkzeug diesen Middleware.
server.registerTool({
name: "refundOrder",
async execute(args, ctx) {
await authorizeTool(ctx, "refundOrder");
return refundService.execute(args);
}
});
Auf diese Weise bleiben Sicherheitsregeln unabhängig vom Modell und vom Prompt.
Ein JWT transportiert eine identität, er entscheidet nichts
Ein JWT kann nützliche Informationen enthalten:
{
"agent":"support-agent",
"tenant":"acme",
"delegatedUser":"user-482",
"scope":["orders.read","orders.update"]
}
Aber ein JWT beantwortet nie die Frage:
Ist diese Operation jetzt autorisiert?
Diese Entscheidung gehört immer der Policy Engine.
Berechtigungen werden bei jeder aktion evaluiert
In einer agentenbasierten Architektur sind Berechtigungen nicht beim Login festgelegt.
Jeder Werkzeugaufruf ist eine neue Entscheidung.
Zum Beispiel kann eine Rückerstattung abhängen von:
- dem Betrag;
- dem Tenant;
- der Rolle des vertretenen Benutzers;
- der Umgebung;
- der Risikorichtlinie.
Die Runtime muss daher vor jeder sensiblen Operation eine Policy Engine abfragen.
Werkzeuge stellen geschäftsfähigkeiten dar
Vermeiden Sie, technische Primitives direkt verfügbar zu machen.
Zu vermeiden:
executeSQL()
executeShell()
deleteCustomer()
Bevorzugen Sie Werkzeuge, die geschäftliche Absicht ausdrücken.
findCustomer()
refundOrder()
updateShippingAddress()
generateInvoice()
Dieser Ansatz reduziert die Angriffsfläche erheblich und vereinfacht die Autorisierungsrichtlinien.
Secrets verlassen niemals die infrastruktur
Das Modell sollte niemals einen Stripe-Schlüssel, ein PostgreSQL-Passwort oder ein AWS-Token erhalten.
Die Runtime ruft diese Secrets von einem dedizierten Manager ab.
import Stripe from "stripe";
const stripe = new Stripe(
await secretManager.get("stripe-API-key")
);
Das Modell drückt eine Absicht aus.
Die Anwendung führt den technischen Aufruf aus.
MCP ersetzt die kontrollen nicht
Das Model Context Protocol (MCP) standardisiert die Erkennung und den Aufruf von Werkzeugen.
Es entscheidet nie, ob ein Werkzeug verwendet werden kann.
Auch wenn ein MCP-Server bereitstellt:
deleteAllCustomers()
Die endgültige Entscheidung gehört immer:
- zur Runtime;
- zur Policy Engine;
- zu Ihrer Architektur.
MCP beschreibt die Fähigkeiten.
Ihre Plattform entscheidet, welche davon wirklich verfügbar sind.
Build oder buy?
Nicht alle Teams haben die gleichen Anforderungen.
| Projektgröße | Empfehlung |
|---|---|
| Prototyp | Regeln im Runtime kodiert |
| Einige Agenten | Einfaches RBAC |
| Multi-Tenant | Policy Engine |
| Regulierte Organisation | Cedar, OPA oder gleichwertiges |
Der Übergang zu einer Policy Engine ist gerechtfertigt, wenn die Regeln zahlreich, entwickelbar oder zwischen mehreren Agenten geteilt werden.
Eine nachhaltige architektur
Einer der Hauptvorteile dieses Ansatzes ist seine Unabhängigkeit von Anbietern.
Sie können ersetzen:
- Claude durch GPT;
- GPT durch Gemini;
- LangGraph durch CrewAI;
- MCP durch ein anderes Protokoll.
Die Sicherheitsarchitektur bleibt unverändert.
Ihre Runtime, Ihre Richtlinien, Ihre Secrets und Ihre Audit-Logs gehören zu Ihrem Informationssystem.
Sie bilden die echte Vertrauensebene Ihrer Plattform.
Zum Mitnehmen
Das Sprachmodell ist niemals die Sicherheitsbehörde.
Es schlägt Aktionen vor.
Ihre Infrastruktur entscheidet, ob sie ausgeführt werden können.
Zu diesem Zeitpunkt hat eine moderne Architektur:
- eine Identität für jeden Agenten;
- einen Authentifizierungsmechanismus;
- eine Policy Engine;
- zentralisierte Secrets-Verwaltung.
Diese Komponenten sind notwendig, reichen aber nicht aus.
Eine Architektur ist wirklich sicher nur, wenn sie geprüft, erklärt und jederzeit gestoppt werden kann.
Audit ist kein einfaches log-file mehr
In einem agentenbasierten System reicht es nicht mehr aus, nur zu erfassen, dass ein Endpunkt aufgerufen wurde.
Jede wichtige Entscheidung sollte ein Ereignis erzeugen, das Folgendes verfolgt:
- die Identität des Agenten;
- den vertretenen Benutzer;
- den Tenant;
- das angeforderte Werkzeug;
- die angewendete Richtlinie;
- die Entscheidung (ALLOW oder DENY);
- das Ausführungsergebnis.
Beispiel:
{
"timestamp": "2026-07-17T10:48:31Z",
"agent": "support-agent",
"delegatedUser": "user-482",
"tenant": "acme",
"tool": "refundOrder",
"decision": "ALLOW",
"policy": "refund-policy-v3",
"durationMs": 91
}
Diese Ereignisse ermöglichen es, eine Entscheidung Wochen nach ihrer Ausführung nachzuverfolgbar zu machen.
Die häufigsten anti-patterns
1. Ein gemeinsamer API-schlüssel
Alle Agenten verwenden dieselbe Identität.
Konsequenz: unmöglich zu wissen, wer verantwortlich ist.
2. Secrets an das modell übermittelt
Ein Stripe-Schlüssel oder ein SQL-Passwort sollte niemals im an den LLM gesendeten Kontext erscheinen.
3. Berechtigungen im prompt definiert
Ein Prompt ist kein Sicherheitsmechanismus.
Autorisierungsregeln müssen auf der Infrastrukturseite implementiert werden.
4. Zu generische werkzeuge
Vermeiden Sie:
executeSQL()
executeShell()
Bevorzugen Sie:
createInvoice()
updateShippingAddress()
Werkzeuge sollten geschäftliche Absichten darstellen.
Eine audit-checkliste
Vor der Produktionsreife überprüfen Sie insbesondere:
- Hat jeder Agent eine eindeutige Identität?
- Sind die vertretenen Benutzer identifiziert?
- Werden Autorisierungen vor jedem Werkzeugaufruf evaluiert?
- Werden Secrets in einem Secret Manager gespeichert?
- Wird jede Entscheidung protokolliert?
- Kann ein Agent sofort widerrufen werden?
- Stellen die Werkzeuge Geschäftsfähigkeiten statt technischer Primitives bereit?
Wenn eine Antwort nein ist, verdient die Architektur wahrscheinlich eine Überprüfung.
Zero trust angewendet auf agenten
Zero Trust-Prinzipien bleiben vollkommen auf agentenbasierte Architekturen anwendbar.
Jede Anfrage muss sein:
- authentifiziert;
- autorisiert;
- verfolgt;
- auf das Allernötigste begrenzt.
Kein Agent sollte als implizit vertrauenswürdig betrachtet werden.
Häufig gestellte fragen
Braucht man einen JWT pro agent?
Nicht unbedingt.
Wichtig ist, dass jede Ausführung eine authentifizierbare und kontextualisierte Identität hat.
Ist rbac ausreichend?
Für einen Prototyp oft ja.
Für mehrere Agenten, mehrere Tenants oder dynamische Regeln wird eine Policy Engine schnell vorzuziehen.
Sichert MCP die werkzeuge?
Nein.
MCP beschreibt die verfügbaren Werkzeuge.
Die Zugriffskontrolle bleibt Aufgabe Ihrer Plattform.
Sollte das modell secrets kennen?
Niemals.
Das Modell formuliert eine Absicht.
Die Runtime führt die technischen Aufrufe mit ihren eigenen Identitäten aus.
Fazit
Lange Zeit war die Anwendungssicherheit um Benutzer und Services herum organisiert.
Agentenbasierte Architekturen führen eine dritte Kategorie von Identität ein: den autonomen Agenten.
Diese Entwicklung erfordert das Überdenken mehrerer Grundlagen:
- Identität;
- Delegation;
- Autorisierung;
- Secrets-Verwaltung;
- Beobachtbarkeit;
- Widerruf.
Die Technologien werden sich weiterentwickeln.
Sprachmodelle werden ersetzt.
Frameworks werden sich ändern.
Die Grundfragen bleiben jedoch gleich:
- Wer handelt?
- In wessen Namen?
- Mit welchen Berechtigungen?
- Wie erklärt man jede Entscheidung?
- Wie unterbricht man einen Agenten sofort?
Organisationen, die diese Fragen beantworten können, verfügen über eine nachhaltige, anbieterunabhängige Architektur, die robust genug ist, um ihre agentenbasierten Systeme im Laufe der Zeit zu entwickeln.
