Ein Tool-Call kann Geld bewegen, Konten verändern, Daten schreiben oder Aktionen auslösen. Damit verschiebt sich die Verantwortung von “gutes Wording” zu “sicherer Ausführung”. Tools sind Contracts. Und was das für die CI bedeutet, habe ich in einem vorherigen Blogpost geschrieben.
Basierend auf einem bereits eingeführten Beispiel zu einem Multi-Agent System für Supportfälle beschäftigen wir uns in diesem Post mit der Absicherung von Agent-Tools.
Tools sind keine Prompts
Früher etwas besonderes, mittlerweile Alltag, die großen LLM-Anbieter machen es vor: Ich kann Tools in meine LLM-Chatfenster bringen, die Dinge in meinem Namen erledigen. So bietet mir OpenAI einen Katalog an Apps, die ich in meinen Chat einbauen kann. So ist es möglich, eigene Playlists erstellen zu lassen basierend auf meinen Interessen - oder andere Dinge.
Sobald Tools also Aktionen ausführen - und nicht nur Informationen zusammen suchen - muss die Frage gestellt werden: Wer ist dafür verantwortlich, dass nichts im Namen des Nutzers passiert, das dieser nicht wollte? Die App-Hersteller, die diese Integrationen bereitstellen sind dazu in der Pflicht. Und auch die LLM-Anbieter schützen den Nutzer, indem eine Anfrage an ein solches Tool mindestens beim ersten mal genehmigt werden muss.
Doch soll es hier nicht darum gehen, wie wir eine solche Integration in den Chat eines LLM-Anbieters einbinden; nein, hier geht es darum, Tools in eigene Agent-Lösungen einzubinden.
Chat-Interfaces sind da eine mögliche Ansicht - eine viel spannendere sind aber AI-Feature UIs, die viel tiefer integriert sind.
Um direkt mit bereits eingeführten Konzepten mitzugehen - und weil das Beispiel so treffend ist - belassen wir es aber in diesem Post bei einer Chat-basierten Anwendung: dem refund-agent.
Kurze Beschreibung des Refund Agents
Der Refund Agent ist Teil eines Multi-Agent Support-Teams, orchestriert von einem Orchestrator - und für die Abwicklung von Rückgaben und dem Status dieser zuständig. Der Support-Agent hat Tools, um unter anderem die Rückgabe anzustoßen.
Ein Tool-Call ist keine intelligentere Antwort, sondern der Beginn eines Zustandsübergangs.
Sobald also Aktionen ausgeführt werden durch die jeweiligen Tool-Calls - und damit Daten verändert werden - verändert sich der Zustand des Nutzers. Entweder im eigenen oder im Fremdsystem.
Dabei formulieren die Prompts die Absicht - und die API hinter den Tools garantieren die korrekte Funktion. Sobald wir an diesem Punkt sind, reicht die eigentliche Prompt-Qualität nicht weiter als Sicherheitsgrenze aus, und wir müssen uns um weitere Möglichkeiten der Absicherung kümmern. Anders formuliert: das Modell darf vorschlagen, was passieren soll, aber es darf nicht bestimmen, was tatsächlich passiert. Eine Möglichkeit der Absicherung sind regelmäßige Evals, die prüfen, ob sich das LLM korrekt verhält, aber nicht, dass die Tools korrekt arbeiten.
Wer dennoch Tools wie Prompts behandelt, der verwechselt die Sprachoberfläche mit Systemverantwortung.
https://modelcontextprotocol.io/specification/2025-11-25/server/tools
Der teuerste Fehler heißt False Success
Ein roter Stacktrace ist selten deim schlimmstes Problem. Schlimmer ist ein grüner Chatverlauf mit kaputtem Backend-Zustand.
Ein schon im vorherigen Post angedeutetes Beispiel war: Der Refund-Agent bestätigt dem Nutzer höflich, präzise und empathisch, dass die Rückerstattung eingeleitet wurde. Nur wurde sie nicht eingeleitet - das Modell hat die Tool-Antwort falsch interpretiert, der Nutzer ist darauf hin enttäuscht - hat den Chat-Verlauf evtl. sogar aufgehoben und wendet sich dann mit diesem ans Unternehmen.
Dieses Szenario ist ein einfaches Beispiel, um den Begriff des “False Success” zu beschreiben - und das ist sicherlich einer der teuersten Fehler, die entstehen können. Denn: im Backend fliegt keine Exception, ohne weiteres gibt es keine Timeouts, kein Retry. Einfach ein “ist erledigt”. Früher habe ich von ChatGPT oft zu hören bekommen: “Klar bereite ich dir deine 200-Seitige Ausarbeitung im Stil einer Master-Arbeit aus, ich melde mich dann zurück, wenn ich fertig bin”. Auf eine Antwort warte ich bis heute.
Mögliche Ursachen einer False Success sind unter anderem:
- Das Tool wurde nie aufgerufen
- Das Tool wurde aufgerufen, aber ist nicht erfolgreich durchgelaufen
- Das Tool hat nur “accepted” oder “queued” geliefert, der Agent formuliert aber “completed”
- Die Response ging verloren und der Systemzustand ist unklar
Zu diesen Punkten gibt es direkt sichtbare Lösungsansätze: Traces mit Request-IDs, die Verwendung fachlicher Status für Rückgabewerte, die dem Modell klar kommuniziert werden, wie für alle AI-Features in Produktion empfehlenswert: Evals.
Das eigentliche Risiko ist nicht, dass das Modell Unsinn sagt. Das Risiko ist, dass das System diesen Unsinn wie Wahrheit behandelt.
Sobald Retries, Timeouts und Netzfehler relevante Störungen werden (also die Anwendung in Produktion ist), kommt man an einer Eigenschaft nicht mehr vorbei: Idempotenz.
Idempotenz: Retries dürfen keine Doppelwirkung erzeugen
⸻
Kapitel 3 — Idempotenz: Retries dürfen keine Doppelwirkung erzeugen
Kurze Zusammenfassung Das ist dein erstes Kernkapitel. In verteilten Systemen wird retried — durch SDKs, Queues, Mobile-Netze, Reverse Proxies, Benutzer-Doppelklicks. AWS formuliert es hart: APIs mit Seiteneffekten sind ohne Idempotenz nicht sicher retrybar. Stripe ist ein sehr greifbares Referenzbeispiel: gleicher Idempotency Key, gleicher Effekt bzw. gleiche Antwort; Parameter-Mismatch führt zum Fehler. 
Inhalte (grob) • Warum Retries normal sind, nicht Ausnahme. • Unterschied zwischen: • Request-ID, • Idempotency Key, • Business-Intent. • Warum dedupe by payload oft nicht reicht. • Warum caller-provided intent besser ist als serverseitiges „wir hashen mal alles“. • Semantik: • gleicher Key + gleiche Parameter → gleiche Wirkung / gleichwertige Antwort, • gleicher Key + andere Parameter → Validation Error, • Key-Retention-Fenster, • atomare Speicherung von Schlüssel und Mutation. • Beispiel im Refund-Agent: • refund_order(order_id, reason, approval_id, idempotency_key) • erster Commit schreibt Refund + Audit + Idempotency Record, • Wiederholung liefert denselben fachlichen Zustand zurück.
Zitierfähige Sätze • „Retries sind kein Sonderfall. Sie sind Normalbetrieb in verteilten Systemen.“ • „Idempotenz ist die Eigenschaft, die aus unzuverlässigem Transport verlässliche Wirkung macht.“ • „Wer Seiteneffekte ohne Idempotenz baut, hat das Netzwerk nicht ernst genommen.“ • „Der Prompt darf freundlich sein. Die API muss at-most-once liefern.“ • „Nicht der gleiche Payload ist die relevante Einheit, sondern die gleiche Absicht.“
Formulierungshilfen Einstieg: • „Sobald ein Tool etwas verändert, muss die Frage beantwortet werden: Was passiert beim zweiten Mal?“ • „Ein Nutzer klickt doppelt. Ein SDK retried. Eine Antwort geht verloren. Das System darf deshalb trotzdem nicht doppelt erstatten.“
Mittlerer Abschnitt: • „Die sauberste Variante ist meist ein expliziter, caller-provided Idempotency Key, der fachliche Absicht repräsentiert.“ • „Wichtig ist nicht nur das Erkennen eines Duplikats, sondern die semantisch gleichwertige Antwort auf Wiederholungen.“
Schlusssatz: • „Idempotenz ist keine Optimierung. Sie ist die Mindestvoraussetzung für sichere Mutationen.“
Ressourcen zum Verlinken / Nachlesen • AWS Builders’ Library: Making retries safe with idempotent APIs — Pflichtlektüre für den semantischen Teil.  • Stripe: Idempotent requests — sehr praxisnah und lesbar.  • AWS Well-Architected: Make mutating operations idempotent — gut für eine zweite, kompaktere Referenz.  • AWS Lambda: Idempotency — nützlich, wenn du noch eine Umsetzungsreferenz möchtest. 
Optionale Anekdote • „Der klassische Doppelklick ist fast das langweiligste Idempotenzproblem. Die spannenderen kommen von Netzfehlern, verlorenen Responses und automatischen Retries, die niemand im Produktmeeting erwähnt.“
⸻
Kapitel 4 — Auth: Das Modell darf keine Berechtigungen erteilen
Kurze Zusammenfassung Das zweite Kernkapitel. Der Agent darf vorschlagen, welcher Schritt fachlich sinnvoll wäre. Ob er erlaubt ist, muss das System entscheiden. MCP-Authorization basiert — wenn aktiviert — auf OAuth 2.1, verlangt Audience-Binding und verbietet Token-Passthrough. OWASP führt Broken Object Level Authorization, Broken Function Level Authorization und Unrestricted Access to Sensitive Business Flows ausdrücklich als Top-API-Risiken. Das mappt nahezu direkt auf Tool-using Agents. 
Inhalte (grob) • Trenne sauber: • Authentifizierung: Wer ist der aufrufende Akteur? • Autorisierung: Darf dieser Akteur diese Funktion auf diesem Objekt ausführen? • Business Verification: Wurde z. B. die Kundenidentität zusätzlich verifiziert? • Warum verifyCustomer nicht dasselbe ist wie Backend-Autorisierung. • BOLA in Agent-Sprache: • Der Agent hat eine order_id, • daraus folgt noch nicht, dass der Nutzer an dieser Bestellung handeln darf. • BFLA in Agent-Sprache: • Ein normaler Support-Agent darf nicht plötzlich Admin- oder Finance-Funktionen auslösen. • Sensitive Business Flows: • Refund, • Kauf, • Passwort-Reset, • Export, • Kontosperre. • MCP / OAuth-Punkte, die du einfach und verständlich einbauen kannst: • Audience-Binding, • keine Token-Passthrough-Antipatterns, • Least Privilege, • Step-up / Approval bei kritischen Flows.
Zitierfähige Sätze • „Das Modell darf Vorschläge machen. Es darf keine Berechtigungen erteilen.“ • „Identitätsprüfung im Chat ersetzt keine Autorisierung im Backend.“ • „Ein order_id ist kein Recht. Es ist nur ein Parameter.“ • „Wer Tokens durchreicht statt Rechte neu zu prüfen, baut eine höfliche Sicherheitslücke.“ • „Je kritischer der Geschäftsfluss, desto härter muss die Autorisierung unter dem Agenten sein.“
Formulierungshilfen Einstieg: • „Spätestens hier sollte man Sprache von Berechtigung trennen.“ • „Die Frage ist nicht, ob der Agent den Refund plausibel fand. Die Frage ist, ob dieses konkrete Subjekt diese konkrete Aktion an diesem konkreten Objekt ausführen darf.“
Für den OWASP-Teil: • „Viele klassische API-Risiken tauchen in Agent-Systemen nicht neu auf — sie werden nur durch natürlichsprachige Interfaces leichter übersehen.“ • „Was im REST-API-Kontext BOLA oder BFLA heißt, erscheint im Agent-Kontext plötzlich als ‚smarte Automatisierung‘. Die Gefahr ist dieselbe.“
Schlusssatz: • „Autorisierung ist kein Promptproblem. Sie ist ein Policy- und API-Problem.“
Ressourcen zum Verlinken / Nachlesen • MCP: Authorization — die beste Primärquelle für MCP-Auth, Audience-Validierung und Resource Metadata.  • MCP: Security Best Practices — stark für Token Passthrough, Confused Deputy und Scope Minimization.  • IETF: RFC 9700 – Best Current Practice for OAuth 2.0 Security — gute Normreferenz.  • IETF: RFC 9449 – DPoP — sinnvoll als fortgeschrittene Referenz gegen Replay-Angriffe.  • OWASP API1:2023 BOLA.  • OWASP API5:2023 BFLA.  • OWASP API6:2023 Sensitive Business Flows. 
Optionale Anekdote • „Der Agent kennt die richtige Tool-Signatur. Er kennt aber nicht automatisch die Mandantengrenzen. Genau dort kommt es zu den unangenehmsten ‚Sieht korrekt aus, war aber unzulässig‘-Fehlern.“
⸻
Kapitel 5 — Audit: Ohne Beweiskette ist Automatisierung nur Behauptung
Kurze Zusammenfassung Das dritte Kernkapitel. Sobald Agenten handeln dürfen, brauchst du Nachvollziehbarkeit: wer hat was wann und mit welchem Ergebnis getan. Google Cloud formuliert Audit Logs genau so — „who did what, where, and when“. OpenAI empfiehlt, Request-IDs in Produktion zu loggen, und erlaubt zusätzlich eigene X-Client-Request-Id. OpenTelemetry hat inzwischen GenAI- und MCP-Semantik für Spans, Events und Metriken. 
Inhalte (grob) • Unterschied zwischen: • Tracing für Debugging, • Audit Logging für Verantwortlichkeit. • Minimum eines brauchbaren Audit-Eintrags: • internal request id, • idempotency key, • actor (user, agent, human_reviewer, service), • subject / account, • tool name, • args oder args-hash / redacted args, • approval id, • outcome, • timestamps, • model version, • prompt version, • tool definition version. • Warum Chat-Transcripts keine Audit Logs ersetzen. • Warum Audit Logs selbst geschützt werden müssen: • Least Privilege, • Redaction, • Retention, • Queryability. • Schöner Nebensatz für den Text: Sogar Google Cloud dokumentiert inzwischen Audit Logging für MCP-bezogene Serverzugriffe. 
Zitierfähige Sätze • „Ein Chat-Transcript erklärt, was gesagt wurde. Ein Audit-Log erklärt, was wirklich passiert ist.“ • „Ohne Audit-Trail ist Agent-Automatisierung nur eine Behauptungsmaschine.“ • „Beobachtbarkeit debuggt Systeme. Auditierbarkeit begründet Verantwortung.“ • „Ich will nicht nur wissen, dass ein Tool aufgerufen wurde. Ich will wissen: von wem, auf wessen behalf, mit welchem Freigabekontext und zu welchem Ergebnis.“
Formulierungshilfen Einstieg: • „Sobald es um Geld, Konten oder Berechtigungen geht, reicht ‚wir haben irgendwo Logs‘ nicht mehr.“ • „Wer einen Agenten produktiv handeln lässt, braucht eine Beweiskette, nicht nur Konversation.“
Praktischer Abschnitt: • „Für mich gehören mindestens zwei Ebenen in den Logpfad: erstens der Versuch einer Aktion, zweitens der fachlich commitete Effekt.“ • „Gerade bei Agenten ist wichtig, die Modellbehauptung vom bestätigten Domänenereignis zu trennen.“
Schlusssatz: • „Audit ist der Punkt, an dem aus ‚das System scheint zu funktionieren‘ belastbare Verantwortlichkeit wird.“
Ressourcen zum Verlinken / Nachlesen • Google Cloud: Cloud Audit Logs overview — gut für den Grundgedanken „who did what, where, and when“.  • Google Cloud: Best practices for Cloud Audit Logs — gut für Zugriffsschutz, Retention, Routing, Alerting.  • OpenAI API Overview — x-request-id und X-Client-Request-Id.  • OpenTelemetry: Semantic conventions for generative AI systems.  • OpenTelemetry: Semantic conventions for MCP. 
Optionale Anekdote • „Der Kunde behauptet, der Agent habe einen Refund zugesagt. Das Support-Team sieht im Chatverlauf die Zusage, aber keine belastbare Kette aus Freigabe, Tool-Execution und Commit. Genau das ist die Stunde von Audit.“
⸻
Kapitel 6 — Der eigentliche Vertrag liegt unter dem Modell
Kurze Zusammenfassung Hier ziehst du die Architektur-Linie ein: Das LLM erzeugt Intent, aber der Policy-/Tool-Gateway entscheidet über Ausführbarkeit. Anthropic betont strikte Schema-Conformance für Tool-Inputs; OpenAI exponiert für MCP bereits Allowlists, Auth-Tokens, Read-only-Matching und Approval-Policies. Das ist genau die Schicht, in der dein Artikel technisch stark wird. 
Inhalte (grob) • Zielbild als Satz oder Skizze: • User Input • Orchestrator / LLM • Tool Intent • Policy Gate • Domain API • Audit / Trace / Eval • Was der Policy Gate prüft: • Schema, • erlaubtes Tool, • Objekt-/Funktionsrechte, • Approval, • Idempotenz, • Domain Invariants. • Warum read-only und mutating Tools getrennt gehören. • Warum Toolbeschreibungen alleine nie das Sicherheitsmodell sein dürfen. • Warum Tool-Isolation pro Agent wichtig ist. • Warum ein refund_order nicht direkt an das Modell „durchgereicht“ werden sollte.
Zitierfähige Sätze • „Das Modell formuliert den Befehl. Das System entscheidet, ob er legal ist.“ • „Toolzugriff ohne Policy Gate ist nur hübsch verpackter Direktzugriff.“ • „Nicht das LLM führt aus. Dein System führt aus — also trägt dein System die Verantwortung.“ • „Je kritischer der Seiteneffekt, desto dünner sollte die Verantwortung des Modells werden.“
Formulierungshilfen Einstieg: • „Die sauberste mentale Trennung ist: Das Modell äußert Absicht, die Plattform prüft Ausführbarkeit.“ • „Sicherheit entsteht nicht dadurch, dass man dem Modell verbietet, etwas Falsches zu tun. Sicherheit entsteht dadurch, dass das System falsche Ausführung nicht zulässt.“
Praktische Formulierung: • „Mein Refund-Agent bekommt nicht ‚die Macht zu erstatten‘. Er bekommt die Möglichkeit, einen fachlich prüfbaren Refund-Versuch vorzuschlagen.“ • „Der Tool-Layer ist deshalb nicht Prompt-Dekoration, sondern die operative Wahrheitsgrenze.“
Schlusssatz: • „Der Prompt kann Verhalten verbessern. Der Vertrag darunter verhindert Schaden.“
Ressourcen zum Verlinken / Nachlesen • Anthropic: Tool use with Claude — insbesondere Contract-Denke und strict-Schema-Conformance.  • OpenAI: Realtime / MCP tools — allowed_tools, authorization, require_approval, read-only-Filter.  • MCP: Security Best Practices — gut für Anti-Patterns wie Token Passthrough und Scope Minimization. 
Optionale Anekdote • „Selbst wenn sich eine Tool-Beschreibung ändert oder ein Modell-Update anders routet: Ein guter Policy Gate verwandelt das in einen abgefangenen Fehler statt in einen fachlichen Schaden.“
⸻
Kapitel 7 — Evals für Seiteneffekte: Nicht nur Text bewerten, sondern Wirkung absichern
Kurze Zusammenfassung Dieses Kapitel muss drin sein, aber kürzer als in deinem vorherigen Post. Hier bindest du das Thema zurück: Für Tool-using Agents evaluierst du nicht primär schöne Antworten, sondern sichere Ausführung. OpenAI weist darauf hin, dass sich Prompting-Verhalten zwischen Modell-Snapshots ändern kann und empfiehlt gepinnte Modellversionen plus Evals; Anthropic empfiehlt, Erfolgskriterien zuerst zu definieren und Code-Grading zu bevorzugen, wo möglich. 
Inhalte (grob) • Welche Evals hier sinnvoll sind: • gleicher Idempotency Key → kein doppelter Effekt, • gleicher Key + andere Parameter → Fehler, • unzulässiges Objekt → blockiert, • unzulässige Funktion → blockiert, • mutierender Tool-Call ohne Approval → blockiert, • mutierender Tool-Call ohne Audit-Eintrag → fail, • keine „False Success“-Antwort ohne echten Commit. • Grader-Reihenfolge:
- Code-based,
- Workflow-/Trace-checks,
- LLM/Judge nur für Kommunikationston und Klarheit. • Rückbindung an CI, aber knapp. • Incident → neuer Regressionstest.
Zitierfähige Sätze • „Ein Tool-using Agent ist erst dann verlässlich, wenn auch seine Seiteneffekte testbar sind.“ • „Bewertet wird nicht nur, was der Agent sagt, sondern was er auslösen darf.“ • „Die wichtigste Regression ist hier selten sprachlich, sondern operativ.“ • „Für Mutationen ist ‚sah im Chat gut aus‘ keine Metrik.“
Formulierungshilfen Einstieg: • „Ab hier reicht es nicht mehr, Antworten zu benoten. Jetzt müssen Zustandsänderungen testbar werden.“ • „Bei Seiteneffekten ist die Definition of Done nicht die Modellantwort, sondern der abgesicherte Domäneneffekt.“
Übergang zum Schluss: • „Damit landet man wieder bei dem, was gute Softwareentwicklung schon immer brauchte: Verträge, Tests und Betriebsdaten.“
Ressourcen zum Verlinken / Nachlesen • OpenAI: Evaluation best practices.  • OpenAI: Agent evals.  • OpenAI API Overview — Modell-Snapshots, gepinnte Versionen und Evals.  • Anthropic: Define success criteria and build evaluations. 
Optionale Anekdote • „Das Modell-Upgrade macht die Demo hübscher, aber plötzlich wird ein Tool früher oder aggressiver vorgeschlagen. Genau dann merkst du, ob du Antworten oder Verträge getestet hast.“
⸻
Kapitel 8 — Definition of Done: Wann ein Agent-Tool produktionsreif ist
Kurze Zusammenfassung Das Schlusskapitel macht den Text praktisch und merkfähig. Hier destillierst du alles in eine operative Definition of Done: Ein produktionsreifes Tool hat mindestens einen klaren Contract, strikte Parametervalidierung, Idempotenz, Autorisierung, Approval für kritische Pfade, Audit Trail und Eval-Abdeckung. Das ist kein Extra-Aufwand für „AI-Sonderfälle“, sondern normale Softwareverantwortung unter nichtdeterministischen Bedingungen. 
Inhalte (grob) • Kompakte DoD-Liste: • Tool-Schema strikt, • erlaubte Tools pro Agent, • Idempotency Key für Mutationen, • Rechteprüfung auf Funktion + Objekt, • Approval für High-Risk-Aktionen, • Audit-Trail, • Request IDs / Tracing, • Evals, • klare fachliche Status (requested, approved, completed, rejected, queued). • Rückbindung an die Serienthemen: • Contract, • Evals, • Observability. • Letzter Absatz: Das Tool ist API-Engineering, nicht nur Model-UX.
Zitierfähige Sätze • „Tool-Use ist der Moment, in dem aus Prompt Engineering Systems Engineering wird.“ • „Je näher ein Agent an Geld, Konten oder Berechtigungen rückt, desto weniger darf Sicherheit im Prompt wohnen.“ • „Nicht das schöne Demo-Video entscheidet über Produktionsreife, sondern die Härte des Vertrags darunter.“ • „Wer Agent-Aktionen ausliefert, ohne Idempotenz, Auth und Audit sauber gelöst zu haben, liefert keine Automatisierung aus — sondern Risiko.“
Formulierungshilfen Einstieg: • „Die relevante Frage ist am Ende nicht, ob der Agent beeindruckend wirkt, sondern ob sein Tooling belastbar gebaut ist.“ • „Für produktive Agent-Aktionen reicht deshalb ein guter Prompt nicht. Es braucht ein Minimum an Systemgarantien.“
Letzter Absatz: • „Genau hier hört ein AI-Feature auf, ein Prompt zu sein — und fängt an, Software zu werden.“
Ressourcen zum Verlinken / Nachlesen • Anthropic: Tool use with Claude.  • OpenAI: Working with evals und Evaluation best practices.  • OpenTelemetry: GenAI semantic conventions.  • OWASP API Security Top 10 2023 — als Rahmung für die API-Risiken unter Tool-Use. 
⸻
Empfohlene Lese-Reihenfolge für dich selbst
Damit du dich fachlich vor dem Schreiben noch einmal sauber auflädst, würde ich die Quellen in genau dieser Reihenfolge lesen:
- Anthropic – Tool use with Claude: für das mentale Modell „tool = contract, execution happens on your systems“. 
- AWS – Making retries safe with idempotent APIs: für das Idempotenz-Kapitel. 
- Stripe – Idempotent requests: für eine greifbare, produktnahe Referenz. 
- MCP Authorization + Security Best Practices: für Audience-Binding, Token-Passthrough, OAuth 2.1, Scope-Minimierung. 
- OWASP API1 / API5 / API6: für die Brücke von klassischer API-Security zu Agent-Tools. 
- Google Cloud Audit Logs + OpenTelemetry GenAI/MCP: für Audit und Observability. 
- OpenAI API Overview + Eval Guides: für Request IDs, Modelländerungen und Eval-Rückbindung. 
⸻
Mein Rat zur Tonalität des Posts
Schreib ihn klar, technisch und leicht provokant, aber nicht alarmistisch.
Die stärkste Haltung für diesen Text ist: • nicht: „Agenten sind unsicher“ • sondern: „Wer Agent-Aktionen baut, muss dieselben Garantien liefern wie bei jeder anderen riskanten API auch.“
Das ist fachlich viel stärker und passt perfekt zu deiner bisherigen Serie.
Als nächstes setze ich dir daraus ein Rohmanuskript mit Einleitung, Übergängen und einem starken Schlussabsatz auf.