Agenten-Identität & DID (Dezentrale Identifikatoren)

1. Konzeptüberblick und Systemproblem

In den Anfängen der Agentenentwicklung riefen Entwickler ihre persönlichen API-Schlüssel oder Passwörter einfach in Umgebungsvariablen von Skripten auf. Im Jahr 2026, wenn Agenten Finanztransaktionen abwickeln, Produktions-Server verwalten und mit externen Vertragspartnern interagieren, ist dieser Ansatz nicht mehr akzeptabel:

• Fehlende Auditierbarkeit: Logs zeigen an, dass „Alexander" einen Commit durchgeführt hat, obwohl Alexander schlief und ein autonomer Agent den Code geschrieben hat.
• Katastrophaler Schadensradius: Wenn ein Agent durch Prompt Injection kompromittiert wird, erhält der Angreifer alle Rechte des Menschen, einschließlich Zugriff auf persönliche E-Mails und Admin-Panels.

Agent Identity implementiert das Konzept des Agenten als vollwertiges digitales Subjekt mit kryptografischem Ausweis, öffentlichen Schlüsseln und eingeschränkten Berechtigungen.

2. Architektonische Taxonomie und mentales Modell

┌─────────────────────────────────────────────────────────────┐
│               AGENT IDENTITY & TRUST STACK                  │
├─────────────────────────────────────────────────────────────┤
│ 1. Cryptographic Key Management (HSM / Secure Enclave)      │
│    • Private Key (never leaves isolated memory)             │
│    • Public Key / DID URI (did:key:z6MkuT...)               │
├─────────────────────────────────────────────────────────────┤
│ 2. Verifiable Credentials & Delegation Chains               │
│    • Issuer: Human Owner (Org Root Certificate)             │
│    • Scope: "Can execute read/write on repo:app, max $10"   │
│    • Expiration: Ephemeral tokens (TTL = 1 hour)            │
├─────────────────────────────────────────────────────────────┤
│ 3. Attestation & Proof of Execution                         │
│    • Git Commit Signatures (GPG / SSH Sig)                  │
│    • Signed MCP & A2A Requests                              │
├─────────────────────────────────────────────────────────────┤
│ 4. Audit & Revocation Infrastructure                        │
│    • Instant Key Revocation (Kill Switch)                   │
│    • Immutable Append-Only Ledger for Audit Logs            │
└─────────────────────────────────────────────────────────────┘

1. DID (Decentralized Identifier): Ein eindeutiger Identifikator für den Agenten im W3C-Format (z. B. did:web:company.com:agents:devops-01), der es jedem System ermöglicht, seinen öffentlichen Schlüssel zu erhalten, ohne auf zentralisierte Datenbanken zugreifen zu müssen.
2. Short-Lived Delegation (Kurzzeitige Delegation): Der Mensch signiert eine Autorisierung für den Agenten für 60 Minuten. Selbst wenn der Agent außer Kontrolle gerät, verliert sein Zertifikat automatisch seine Gültigkeit.

3. Praktische Engineering-Szenarien in der Produktion

01. Kontrolliertes Infrastruktur-Deployment

Der Agent erhält ein kurzlebiges Zertifikat zur Aktualisierung eines bestimmten Docker-Clusters auf einem VPS. Versucht der Agent, einen Befehl auf einem anderen Server auszuführen, lehnt das Sicherheits-Gateway die Anfrage aufgrund einer ungültigen Signatur ab.

02. Commit-Signierung für ISO 27001 / SOC 2 Compliance

Alle KI-generierten Commits werden mit einer separaten Signatur gekennzeichnet: GPG Signed by Agent ID: 4092. Auditoren können klar erkennen, welche Codezeilen ein menschliches Code-Review durchlaufen haben und welche autonom erstellt wurden.

4. Fallstricke, typische Fehler und Sicherheit

• Speicherung privater Schlüssel in offenen Dateien: Wenn der Agent seinen private_key.pem im Arbeitsverzeichnis speichert, kann ein Angreifer ihn über einen Datei-Lese-Aufruf stehlen. Schlüssel müssen in einer Secure Enclave oder HashiCorp Vault gespeichert werden.
• Fehlender Mechanismus für Notfall-Widerruf (Kill-Switch): Jeder Agent muss einen Status-Check für die Aktivität haben: Eine Änderung eines Flags im IAM-System muss sofort alle seine Signaturen und Tokens widerrufen.

5. Strategisches Fazit für Ingenieure im Jahr 2026

Agent Identity verschiebt die Arbeit mit KI von der Ebene amateurhafter Experimente auf die Ebene der Unternehmenssicherheit und rechtlichen Verantwortung. Ein sicherer Agent ist nicht einfach nur ein Modell im Loop, sondern ein verifizierbares Subjekt mit klar definierten Vertrauensgrenzen.