Delegierte KI-Agenten-Authentifizierung mit OAuth 2.0 und IBM Vault

Die Authentifizierung und Autorisierung von KI-Agenten stellt Unternehmen vor neue Herausforderungen – insbesondere, wenn ein Agent im Auftrag eines Nutzers handeln soll. Eine innovative Lösung bietet der OAuth 2.0 Token Exchange Standard (RFC 8693), der die sichere Delegation von Identitäten ermöglicht. In diesem Artikel erfahren Sie, wie IBM Vault als OpenID Connect-Anbieter konfiguriert wird, um diese Delegation technisch umzusetzen.

Warum Identitätsdelegation für KI-Agenten entscheidend ist

Moderne KI-Agenten-Systeme erfordern oft, dass ein Agent im Namen eines Nutzers handelt. Beispielsweise könnte ein virtueller Assistent im Hintergrund Ressourcen verwalten oder Aktionen ausführen, ohne dass der Nutzer ständig neue Anmeldungen durchführen muss. Der OAuth 2.0 Token Exchange Standard adressiert genau dieses Szenario, indem er einen kontrollierten Delegationsmechanismus bereitstellt.

Microsoft Entra Agent ID und Experten wie Christian Posta haben bereits Implementierungen dieses Standards für KI-Agenten vorgestellt. Die Herausforderung besteht darin, diese Mechanismen in bestehende Systeme wie IBM Vault zu integrieren. Der Autor des Artikels entwickelte daher eine benutzerdefinierte Vault-Erweiterung, die RFC 8693 umsetzt und als Proof of Concept dient.

Schritt 1: Subjekt-Token mit erweiterten Berechtigungen generieren

Der erste Schritt im Delegationsprozess besteht darin, dass der Nutzer sich beim KI-Agenten-Client authentifiziert und ein Subjekt-Token (Subject Token) erhält. In dieser Implementierung fungiert IBM Vault als OpenID Connect-Anbieter (OIDC Provider), der spezielle Berechtigungen für die Delegation vergibt.

Ein zentraler Bestandteil ist die Konfiguration eines OIDC-Scopes namens may-act, der zusätzliche Berechtigungsansprüche (may_act-Claim) in das id_token einfügt. Dieser Claim definiert, welche Client-Agenten im Namen des Nutzers handeln dürfen. Die Konfiguration erfolgt über Terraform:

locals {
  may_act_scope_name = "may-act"
  may_act_claim = jsonencode([
    for agent, info in var.client_agents : {
      client_id = agent,
      sub = vault_identity_entity.client_agents[agent].id
    }
  ])
}

resource "vault_identity_oidc_scope" "may_act" {
  name        = local.may_act_scope_name
  template    = <<EOT
{
  "client_id": "${vault_identity_oidc_client.agent.client_id}",
  "may_act": ${local.may_act_claim}
}
EOT
  description = "Claim, der angibt, welche Agenten im Namen des Nutzers handeln dürfen"
}

Der client_id und der sub-Wert im may_act-Claim beziehen sich auf den Client-Agenten, nicht auf den Nutzer selbst. Der Vault-Rollenname (client_id) und die Entitäts-ID (sub) müssen korrekt verknüpft sein, um die Delegation zu validieren. Diese Trennung ist wichtig, da Vault für jede Authentifizierungsmethode eine neue Entität erstellt.

Nach erfolgreicher Authentifizierung erhält der Nutzer ein Subjekt-Token mit einem may_act-Claim, der die autorisierten Agenten auflistet:

{
  "client_id": "Sy0uWliApQrPApxpLp7gYVD0wAjvQNse",
  "iss": "$VAULT_ADDR/v1/identity/oidc/provider/agent",
  "may_act": [
    {
      "client_id": "test-client",
      "sub": "83b1d088-c7d5-b8a4-dd7b-99baca521f8d"
    }
  ],
  "sub": "50099deb-d0cf-911b-4310-64a173c542a6"
}

Für jeden autorisierten Agenten muss ein separater Scope konfiguriert werden. Der Nutzer kann damit gezielt festlegen, welcher Agent in seinem Namen handeln darf.

Schritt 2: Actor-Token für delegierte Zugriffe erstellen

Im nächsten Schritt fordert der Client-Agent ein Actor-Token an, das seine Identität und Berechtigungen für die delegierte Aktion bestätigt. Hier kommt die Vault-Identitäts-Engine ins Spiel, die JSON-Web-Tokens (JWT) mit den erforderlichen Ansprüchen generiert.

Ein Beispiel für ein solches Actor-Token:

{
  "aud": "test-client",
  "client_id": "test-client",
  "iss": "$VAULT_ADDR/v1/identity/oidc",
  "sub": "83b1d088-c7d5-b8a4-dd7b-99baca521f8d",
  "scope": "helloworld:read"
}

Die Identitäts-Engine stellt sicher, dass das Token an eine bestimmte Entität gebunden ist – ein entscheidender Sicherheitsmechanismus. Die Entitäts-ID (sub-Claim) kann mehreren Authentifizierungsmethoden wie Kubernetes oder AppRole zugeordnet sein. Dies ermöglicht eine flexible Integration in bestehende Systeme.

Praktische Umsetzung und Ausblick

Die vorgestellte Lösung kombiniert IBM Vault als OIDC-Anbieter mit dem OAuth 2.0 Token Exchange Standard, um eine sichere und kontrollierte Identitätsdelegation für KI-Agenten zu ermöglichen. Die vollständige Implementierung steht als Open-Source-Beispiel auf GitHub bereit und kann als Ausgangspunkt für eigene Projekte dienen.

Für Unternehmen, die KI-Agenten in Produktionsumgebungen einsetzen, bietet diese Methode eine zuverlässige Grundlage für die Steuerung von Zugriffen und Berechtigungen. Die Integration des Delegationsmechanismus in bestehende Sicherheitsinfrastrukturen wird damit deutlich vereinfacht.

Die weitere Entwicklung in diesem Bereich wird zeigen, wie sich Standards wie RFC 8693 in der Praxis durchsetzen und ob weitere Anbieter spezifische Lösungen für KI-Agenten entwickeln. Eines ist jedoch klar: Identitätsdelegation wird eine zentrale Rolle in der nächsten Generation verteilter KI-Systeme spielen.