AI-Security-Zielbild — Agenten begrenzen, überwachen, nachweisen

Git (Source of Truth) dokumentiert und versioniert, was wir bauen. Es sieht aber nicht, was ein laufender Agent gerade tut — ob ein Prompt manipuliert wurde, ein Tool-Aufruf in einen fremden Mandanten läuft oder ein Container ungewöhnlich agiert. Genau dort entsteht bei autonomen Agenten der Schaden. Deshalb: Git für Build, Review, Doku und Audit — plus eine Runtime-, Policy-, Monitoring- und Nachweis-Schicht.

Das Kernprinzip

Das LLM sieht nie Credentials und bedient nie frei APIs. Der Agent formuliert eine Absicht — ein Gateway prüft und führt nur erlaubte Aktionen aus (Least Privilege, fail-closed bei Schreib-/Admin-/Produktionszugriffen).

Die fünf Ebenen

Ebene	Leitfrage	Rolle von Git	Zusätzlich nötig — und auf der Plattform
Governance & Risiko	Welche Agenten, Zweck, Risiko, Owner?	Inventare, Doku, Reviews	Agenten-Registry, Risikoklassen, Rezertifizierung → Registry-Seiten vorhanden, als versionierte YAML ausbauen
Architektur & Guardrails	Was darf ein Agent, mit welchen Tools, in welchem Mandanten?	versioniert Policies/Tool-Specs	✅ OPA-PDP, Tool-Trust-Tiers, Tenant-Isolation, Secret-Boundaries (OpenBao)
Build / SDLC	Sind Code, Prompts, Routen geprüft & freigegeben?	Kernstärke	MR-Gates, Secret-Scan, Container-Scan → Gitea live (1und1-git), CI-Gates ausbauen
Laufzeit / Betrieb	Was tut der Agent jetzt? Wird er missbraucht?	sieht es nur indirekt	✅ Wazuh + Falco-Worker-Endpoints + Forwarder-Kette, CrowdSec, Langfuse, Prometheus/Grafana
Assurance / Nachweis	Können wir beweisen, dass Kontrollen wirkten?	Audit-/Review-Spuren	✅ Append-only Evidence (ops-evidence, Paperclip, ClickHouse) → OPA-Decision-Logging verifizieren

Schutzschichten zur Laufzeit

Schutzschicht	Verhindert	Plattform-Umsetzung
Prompt-Injection-/Jailbreak-Guardrails	manipulierte Eingaben führen zu Aktionen	claw-guardrails-adapter, LLM-Guard, NeMo Guardrails
PII-/Secret-Redaction	Datenlecks über Antworten, Logs, Traces	Presidio Analyzer/Anonymizer, redigierte Langfuse-Traces
Policy-Engine	überbreite Tools, Cross-Tenant, unerlaubte Aktionen	OPA-PDP (Rego), Tool-Allowlists, Trust-Tiers
Runtime Detection	Container-Ausbruch, Persistenz, Exfiltration	Falco (Worker), Wazuh-Stack, CrowdSec
SIEM & Monitoring	Vorfälle verstecken sich in Einzellogs	Wazuh + Event-Forwarder (alle Nodes), Grafana
Purple-Team-Runner	Schwächen bleiben unentdeckt	OpenMythos, SecCLAW, promptfoo
Human-in-the-Loop	autonome Schadaktionen	approval-queue, AWX Apply-Gates, ClawPatch
Append-only Evidence	fehlender Nachweis gegenüber Audit/Revision	ops-evidence (Z), Paperclip + Evidence-Bridge, ClickHouse

Der kontrollierte Ausführungspfad (so läuft es hier)

Intent → Klassifizierung (Tenant, Risiko, Datenklasse) → OPA-Entscheid → Inventory nur aus NetBox → Secrets nur als Referenz aus OpenBao → Plan-only → Check-Mode (Diffs redigiert) → Approval-Gate (Low auto / Medium Owner / High Wartungsfenster+Rollback) → Ausführung nur über versionierte AWX-Templates → Healthcheck → ggf. Rollback → Evidence mit Request-ID, Approval-ID, Diff, Ergebnis.

Schnittstellen-Regeln (verbindlich)

• Pro Agent und Zielsystem dedizierte Service-Accounts (z. B. n8n-jira-agent), keine Mitarbeiter-Logins.
• OAuth/kurzlebige Tokens; Secrets nur in OpenBao/n8n-Credentials — nie in Prompt, Code oder Trace.
• Keine Universal-Tools (kein jira_api_call) — enge Tools wie get_ticket_summary, add_internal_comment. Kein Delete/Admin/Bulk-Export ohne Sonderfreigabe.
• Container non-root, kein Host-Netz, kein Docker-Socket; neue Agenten erst Staging, dann begrenzt produktiv.
• Jeder Tool-Aufruf mit Request-ID, Agent-ID, Tenant, Zielsystem, Policy-Decision, Evidence-Link.

Freigabe-Mindestprüfung für produktive Agenten

Zweck+Owner · Risikoklasse (Low/Medium/High) · Datenklassen · enge Tool-Rechte · Service-Account · Secret-Refs mit Rotation · gehärtete Sandbox · aktive Guardrails · geloggte OPA-Entscheidungen · Monitoring+Ticket-Anbindung · HITL für Schreibaktionen · Red-Team-/Rollback-Test · Agentenkarte+Runbook+Löschkonzept · MR-+Security-Review, ggf. Documenso-Signatur. Ohne das: maximal Sandbox oder Read-only.

Agenten-Lebenszyklus

Antrag (Ticket mit Zweck/Owner/Risiko) → Aufbau nur über Git/MR → Sandbox → Pilot → Produktion → laufendes Monitoring → Rezertifizierung mind. quartalsweise (sofort bei neuen Tools/Datenklassen/Routen) → Ablaufdatum je Agent → Deaktivierung bei fehlendem Owner/Finding → Löschung (Accounts sperren, Tokens rotieren, Konfig entfernen, Daten nach Retention, Evidence bleibt) → Nachweis als Ticket + Evidence.

Regulatorik — ein Kontrollsystem, gemappt statt viermal dokumentiert

Nachweis auf der Plattform	Zuordnung
Agenten-Inventar, Risikoklasse, Owner	ISO 42001, NIST AI RMF Govern/Map, EU AI Act techn. Doku
Presidio-PII-Filter, Secret-Redaction	DSGVO, EU AI Act Daten-Governance
Langfuse-Tracing (redigiert)	Logging, Post-Market-Monitoring, Root Cause
Retention-/Löschkonzept	DSGVO Art. 5
HITL / Kill-Switch (approval-queue, Gates)	EU AI Act menschliche Aufsicht, NIS2 Incident Handling
Wazuh/Falco-Detection + Zammad-Incidents	NIS2 Vorfallmanagement (24h/72h-Meldekette)
OpenMythos/SecCLAW-Reports	OWASP Agentic Top 10, MITRE ATLAS, Management-Nachweis

Stand & offene Punkte (2026-07)

EU-AI-Act-High-Risk-Pflichten greifen ab 02.08.2026 (kein High-Risk-Use-Case geplant — Orientierung daran trotzdem sinnvoll). Offen: (1) Git-Backbone-Entscheid — Gitea läuft (1und1-git.ki-guru.com), GitLab auf den 4 Nodes nicht deployed; (2) Agenten-/Tool-Registry als versionierte YAML mit CI-Prüfung; (3) OPA-Decision- Logging nachweisbar machen; (4) Rezertifizierungs-Prozess organisatorisch verankern. Planungs-SaaS (z. B. Linear) bleibt optionale Arbeitsfläche — nie Ablage für Evidence, Freigaben, Secrets oder Agenten-Policies.