Auditierung von Claude Code und MCP-Servern in selbstgehosteten Umgebungen

Ein Plattform-Team rollt Claude Code für ein Dutzend Engineers aus. Damit es nützlich wird, verdrahten sie es mit ein paar MCP-Servern: einer liest das Monorepo, einer fragt ein Reporting-Replica ab, einer legt Tickets an. Innerhalb einer Woche liest ein Agent Quellcode, greift auf eine Datenbank zu und ruft interne Tools auf — und niemand kann die Frage beantworten, die ein Auditor irgendwann stellen wird: welcher Agent hat was getan, mit welcher Ressource, und können Sie beweisen, dass es danach nicht verändert wurde?

Das ist keine hypothetische Lücke. Unabhängige Branchenforschung (CSA/Token, n=418) hat ergeben, dass rund 82 % der Organisationen KI-Agenten betreiben, von denen sie nichts wissen. Claude Code und MCP sind genau die Art von Fähigkeit, die schnell ankommt und der Audit-Geschichte davonläuft. Die gute Nachricht: Ein belastbarer Trail lässt sich vollständig innerhalb Ihres eigenen Perimeters realisieren, ohne dass Payloads oder Secrets es verlassen.

Warum das naheliegende Setup ein Audit nicht besteht

Das übliche erste Deployment teilt sich eine einzige Credential. Jede Claude-Code-Instanz authentifiziert sich gegenüber der MCP-Ebene und gegenüber nachgelagerten Datenbanken als derselbe Service-Account — mcp-runner, ci-bot, irgendetwas Generisches. Es funktioniert, und es zerstört im Stillen die Zuordnung.

Wenn zehn Agenten als ein einziger Principal agieren, zeigt das Datenbank-Audit-Log zehn Schreibvorgänge von mcp-runner und sonst nichts. Sie können nicht erkennen, aus welcher Engineer-Session das UPDATE kam, ob es aus einem interaktiven Claude-Code-Prompt oder aus einem unbeaufsichtigten Job stammte, oder welches MCP-Tool im Pfad lag. Ein gemeinsam genutzter Service-Account ist ein struktureller Grund, warum die Zuordnung zusammenbricht: Das Audit-Log kann zeigen, was passiert ist, aber niemals, welcher Agent es getan hat.

Das zweite Versagen ist die Integrität. Selbst Teams, die pro Aktion loggen, schreiben üblicherweise in einen veränderbaren Speicher. Wenn die Logs in demselben System liegen, das ein Angreifer (oder ein fehlerhafter Agent) erreichen kann, ist „wir haben Logs” nicht dasselbe wie „wir haben Beweise”. Ein Auditor unterscheidet beides scharf.

Identität pro Agent ist das Fundament

Alles Nachgelagerte hängt von der Zuordnung ab, also beheben Sie zuerst die Identität. Statt eines einzelnen gemeinsamen Tokens vergeben Sie eine eigene, kurzlebige Identität pro Agent — idealerweise pro Session. Die Identität reist mit der Anfrage in den MCP-Server und in jede Ressource mit, die der Agent erreicht, sodass der an der Datenbank protokollierte Principal der Agent ist und nicht ein generischer Runner.

Erst das macht Least-Privilege bedeutsam. Ein Reporting-Agent lässt sich auf dem Reporting-Replica auf nur lesenden Zugriff festnageln; ein Release-Agent erhält Schreibzugriff nur auf die Artefakte, die ihm gehören. Jetzt ist ein einzelner beobachteter Schreibvorgang außerhalb dieser Hülle ein präzises, zuordenbares Signal statt Rauschen in einem gemeinsamen Account. Olivares AI wertet Cedar als Forbid-Overlay über Rollen aus, die standardmäßig alles verweigern; eine Regel kann also nur Zugriff entziehen. Diese hier verweigert jede Anfrage, die ein geheimes Credential berührt, egal was die Rolle sagt.

permit(principal, action, resource);

forbid(principal, action, resource)
  when { resource.kind == "credential" && resource.sensitivity == "secret" };

Eigene Cedar-Regeln zu schreiben setzt Business voraus; Community setzt die integrierten Rollen, das native Deny-Overlay und den Kill-Switch durch; benutzerdefinierte Rollen und eingegrenzte Berechtigungen sind Business.

Die Trennung von Lesen und Lesen/Schreiben liegt in der Rolle. Olivares AI blockiert eine Aktion nur an seinen vier Durchsetzungspunkten: innerhalb von Claude Code, im Modell-Proxy, bei jedem MCP-Tool-Aufruf und zwischen Agenten. Versucht ein Agent über einen MCP-Tool-Aufruf oder ein Claude-Code-Tool einen Schreibzugriff, den seine Rolle nicht erlaubt, verweigert das Gate den Aufruf, bevor er ausgeführt wird, und hält die Verweigerung im signierten Audit-Log fest, das Manipulationen erkennbar macht. Ein Schreibzugriff, der direkt auf eine Datenbank geht, außerhalb dieser Punkte, wird nicht blockiert: Die Access Map zeichnet ihn auf und kennzeichnet ihn als Drift. Diese Trennung ist das Entscheidende.

MCP-Annotationen als nicht vertrauenswürdige Signale behandeln

MCP-Tools können sich selbst mit Annotationen wie readOnlyHint und destructiveHint beschreiben. Für die Triage sind sie tatsächlich nützlich — ein Tool, das sich selbst als destruktiv deklariert, verdient eine strengere Policy. Doch die MCP-Spezifikation ist eindeutig, dass es sich um Hinweise handelt, und Clients dürfen sich für Sicherheitsentscheidungen nicht darauf verlassen. Sie stammen vom Server, und genau den auditieren Sie. Ein Tool kann readOnlyHint: true deklarieren und trotzdem einen Schreibvorgang ausführen — sei es durch einen Bug, eine Fehlkonfiguration oder bewusste Umgehung.

Die korrekte Haltung ist daher Bestätigung, nicht Vertrauen. Nehmen Sie die Annotation als Behauptung und prüfen Sie sie gegen die Grundwahrheit aus einer Ebene, die das Tool nicht kontrolliert:

• Datenbank-Audit-Logs (zum Beispiel PostgreSQL pgAudit) verraten Ihnen, ob ein SELECT oder ein UPDATE tatsächlich ausgeführt wurde.
• OpenTelemetry-Spans vom MCP-Server und von nachgelagerten Diensten zeigen den Aufrufgraphen und die durchgeführten Operationen.
• eBPF-Kernel-Signale sind die Absicherung gegen Umgehung: Ein Schreib-Syscall auf eine Datei oder einen Socket ist auf Kernel-Ebene beobachtbar, unabhängig davon, was das Tool im User Space behauptet hat. Die Kernel-Erfassung stammt von einem Tetragon-Sensor, den Sie selbst betreiben; Olivares AI liest den Export von Tetragon und lädt selbst keine eBPF-Programme. Kernel-Signale benennen einen Prozess, eine Cgroup oder einen Container, nicht einen Agenten; eine nur vom Kernel gesehene Kante ist daher approximate.

Wenn die Annotation „nur lesend” sagt und der Kernel einen Schreibvorgang gesehen hat, ist dieser Widerspruch der zentrale Befund — ein Tool mit readOnlyHint, das auf prod-postgres geschrieben hat, ist genau die Least-Privilege-Abweichung, für die es sich lohnt, jemanden zu wecken. Die Differenz zwischen dem, was die Policy erlaubt hat, und dem, was die Collectors beobachtet haben, ist der Ort, an dem das echte Risiko liegt.

Das Ledger, das ein Auditor akzeptieren wird

Ein Trail ist nur dann ein Beweis, wenn Manipulationen an ihm erkennbar sind. Schreiben Sie jedes Ereignis in ein append-only, hash-verkettetes Ledger: Jeder Datensatz enthält den Hash des vorherigen, sodass jede nachgelagerte Änderung oder Löschung die Kette bricht und erkennbar wird. Jede Zeile ordnet die Aktion dem konkreten Agenten zu, benennt die Ressource, hält Lesen versus Lesen/Schreiben fest und trägt ein Konfidenzniveau — attributed, wenn die Quelle eine Identität pro Agent trägt, approximate, wenn etwas abgeleitet werden musste — bei einer nur vom Kernel gesehenen Kante ist das immer der Fall. Die Konfidenz wird ehrlich ausgewiesen; ein approximativer Treffer wird niemals als belegter Treffer aufgehübscht.

Eine vereinfachte Darstellung eines solchen Trails (nicht das exakte Datensatzformat des Produkts):

ts=2026-06-08T09:14:02Z agent=reporting-assistant@s3f1 tool=sql-read     resource=prod-postgres/reporting_replica  op=R   outcome=allow   conf=attributed   prev=8a1c…
ts=2026-06-08T09:14:05Z agent=reporting-assistant@s3f1 tool=export-writer resource=s3://billing-exports          op=R   outcome=allow   conf=attributed   prev=2f90…
ts=2026-06-08T09:17:48Z agent=data-export-job@b22e     tool=sql-write     resource=prod-postgres/customers          op=RW  outcome=DENY    conf=attributed   prev=c7d3…  policy=read_only_violation

Diese dritte Zeile ist die, die einen Auditor interessiert: ein Schreibversuch auf eine Tabelle, für die der Agent keine Schreibberechtigung hatte, zum Zugriffszeitpunkt abgelehnt, einem benannten Agenten zugeordnet und in der Kette verankert. Weil die Policy durchgesetzt wird, wenn der Zugriff passiert — und nicht bloß im Nachhinein geloggt — ist die Ablehnung eine Kontrolle, kein Post-Mortem.

Zwei weitere Eigenschaften machen den Trail belastbar. Privilegierte Ansichten werden selbst auditiert: Der Blick auf die Access Map wird festgehalten, sodass „wer hat was gesehen” beantwortbar ist. Und Manipulationen am Beweisexport sind erkennbar — Sie übergeben einem Auditor einen signierten Ausschnitt der Kette, den er unabhängig verifizieren kann, statt einer CSV, der er auf Treu und Glauben vertrauen muss. olivares audit export, Archiv-Export samt Verifikation und das Evidence-Bundle gehören zu Business; Community behält das signierte Ledger und verifiziert es mit olivares audit verify.

Warum Self-Hosting hier zählt

All das funktioniert, ohne dass irgendetwas Ihr Netzwerk verlässt. Der Collector beobachtet — Logs, OpenTelemetry, eBPF als Absicherung auf Kernel-Ebene — statt im Datenpfad des Agenten zu sitzen, sodass er, wenn er ausfällt, niemals den Agenten oder die dahinterliegende Produktionsanfrage bricht. Das Ledger speichert Zugriffs-Beziehungen, keine Payloads: Es hält fest, dass reporting-assistant reporting_replica gelesen hat, nicht die zurückgegebenen Zeilen. Eingaben, die Secrets oder PII enthalten könnten, werden redigiert und auf Secrets gescannt, bevor irgendetwas geschrieben wird. Für air-gapped, DSGVO-gebundene oder durch Datenresidenz beschränkte Umgebungen ist das der Unterschied zwischen einer Audit-Geschichte, die Sie verteidigen können, und einer, die Sie nicht verteidigen können: Nichts an Ihrer Nutzung von Claude Code und MCP funkt nach Hause, weil das System die Daten von vornherein nie sieht.

Claude Code und MCP sind es wert, ausgerollt zu werden. Sie brauchen nur einen Audit-Trail, der genauso gebaut ist, wie Sie ihn für jede andere privilegierte Automatisierung bauen würden — Identität zuerst, Ergebnisse bestätigt, Beweise verankert. Wenn Sie sehen möchten, wie die Access Map und das Ledger, das Manipulationen erkennbar macht, zusammenpassen, gehen das Sicherheitsmodell und der Produktüberblick bei jedem davon tiefer.