Agentische Zero-Trust-Sicherheit

license: Apache-2.0 name: agentic-zero-trust-security description: | Kryptografische Sicherheit für agentische Systeme — Zero-Trust-Agenten-Netzwerke, signierte Nachrichtenumschläge (JWS/JWE), fähigkeitsbasierte Sicherheit (oCaps), Merkle-Baum-Prüfpfade, WASM-Sandboxing und formale Verifikation. Behandelt die Sicherheit von CLI-Entwicklungswerkzeugen, mTLS zwischen Agenten, Berechtigungsgrenzen (Least Privilege für KI-Agenten) und Lieferkettensicherheit für Skills/Plugins. Aktivieren bei: "Agentensicherheit", "Zero-Trust-Agenten", "sichere Agentenkommunikation", "fähigkeitsbasierte Sicherheit", "ocap", "signierte Nachrichten zwischen Agenten", "Agentenprüfpfad", "Sandbox-Agentenausführung", "Agentenberechtigungen", "mTLS-Agenten", "kryptografische Verifikation", "Agentenlieferkette", "OWASP agentisch", "beweisen, dass Agent X getan hat", "manipulationssichere Agentenprotokolle". NICHT geeignet für: Anwendungsbezogene SAST-Analyse (verwende security-auditor), Netzwerk-Firewall-Regeln (verwende infrastructure), SOC2/HIPAA-Compliance (organisatorisch) oder Prompt-Injection-Abwehr (verwende prompt-engineer). allowed-tools: Read,Write,Edit,Bash,Glob,Grep,WebSearch,WebFetch metadata: category: Sicherheit & Vertrauen tags: - zero-trust - kryptografie - agentensicherheit - fähigkeitssicherheit - mTLS - prüfpfad - sandboxing - WASM - ocap - formale-verifikation pairs-with: - skill: multi-agent-coordination reason: Sichert die Kommunikationskanäle, auf die Multi-Agenten-Systeme angewiesen sind - skill: agent-conversation-protocols reason: Signierung und Verifizierung von Nachrichtenumschlägen für Agentenprotokolle - skill: security-auditor reason: Ergänzt codebezogene SAST mit architektonischen Sicherheitsmustern category: Sicherheit tags:

• zero-trust
• sicherheit
• agenten
• authentifizierung
• autorisierung

---

Was macht Agentische Zero-Trust-Sicherheit?

Kryptografische Sicherheitsarchitektur für autonome KI-Agentensysteme. Dieses Skill behandelt die Schnittmenge von traditionellem Sicherheitsengineering und den besonderen Herausforderungen von Agenten, die planen, persistent sind, delegieren und über Vertrauensgrenzen hinweg ausführen.

Grundprinzip: Traue niemals, überprüfe immer – angewendet auf jede Agent-zu-Agent-Nachricht, jeden geladenen Skill, jedes aufgerufene Tool und jedes zurückgegebene Ergebnis.

Entscheidungspunkte

1. Bedrohungsstufe → Verifizierungsstrategie

Bedrohungsstufenbewertung:
├── ÖFFENTLICH (Internetagenten, unbekannte Skills)
│   ├── Aktionen: Vollständiges mTLS + JWS + Fähigkeitstoken + WASM-Sandbox
│   ├── Prüfung: Jede Aktion mit Merkle-Nachweis protokolliert
│   └── TTL: Max. 5 Minuten Fähigkeitslebensdauer
├── INTERN (vertrauter Agentencluster)
│   ├── Aktionen: mTLS + JWS + Fähigkeiten (längere TTL)
│   ├── Prüfung: Aggregierte Protokollierung mit täglichem Root-Publish
│   └── TTL: Max. 1 Stunde Fähigkeitslebensdauer
└── ENTWICKLUNG/TEST (localhost, Entwicklung)
    ├── Aktionen: Optionales mTLS + grundlegende Fähigkeiten
    ├── Prüfung: Lokale Dateiprotokolle (kein Merkle-Baum)
    └── TTL: Max. 24 Stunden Fähigkeitslebensdauer

2. Agentenanfrage → Fähigkeitsprüfung → Gewähren/Ablehnen-Logik

Eingehende Agentenanfrageverarbeitung:
├── 1. mTLS-Zertifikatskette überprüfen
│   ├── Gültige CA-Signatur? → Fortfahren
│   └── Ungültig/abgelaufen? → SOFORT ABLEHNEN
├── 2. JWS-Nachrichtenumschlag parsen
│   ├── Signatur gültig + nicht abgelaufen? → Fortfahren
│   ├── Wiederholung erkannt (jti-Cache)? → ABLEHNEN
│   └── Signatur ungültig? → ABLEHNEN + Sicherheitsereignis protokollieren
├── 3. Erforderliche Fähigkeiten prüfen
│   ├── Agent besitzt exakte Fähigkeit? → GEWÄHREN
│   ├── Agent besitzt breitere Fähigkeit? → ABSCHWÄCHEN + GEWÄHREN
│   ├── Fähigkeit abgelaufen? → ABLEHNEN + Aktualisierung erzwingen
│   └── Keine passende Fähigkeit? → ABLEHNEN + minimale Gewährung vorschlagen
└── 4. Mit Sandbox-Einschränkungen ausführen
    ├── WASM-Skills: CPU-/Speicherlimits durchgesetzt
    ├── Dateioperationen: Pfadvalidierung gegen Fähigkeiten
    └── Netzwerkaufrufe: Zielvalidierung gegen Fähigkeiten

3. Delegationskette → Vertrauenstiefenentscheidung

Fähigkeitsdelegierungsanfrage:
├── Übergeordnete Fähigkeit delegierbar=wahr?
│   ├── Ja → Verbleibende Tiefe prüfen
│   │   ├── Tiefe > 0 → Mit Tiefe-1 zulassen
│   │   └── Tiefe = 0 → ABLEHNEN (maximale Delegierung erreicht)
│   └── Nein → ABLEHNEN (nicht delegierbar)
├── Angeforderte Aktionen ⊆ übergeordnete Aktionen?
│   ├── Ja → Teilmenge zulassen
│   └── Nein → ABLEHNEN (kann Berechtigungen nicht eskalieren)
└── Vertrauensgrenze überschritten?
    ├── Gleiche Orchestrator-Domäne → Zulassen
    └── Andere Domäne → Explizite domänenübergreifende Fähigkeit erforderlich

Fehlermodi

1. Umgebungsberechtigungsleck

Erkennung: grep -r "process.env" agent_code/ zeigt Zugriff auf Umgebungsvariablen ohne Fähigkeitsprüfung Symptom: Agent greift auf Ressourcen zu, für die er keine Berechtigungen haben sollte Behebung: Ersetzen durch explizite Fähigkeitstoken, die auf die genauen benötigten Ressourcen beschränkt sind

2. Nachrichtenwiederholungsangriff

Erkennung: Mehrere Prüfpfadeinträge mit identischer jti (Nachrichten-ID) oder Zeitstempeln innerhalb des Wiederholungsfensters Symptom: Agent empfängt und verarbeitet denselben Befehl mehrfach Behebung: Implementieren eines jti-Deduplizierungs-Cache mit TTL, die dem Nachrichtenablauf entspricht

3. Fähigkeitseskalation durch Delegierung

Erkennung: Untergeordnete Fähigkeit hat mehr Aktionen als übergeordnete, oder Delegierungstiefe überschreitet konfiguriertes Maximum Symptom: Unteragenten erhalten mehr Privilegien als von ihrem übergeordneten Delegierer beabsichtigt Behebung: Durchsetzen der Abschwächungsinvariante: untergeordnete Fähigkeiten ⊆ übergeordnete Fähigkeiten zum Zeitpunkt der Delegierung

4. Sandbox-Ausbruch durch Ressourcenverbrauch

Erkennung: Agent-CPU-Auslastung >95% für >30 Sekunden oder Speichernutzung nähert sich Sandbox-Grenzen Symptom: Agent versucht Endlosschleifen oder übermäßige Speicherzuweisung, um aus Beschränkungen auszubrechen Behebung: Hartes Beenden des Agentenprozesses bei Ressourcengrenzen, Implementieren einer kraftstoffbasierten Ausführungsmessung

5. Trust-on-First-Use (TOFU)-Zertifikatsakzeptanz

Erkennung: Agent akzeptiert Zertifikat ohne CA-Verifizierung bei erster Verbindung Symptom: Man-in-the-Middle-Angriffe gelingen, indem ein beliebiges Zertifikat präsentiert wird Behebung: Vorab-Provisionierung aller Agentenzertifikate, expliziten Vertrauensspeicher pflegen, unbekannte CAs ablehnen

Ausgearbeitete Beispiele

Beispiel 1: Multi-Agenten-Nachrichtensignierungspipeline

Szenario: Forschungsagent muss Analyse an Codegenerierungsagenten und dann an Prüfagenten weiterleiten.

Einrichtungsphase:

// Orchestrator erstellt Fähigkeiten
const researchCap = mint.mint('fs:/tmp/research/**', ['read','write'], 'agent-research-001');
const codegenCap = mint.mint('fs:/workspace/src/**', ['read','write'], 'agent-codegen-001'); 
const reviewCap = mint.mint('fs:/workspace/**', ['read'], 'agent-review-001');

Nachrichtenfluss:

1. Forschung → Codegen: Forschungsagent erstellt JWS-signierte Nachricht:

   Header: {alg: 'EdDSA', kid: 'agent-research-001/v1'}
   Nutzdaten: {
     iss: 'agent-research-001',
     sub: 'agent-codegen-001', 
     dag_id: 'proj-alpha-v1',
     action: 'task',
     body: {analysis: "API benötigt OAuth2-Flow", output_path: "/tmp/research/api_analysis.json"}
   }
   

2. Codegen-Verifizierung: Codegen-Agent empfängt Nachricht:

   • Verifiziert JWS-Signatur gegen öffentlichen Schlüssel des Forschungsagenten
   • Prüft Nachrichten-TTL (nicht abgelaufen)
   • Validiert jti nicht im Wiederholungscache
   • Bestätigt, dass dag_id mit aktuellem Ausführungskontext übereinstimmt
   • Experten-Fang: Verifiziert, dass Forschungsagent Fähigkeit für output_path hatte

3. Codegen → Prüfung: Codegen erstellt signiertes Ergebnis:

   {
     "iss": "agent-codegen-001",
     "sub": "agent-review-001",
     "action": "result", 
     "body": {"generated_files": ["/workspace/src/auth.ts"], "confidence": 0.87}
   }
   

Anfängerfehler: Würde jti-Wiederholungsschutz überspringen, was doppelte Verarbeitung ermöglicht. Experteneinsicht: Prüfpfad zeigt vollständige Nachrichtenkette mit kryptografischem Verwahrscheinlichkeitsnachweis.

Beispiel 2: Fähigkeitstokenausstellung mit Abschwächung

Szenario: Hauptagent muss Dateianalyse an spezialisierten Unteragenten delegieren, aber Zugriff auf sensible Verzeichnisse einschränken.

Erstgewährung:

// Orchestrator gewährt breiten Dateisystemzugriff
const mainCap = mint.mint('fs:/project/**', ['read','write','execute'], 'agent-main', {
  delegatable: true,
  maxDepth: 2,
  ttlSeconds: 3600
});

Abschwächungsentscheidungsbaum:

Hauptagent bewertet Delegierungsanfrage:
├── Unteragent fordert an: fs:/project/src/** [read]
│   ├── /project/src/** ⊂ /project/** ? JA
│   ├── [read] ⊂ [read,write,execute] ? JA  
│   ├── Delegierungstiefe 2 > 0 ? JA
│   └── GEWÄHREN: Abgeschwächte Fähigkeit erstellen
├── Unteragent fordert an: fs:/project/secrets/** [read]  
│   ├── Pfad enthält "secrets" → Sicherheitsrichtlinienverstoß
│   └── ABLEHNEN: Ausschluss sensibler Pfade
└── Unteragent fordert an: fs:/etc/passwd [read]
    ├── /etc/passwd ⊂ /project/** ? NEIN
    └── ABLEHNEN: Außerhalb des autorisierten Bereichs

Generierte abgeschwächte Fähigkeit:

const subCap = mint.attenuate(mainCap, 'agent-analyzer-001', ['read']);
// Ergebnis: fs:/project/src/** [read] delegatable=true maxDepth=1 ttl=3600s

Anfängerfehler: Würde volle übergeordnete Fähigkeit ohne Einschränkung gewähren. Experteneinsicht: Abschwächung setzt "niemals Privilegien eskalieren" auf kryptografischer Ebene durch.

Beispiel 3: Sandbox-Richtlinienverstoßerfassung mit Abwägungsanalyse

Szenario: Codegenerierungsagent versucht während der Ausführung auf Netzwerk zuzugreifen, was gegen die Sandbox-Richtlinie verstößt.

Sandbox-Konfiguration:

const codegenSandbox = {
  fileRead: ['/workspace/src/**', '/workspace/package.json'],
  fileWrite: ['/workspace/src/**'], 
  netConnect: false,  // KEIN Netzwerkzugriff
  maxExecutionMs: 300000,
  maxMemoryMb: 512
};

Verstoßerfassungsablauf:

1. Agentenaktion: Codegen versucht fetch('https://api.github.com/repos/...')

2. Sandbox-Abfangen: WASM-Laufzeitumgebung fängt Syscall für Netzwerk-Socket ab

3. Richtlinienprüfung: netConnect: false → VERSTOSS ERKANNT

4. Abwägungsanalyse:

   Sicherheit vs. Funktionalitätsabwägungen:
   ├── STRENG (aktuell): Netzwerk blockieren, Agent beenden
   │   ├── Pro: Keine Netzwerkangriffsfläche
   │   ├── Contra: Kann keine externen Abhängigkeiten/Dokumente abrufen
   │   └── Entscheidung: ERZWINGEN (sicherheitsorientierte Umgebung)
   ├── MODERAT: Bestimmte whitelistierte Domänen zulassen
   │   ├── Pro: Funktionell für bekannte gute APIs  
   │   ├── Contra: DNS-Poisoning, Subdomain-Übernahmerisiken
   │   └── Entscheidung: Nur für Entwicklungsumgebungen in Betracht ziehen
   └── PERMISSIV: Protokollieren, aber zulassen
       ├── Pro: Volle Funktionalität erhalten
       ├── Contra: Agent kann Daten exfiltrieren, Malware herunterladen
       └── Entscheidung: ABLEHNEN (verstößt gegen Zero-Trust-Modell)
   

5. Antwort: Agent beenden, Sicherheitsereignis protokollieren:

   {
     "event": "sandbox_verstoß",
     "agent_id": "agent-codegen-001", 
     "violation_type": "unberechtigter_netzwerkzugriff",
     "attempted_url": "api.github.com",
     "policy_matched": "netConnect: false",
     "action_taken": "agent_beenden"
   }
   

Anfängerfehler: Würde den Netzwerkzugriff "nur dieses eine Mal" zulassen oder den Verstoß nicht erkennen. Experteneinsicht: Sandbox-Verstöße deuten auf potenzielle Kompromittierung oder Modellabweichung hin – immer streng durchsetzen.

Qualitätskriterien

• Jeder Agent hat eine eindeutige kryptografische Identität (Ed25519-Schlüsselpaar + Zertifikat)
• Alle Agent-zu-Agent-Kanäle verwenden gegenseitiges TLS mit Zertifikatsverifizierung
• Alle Nachrichten tragen JWS-Signaturen mit <5min TTL und jti-Wiederholungsschutz
• Fähigkeitstoken folgen dem ocap-Modell (keine Umgebungsberechtigungen irgendwo)
• Fähigkeitsdelegierung wahrt die Abschwächungsinvariante (Kind ⊆ übergeordnete Privilegien)
• Prüfpfad verwendet append-only Merkle-Baum mit veröffentlichten Roots
• Alle Skill-Ausführungen finden in WASM- oder Container-Sandbox statt
• Ressourcenlimits durchgesetzt (CPU, Speicher, Ausführungszeit, Netzwerk)
• Skill-Pakete sind content-addressed und vom Autor signiert
• Kein Agent akzeptiert unsignierte oder unverifizierte Skills/Eingaben
• Zertifikatsrotation automatisiert mit <24 Std. Zertifikatslebensdauer
• Wiederholungserkennungs-Cache betriebsbereit mit TTL, die dem Nachrichtenablauf entspricht
• Alle Sicherheitsverstöße protokolliert mit Zeitstempel + Agentenidentität + ergriffener Maßnahme

NICHT-FÜR-Grenzen

Dieses Skill sollte NICHT verwendet werden für:

• Anwendungsbezogene Schwachstellenscans → Stattdessen security-auditor verwenden
• Netzwerk-Firewall/WAF-Konfiguration → Stattdessen infrastructure-engineer verwenden
• SOC2/HIPAA-Compliance-Dokumentation → Organisatorische Compliance-Prozesse verwenden
• Prompt-Injection-Abwehr → Stattdessen prompt-engineer Skill verwenden
• Ratenbegrenzung oder DDoS-Schutz → API-Gateway-Konfiguration verwenden
• Container-Orchestrierungssicherheit → Stattdessen devops-automator Skill verwenden

Delegierungsgrenzen:

• Für Code-Sicherheitsprobleme → security-auditor
• Für Infrastrukturhärtung → infrastructure-engineer
• Für sichere Codierungspraktiken → software-engineer
• Für Incident-Response → security-incident-response