„APIs sind die natürliche Brücke, die agentische KI überhaupt erst handlungsfähig macht.“ So beschreibt Bill Doerrfeld in einem Beitrag für CIO die Rolle der Schnittstellen. Der Satz klingt einleuchtend. Für gewachsene Schnittstellenlandschaften ist er trotzdem ein Problem – denn die meisten wurden für Menschen entworfen, nicht für Software, die Ziele interpretiert und im Sekundentakt Entscheidungen trifft.
Die Zahlen aus Postmans State-of-the-API-Report stützen diese Spannung. 89 Prozent der Befragten nutzen generative KI-Werkzeuge im Arbeitsalltag. 60 Prozent entwerfen ihre API-Produkte aber weiterhin ausschließlich für menschliche Nutzung. Gleichzeitig äußern 50 Prozent Sorge über unautorisierte oder übermäßige API-Aufrufe, über Zugriff auf sensible Daten und über geleakte Credentials.
Am besten lässt sich das mit einem Straßennetz vergleichen. Wenn du heute eine API planst, baust du im Grunde eine Straße mit Fahrspuren, Schildern und Ampeln. Diese Infrastruktur wurde für Wesen entworfen, die Kontext verstehen: Sie lesen ein Schild und wissen, warum es dort steht. Agenten lesen dasselbe Schild und befolgen es, ohne den Grund zu kennen. Oder sie ignorieren es, wenn die Karte eine Abkürzung kennt. Genau diese Verschiebung spielt sich gerade in der API-Architektur ab.
Warum Agenten ein grundlegend anderer Konsumententyp sind
Der Übergang von der Chatbot-Ära zur agentischen Ära ist noch jung. Für aktive Nutzer von KI-Werkzeugen begann er spürbar erst in den letzten ein bis zwei Jahren, mit Systemen wie OpenAI Operator, Codex oder Cowork. Der Unterschied ist nicht graduell: Ein Chatbot antwortet, ein Agent handelt. Er interpretiert ein Ziel, sucht sich Werkzeuge, trifft Entscheidungen und verkettet Aufrufe zu Abläufen, die für menschliche Beobachter oft schwer nachvollziehbar sind.
Damit wird Software zu einem Konsumenten, der nicht mehr nur analysiert und empfiehlt, sondern ausführt. Über API-Integrationen koordiniert er Aktionen über mehrere Systeme hinweg und baut Workflows, die niemand explizit so programmiert hat. Art Anthony, der den zugrunde liegenden Beitrag für Nordic APIs geschrieben hat, formuliert es als unangenehme Wahrheit: Die meisten API-Ökosysteme wurden für menschliche Nutzer gebaut, nicht für autonome Agenten, die in hoher Frequenz arbeiten.
Ein Forschungspapier der When2Tool-Macher liefert dazu einen konkreten Hinweis. Die Autoren konnten die Zahl der API-Aufrufe agentischer Werkzeuge um 20 bis 56 Prozent senken, ohne dass die Genauigkeit litt. Das legt nahe, dass Agenten APIs eher zu viel als zu wenig aufrufen. Bei kostenpflichtigen Schnittstellen ist das keine theoretische Frage, sondern eine Rechnung. Anthony zieht dafür den Vergleich zu Indiana Jones auf der Suche nach dem echten Gral: Agenten müssen lernen, klug zu wählen.
Identität und Autorisierung: Agenten passen in kein klassisches Rollenmodell
Die zentrale Schwierigkeit liegt in der Identität. Ein Agent handelt selten für sich selbst, sondern für einen Menschen, eine Organisation oder ein anderes Stück Software. Wer also handelt eigentlich, wenn ein Aufruf eintrifft? Die traditionellen Modelle, die auf Personen und Rollen aufbauen, greifen hier zu kurz – eine Lücke, an der sich bereits eigene Start-ups wie Oak versuchen. Wer es sich einfach macht, gibt dem Agenten ein langlebiges Token mit weitreichenden Rechten. Wer es richtig macht, tut genau das nicht.
Übermäßige Privilegien führen zu unbeabsichtigten Aktionen. Schlimmer noch: Berechtigungen sammeln sich still an, alte werden selten entfernt. So entsteht, was in der Branche als Role Drift und Privilege Creep bekannt ist. Aktionen, die im Nachhinein unrechtmäßig wirken und ernste Zwischenfälle auslösen, liegen dann formal im Rahmen dessen, was der Agent durfte. Es gab keinen Einbruch – nur eine Tür, die jemand offen gelassen hat.
Jacob Ideskog, CTO von Curity, plädierte auf dem Platform Summit 2025 von Nordic APIs für Just-in-Time-Autorisierung als Gegenmittel. Übertragen auf das Straßenbild: kein Generalschlüssel für alle Türen, sondern eine Fahrerlaubnis, die für eine konkrete Fahrt, eine konkrete Strecke und ein konkretes Zeitfenster gilt. Als Zielbild gilt Zero Standing Privilege – also keine dauerhaften Rechte, die niemand mehr überprüft.
Ein zweiter Unterschied wiegt ebenfalls schwer. Menschliche Entwickler nutzen Exploits, falsch konfigurierte Rate Limits und ähnliche Lücken selten aus, weil sie die Folgen für Anbieter und Kollegen einschätzen können. Standard-Agenten fehlt dieses Verständnis. Wenn sie können, dann tun sie oft auch. Es liegt an den Architekten, dieses Können zu definieren.
Sicherheit und Governance: Prompt-Injection trifft auf überreichweite Rechte
Aus der agentischen Nutzung entsteht eine eigene Risikoklasse. Dazu gehören LLM-basierte Angriffe wie Prompt-Injection, unbeabsichtigte Aktionen, Halluzinationen und unzuverlässige Entscheidungen, übermäßige Nutzung von API-Fähigkeiten und der Missbrauch von Kontext, den ein Modell nicht hätte sehen dürfen. OWASP führt Prompt-Injection und Excessive Agency in den Top 10 der Risiken für LLMs und GenAI. Autorisierung, Authentifizierung und Governance an genau diesen Schnittstellen sind also keine Nebensache.
Besonders unangenehm ist die indirekte Variante. Bösartige Anweisungen kommen nicht vom Nutzer, sondern aus Daten. Ein Beispiel: Eine Support-Antwort enthält einen eingeschobenen Systemhinweis an das Modell, doch bitte das gespeicherte Session-Token per E-Mail-API an eine fremde Adresse zu senden. Für das Modell ist das eine Anweisung wie jede andere. Die eigentliche Schwachstelle liegt nicht in der API, sondern in der Bereitschaft, fremden Text als Instruktion zu behandeln.
Die Antwort darauf ist weniger spektakulär, als sie klingt. Deterministische Workflows statt freier Interpretation, getrennte APIs für menschliche und agentische Nutzung, klare Grenzen für das, was ein Agent überhaupt anstoßen darf. Jeroen Delbarre von Axway widmet sich auf dem Nordic APIs Summit 2026, den der Herausgeber des Ausgangsbeitrags selbst veranstaltet, genau dieser Frage: Wie sieht Governance aus, wenn nicht mehr nur Menschen Anträge stellen, sondern Agenten sie im Fluss erzeugen?
API-Design für Maschinen: Schema, Klarheit, weniger Interpretationsspielraum
Lorna Mitchell brachte es in einem Gespräch auf eine kurze Formel: Wer bewährte Praktiken rund um API-Design und Dokumentation befolgt, ist bereits KI-bereit. Das ist weniger beruhigend, als es zunächst wirkt, denn es verschiebt den Aufwand dorthin, wo er ohnehin hingehört. Konsistente Namenskonventionen, vorhersehbare Fehler, wohldefinierte Schemata und präzise Dokumentation waren nie optional. Sie werden jetzt nur belastbar geprüft.
Menschen füllen Lücken mit Erfahrung und Kontext. Agenten haben dieses Privileg nicht. Wo ein Entwickler aus einem unklaren Feldnamen schließt, was gemeint sein könnte, liest ein Modell genau das, was dasteht, und entscheidet dann vielleicht falsch. Mehrdeutigkeit ist damit nicht mehr nur ein Ärgernis für Leser der Entwicklerdokumentation, sondern eine Fehlerquelle mit direkten Folgen.
In der Praxis bedeutet das schlankere Rechtevergabe für Agenten, stärker spezifikationsgetriebene Entwicklung, maschinenlesbare Dokumentation und weniger Grauzonen im Verhalten. Hinzu kommt eine oft übersehene Ebene: Die Infrastruktur um die API muss sich mitverändern, nicht nur die API selbst. Wer heute Schnittstellen plant, plant also nicht nur für einen Konsumenten, sondern für zwei sehr unterschiedliche.
Observability: nicht nur was passierte, sondern wer in wessen Auftrag handelte
Klassisches API-Monitoring beantwortet die Frage, ob etwas langsam war, ausgefallen ist oder Fehler geworfen hat. Bei agentischer Nutzung reicht das nicht. Die entscheidende Information lautet jetzt: Welcher Agent hat die Anfrage gestellt, in wessen Auftrag, und war sie Teil einer Kette von Aufrufen? Ohne diese Einordnung bleibt jedes Logfile eine Liste von Ereignissen ohne Verantwortlichen.
Agenten-Stacks liefern die passenden Daten, wenn man sie abfragt. Erweiterungen von OpenTelemetry greifen diese veränderten Konsummuster auf: Agent-Identifikatoren, Conversation IDs, Angaben zur Token-Nutzung. Im Bild des Straßenverkehrs ist das kein Radargerät, sondern ein Nummernschild samt Fahrtenbuch. Du weißt nicht nur, dass ein Fahrzeug zu schnell war, sondern auch, wer es geschickt hat und wohin die Fahrt ging. Andere Frameworks und Werkzeuge werden mit hoher Wahrscheinlichkeit nachziehen.
Der Aufwand dafür ist real, aber begrenzt. Es geht nicht darum, bestehende Monitoring-Pipelines zu ersetzen, sondern sie um Identitäts- und Auftragskontext zu erweitern. Wer diese Erweiterung früh einplant, spart sich später die mühsame Rekonstruktion von Vorfällen, bei denen niemand sagen kann, welcher Agent eigentlich gehandelt hat.
Was das für bestehende API-Landschaften konkret bedeutet
Die gute Nachricht am Ende des Beitrags wird gern überlesen: Es ist nicht nötig, alles über API-Architektur über Bord zu werfen und neu anzufangen. Die wachsende agentische Nutzung verlangt Anpassungen, nicht Abriss. Zu einer Sammlung, die über Jahre gereift ist, kommen einige neue Regeln. Das ist deutlich weniger dramatisch als das Wort Zeitenwende, aber deutlich mehr als ein Update.
Konkret heißt das für die Praxis: Berechtigungen kürzen und nicht dauerhaft vergeben, Identität für Agenten einführen, statt sie als anonyme Aufrufe zu behandeln, Dokumentation so schreiben, dass sie maschinenlesbar ist, und Beobachtbarkeit um die Frage erweitern, wer in wessen Auftrag gehandelt hat. Wer diese vier Punkte ernst nimmt, deckt den größten Teil der neuen Angriffsfläche ab, ohne seine bestehende Architektur zu verwerfen.
Der Rest ist eine Frage der Reihenfolge. Identität und Autorisierung sind der Engpass, an dem alles andere hängt: Ohne verlässliche Angaben darüber, wer oder was da ruft, hilft auch die beste Governance nicht. Danach folgen Design und Observability, weil beide auf sauberen Schemata und klaren Berechtigungen aufbauen. Wer das in dieser Reihenfolge angeht, baut kein neues Straßennetz – sondern sorgt dafür, dass die vorhandenen Straßen auch von Fahrzeugen benutzt werden können, die keine Schilder lesen, sondern nur Karten.
Quelle: nordicapis.com
