--- title: "Kann ein KI-Agent dein Produkt benutzen, oder nur darüber lesen?" canonical: https://wavect.io/de/blog/can-an-ai-agent-use-your-product/ language: de description: "Was es braucht, damit ein Produkt agentennutzbar wird statt nur agentenlesbar: delegierte Identität, Autorisierung auf Datenebene, Idempotenz, Fehlersemantik, MCP und Agent Skills." image: "https://wavect.io/img/blog/headers/header_can-an-ai-agent-use-your-product.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min Lesezeit · 18. Aug 2026 Zuletzt geprüft 18. August 2026 [**Weiter**](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) # Kann ein KI-Agent dein Produkt benutzen, oder nur darüber lesen? TL;DR Für einen Agenten lesbar zu sein und von einem benutzbar zu sein sind getrennte Projekte, und die meisten Teams haben nur das erste gemacht. Lesbar heißt, ein Assistent kann dich abrufen, parsen, zitieren und zuordnen. Benutzbar heißt, er kann sich als konkreter Nutzer authentifizieren, ein Tool aufrufen, Zustand ändern und abgelehnt werden, wenn er es soll. Das Zweite ist überwiegend ein Problem von Autorisierung, Identität und Fehlersemantik und nicht des Modells, und sein Tempo hängt daran, wie präzise du Nein sagen kannst, denn ein Lesbarkeitsbug kostet ein Zitat, ein Autorisierungsbug einen Incident. Eine nutzbare Tool-Oberfläche braucht fünf Dinge: delegierte Identität, die ausdrückt, welcher Agent für welchen Nutzer in welchem Scope handelt, Autorisierung auf der Datenebene statt im Prompt, Idempotency-Keys, weil Agenten bei falsch gelesenen Timeouts wiederholen, Fehlermeldungen, die das fehlgeschlagene Feld benennen, damit ein Modell korrigiert statt zu kreisen, und Discovery über MCP und veröffentlichte Agent Skills. MCP ist der Transport und nicht das Autorisierungsmodell; es dafür zu halten ist der häufige Fehler. Eine verteidigbare Reihenfolge sind lesende Tools, dann eine veröffentlichte Karte, dann ein risikoarmer Schreibzugriff hinter menschlicher Genehmigung, und dann Erweiterung nur dort, wo das Audit-Log konsistent korrektes Verhalten zeigt. Niemand kann heute beziffern, wie viel Umsatz über Agenten kommt, das Argument für die frühen Schritte ruht also darauf, dass sie günstig sind und menschlichen Integrationen ohnehin nützen. **Für einen Agenten lesbar zu sein und von einem benutzbar zu sein sind zwei verschiedene Projekte, und fast jedes Team hat nur das erste gemacht.** Lesbar heißt, ein Assistent kann dich zusammenfassen und zitieren. Benutzbar heißt, er kann im Namen einer konkreten Person eine Aufgabe auf deinem Produkt erledigen, und er kann gestoppt werden, wenn er es soll. Das Zweite ist überwiegend kein Modellproblem. Es ist ein Problem von Autorisierung, Identität und Fehlersemantik, und deshalb landet es beim Engineering und nicht im Marketing. ## Zwei verschiedene Fragen | | Lesbar | Benutzbar | | --- | --- | --- | | Was der Agent tut | Abrufen, parsen, zitieren, zuordnen | Authentifizieren, aufrufen, Zustand ändern, zurückmelden | | Oberfläche | HTML, Markdown-Spiegel, llms.txt, JSON-LD | Tools mit Schemas, Identität, Berechtigungen, Audit | | Fehlerfall | Du fehlst in der Antwort | Es passiert etwas, das nicht hätte passieren dürfen | | Preis eines Fehlers | Verlorene Aufmerksamkeit | Verlorene Daten, Geld oder Vertrauen | Die letzte Zeile ist der Grund, warum die zweite Spalte länger dauert. Ein Lesbarkeitsbug kostet dich ein Zitat. Ein Autorisierungsbug kostet dich einen Incident, das Tempo der Arbeit richtet sich also danach, wie zuverlässig du Nein sagen kannst. Wenn die erste Spalte noch nicht erledigt ist, fang dort an. Unser [Guide zu agentenlesbaren Websites](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) behandelt das, und es ist ein Bruchteil des Aufwands. ## Was „benutzbar“ tatsächlich verlangt Eine Tool-Oberfläche, die ein Agent bedienen kann, braucht fünf Dinge, und die interessanten sind nicht die API. - **Identität, die nicht die des Agenten ist.** Der Agent handelt für einen Nutzer oder einen Mandanten. Wenn deine Tokens nicht ausdrücken können „dieser Agent, im Namen dieser Person, für diesen Scope, bis zu diesem Zeitpunkt“, ist praktisch jeder Aufruf ein Admin-Aufruf. - **Autorisierung auf der Datenebene.** Im Prompt zu filtern ist keine Zugriffskontrolle. Die Grenze gehört dorthin, wo die Query läuft, damit eine überzeugende Anweisung sie nicht verschieben kann. - **Idempotenz.** Agenten wiederholen. Sie wiederholen bei Timeouts, die sie falsch gelesen haben, und bei Teilantworten, die sie nicht verstanden haben. Jeder zustandsändernde Aufruf braucht einen Key, der den zweiten Versuch zu einem No-op macht. - **Fehlersemantik, mit der ein Modell etwas anfangen kann.** Ein 400 mit „invalid request“ erzeugt eine Retry-Schleife. Ein 400, das sagt, welches Feld fehlgeschlagen ist und welche Form erwartet wurde, erzeugt einen korrigierten Aufruf. Das ist Dokumentation als Steuerungsfläche. - **Discovery.** Irgendetwas muss dem Agenten sagen, dass die Tools existieren, was sie kosten und wofür sie da sind. Genau das leisten MCP und veröffentlichte Agent Skills. ## Wo MCP hingehört und wo nicht MCP gibt dir einen standardisierten Weg, Tools und Ressourcen einem Modell anzubieten, und es ist der richtige Transport. Es ist kein Autorisierungsmodell, und es dafür zu halten ist der häufigste Fehler in diesem Bereich. Das Protokoll trägt deine Entscheidungen; es trifft sie nicht. Die Designfragen darunter sind die bekannten. Für welchen Mandanten ist dieser Aufruf. Welche Datensätze dieses Mandanten darf dieser Scope sehen. Wer genehmigt einen Schreibzugriff. Was wird geloggt, damit ein Incident rekonstruierbar ist. Wir haben beide Hälften ausführlich aufgeschrieben: [Enterprise-MCP-Autorisierungsarchitektur](/de/blog/enterprise-mcp-authorization-architecture/) für das mandantenfähige Referenzdesign und [MCP-Sicherheitsgrenzen](/de/blog/mcp-security-boundary-data-level-access-control/) dafür, warum nur Durchsetzung auf Datenebene hält. Agent Skills sitzen über den Tools als Instruktionsschicht: wann welches Tool, was die Hausregeln sind, was nie passieren darf. Tools ohne Skills werden falsch benutzt; Skills ohne Tools sind Ratschläge. Wir veröffentlichen unsere als statische Dateien mit Prüfsummen, damit jeder lesen kann, was unseren Agenten gesagt wird. ## Ein Vorgehen, das keinen Glauben braucht Du musst nicht glauben, dass Agent-Traffic groß wird, um die ersten zwei Schritte zu rechtfertigen, denn sie sind günstig und zahlen sich auch für Menschen aus. 1. **Zuerst lesende Tools.** Suche, Lookup, Status. Keine Schreibzugriffe, keine Genehmigungen zu designen, und es übt Identität und Rate Limits unter echten Bedingungen. 2. **Veröffentliche die Karte.** Ein MCP-Endpoint plus Skills, die die Tools ehrlich beschreiben, inklusive dem, was sie ablehnen. 3. **Ein Schreibzugriff, hinter Genehmigung.** Nimm die harmloseste Zustandsänderung, ergänze Idempotency-Keys und setze eine menschliche Bestätigung davor. Logge alles. 4. **Erweitere nach Evidenz.** Entferne das Genehmigungs-Gate nur bei Operationen, bei denen das Log zeigt, dass der Agent konsistent richtig lag, und behalte es überall sonst. Schritt eins und zwei sind bei einer gut geschnittenen API ein paar Tage Arbeit und sofort nützlich, denn dieselben Schemas und Fehlermeldungen machen deine eigenen Integrationen einfacher. Schritt drei ist dort, wo die echte Designarbeit liegt. ## Der ehrliche Teil Niemand kann dir heute sagen, wie viel Umsatz über Agenten kommt. Wer dir eine Zahl nennt, rät, und wir raten nicht für dich. Verteidigbar ist die Form der Wette. Die lesende Oberfläche ist günstig, die Standards konvergieren, und die Arbeit ist nicht verloren, wenn Agent-Traffic klein bleibt, denn typisierte Tools, echte Autorisierungsgrenzen und maschinenlesbare Fehler sollte eine erwachsene API sowieso haben. Was wir nicht täten: ein Produkt um einen Kanal herum neu bauen, der sich noch nicht bewiesen hat. Fang mit dem Teil an, der so oder so nützlich ist. ## Häufige Fragen ### Was ist der Unterschied zwischen einem agentenlesbaren und einem agentennutzbaren Produkt? Lesbar heißt, ein Assistent kann deine Inhalte abrufen, parsen, zitieren und zuordnen. Benutzbar heißt, er kann sich als konkreter Nutzer authentifizieren, ein Tool aufrufen, Zustand ändern und abgelehnt werden, wenn er es soll. Das Erste ist ein Publishing-Problem, das Zweite ein Autorisierungs- und Identitätsproblem. ### Genügt ein MCP-Server, um ein Produkt agentennutzbar zu machen? Nein. MCP ist der Transport, um Tools und Ressourcen anzubieten; es trägt deine Autorisierungsentscheidungen, statt sie zu treffen. Mandanten-Scoping, Berechtigungen auf Datenebene, Genehmigung für Schreibzugriffe und Audit-Logging müssen alle dahinter existieren. ### Warum brauchen Agenten Idempotency-Keys? Weil Agenten wiederholen, auch bei Timeouts, die sie falsch gelesen haben, und bei Teilantworten, die sie nicht verstanden haben. Ohne einen Key, der den zweiten Versuch zu einem No-op macht, wird aus einem Retry eine doppelte Bestellung, Nachricht oder Abbuchung. ### Können wir einfach unsere bestehende REST-API anbieten? Oft ja, mit zwei Änderungen. Fehler müssen sagen, welches Feld fehlgeschlagen ist und was erwartet wurde, damit ein Modell sich korrigieren kann statt zu kreisen. Und Scopes müssen ausdrücken können, dass ein Agent im Namen eines Nutzers handelt, statt eines einzigen Keys, bei dem alles freigeschaltet ist. ### Sollen Agenten in Produktion schreiben dürfen? Irgendwann, und eng begrenzt. Fang lesend an, setz dann einen risikoarmen Schreibzugriff hinter eine menschliche Genehmigung mit Idempotenz und vollem Logging, und entferne das Gate nur dort, wo das Log konsistent korrektes Verhalten zeigt. ### Ist es zu früh, hier zu investieren? Für einen kompletten Rebuild ja. Für lesende Tools und veröffentlichte Skills nein, denn typisierte Tools, echte Autorisierungsgrenzen und maschinenlesbare Fehler verbessern deine eigenen Integrationen, ganz unabhängig davon, ob Agent-Traffic wächst. ## Fazit Lesbar ist ein Publishing-Problem und mit sauberen Kopien und den richtigen Fetchern fast gelöst. Benutzbar ist ein Engineering-Problem, und es hängt daran, wie präzise du Nein sagen kannst. Mach die lesende Oberfläche, weil sie sich ohnehin auszahlt. Designe den Schreibpfad dann um Identität, Autorisierung auf Datenebene, Idempotenz und Audit, und erweitere ihn nach Evidenz statt nach Optimismus. ## Das könnte dich auch interessieren.. [**Enterprise-MCP-Autorisierungsarchitektur** Ein herstellerneutrales, mandantenfähiges Referenzdesign, um Agenten Tools anzubieten, ohne den Blast Radius zu vergrößern.](/de/blog/enterprise-mcp-authorization-architecture/) [**AI Enablement vs eigener KI-Hire** Wann du die Fähigkeit kaufst und wann du sie einstellst, mit dem ehrlichen Break-even.](/de/compare/ai-enablement-vs-in-house-ai-hire/) Agent Engineering ## In diesem Cluster weiterlesen Coding Agents, MCP, Kontextsysteme, Evaluation und Kontrollen für verlässliche Automatisierung. [Mit dem Grundlagenartikel starten**Graph Engineering für KI-Agenten: Wann lohnt sich ein Knowledge Graph?**](/de/blog/graph-engineering-ai-agents/) - [Agentenlesbare Websites: llms.txt, Markdown-Spiegel und was kaputtgeht](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [Lokalisierte URLs zerlegen hreflang: ein englischer Slug genügt](/de/blog/english-slugs-vs-localized-urls-hreflang/) - [Graft Review 2026: Gehört die Repo-Map ins Git?](/de/blog/graft-review-agent-repo-map/) - [Wie du Coding-Agenten mit Tool-Ausgabe-Kompression skalierbar machst](/de/blog/codag-cost-control/) - [Intelligenterer Token-Einsatz mit deinem AI-Coding-Agenten](/de/blog/smarter-token-usage-with-your-ai-coding-agent/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min Lesezeit · 18. Aug 2026 Zuletzt geprüft 18. August 2026 [**Weiter**](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/can-an-ai-agent-use-your-product/#webpage", "@type": "WebPage", "dateModified": "2026-08-18", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-18", "url": "https://wavect.io/de/blog/can-an-ai-agent-use-your-product/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Für einen Agenten lesbar zu sein und von einem benutzbar zu sein sind getrennte Projekte, und die meisten Teams haben nur das erste gemacht. Lesbar heißt, ein Assistent kann dich abrufen, parsen, zitieren und zuordnen. Benutzbar heißt, er kann sich als konkreter Nutzer authentifizieren, ein Tool aufrufen, Zustand ändern und abgelehnt werden, wenn er es soll. Das Zweite ist überwiegend ein Problem von Autorisierung, Identität und Fehlersemantik und nicht des Modells, und sein Tempo hängt daran, wie präzise du Nein sagen kannst, denn ein Lesbarkeitsbug kostet ein Zitat, ein Autorisierungsbug einen Incident. Eine nutzbare Tool-Oberfläche braucht fünf Dinge: delegierte Identität, die ausdrückt, welcher Agent für welchen Nutzer in welchem Scope handelt, Autorisierung auf der Datenebene statt im Prompt, Idempotency-Keys, weil Agenten bei falsch gelesenen Timeouts wiederholen, Fehlermeldungen, die das fehlgeschlagene Feld benennen, damit ein Modell korrigiert statt zu kreisen, und Discovery über MCP und veröffentlichte Agent Skills. MCP ist der Transport und nicht das Autorisierungsmodell; es dafür zu halten ist der häufige Fehler. Eine verteidigbare Reihenfolge sind lesende Tools, dann eine veröffentlichte Karte, dann ein risikoarmer Schreibzugriff hinter menschlicher Genehmigung, und dann Erweiterung nur dort, wo das Audit-Log konsistent korrektes Verhalten zeigt. Niemand kann heute beziffern, wie viel Umsatz über Agenten kommt, das Argument für die frühen Schritte ruht also darauf, dass sie günstig sind und menschlichen Integrationen ohnehin nützen.", "articleBody": " Blog-Übersicht/AI und Agents/Agent Engineering Kann ein KI-Agent dein Produkt benutzen, oder nur darüber lesen? TL;DR Für einen Agenten lesbar zu sein und von einem benutzbar zu sein sind getrennte Projekte, und die meisten Teams haben nur das erste gemacht. Lesbar heißt, ein Assistent kann dich abrufen, parsen, zitieren und zuordnen. Benutzbar heißt, er kann sich als konkreter Nutzer authentifizieren, ein Tool aufrufen, Zustand ändern und abgelehnt werden, wenn er es soll. Das Zweite ist überwiegend ein Problem von Autorisierung, Identität und Fehlersemantik und nicht des Modells, und sein Tempo hängt daran, wie präzise du Nein sagen kannst, denn ein Lesbarkeitsbug kostet ein Zitat, ein Autorisierungsbug einen Incident. Eine nutzbare Tool-Oberfläche braucht fünf Dinge: delegierte Identität, die ausdrückt, welcher Agent für welchen Nutzer in welchem Scope handelt, Autorisierung auf der Datenebene statt im Prompt, Idempotency-Keys, weil Agenten bei falsch gelesenen Timeouts wiederholen, Fehlermeldungen, die das fehlgeschlagene Feld benennen, damit ein Modell korrigiert statt zu kreisen, und Discovery über MCP und veröffentlichte Agent Skills. MCP ist der Transport und nicht das Autorisierungsmodell; es dafür zu halten ist der häufige Fehler. Eine verteidigbare Reihenfolge sind lesende Tools, dann eine veröffentlichte Karte, dann ein risikoarmer Schreibzugriff hinter menschlicher Genehmigung, und dann Erweiterung nur dort, wo das Audit-Log konsistent korrektes Verhalten zeigt. Niemand kann heute beziffern, wie viel Umsatz über Agenten kommt, das Argument für die frühen Schritte ruht also darauf, dass sie günstig sind und menschlichen Integrationen ohnehin nützen. Für einen Agenten lesbar zu sein und von einem benutzbar zu sein sind zwei verschiedene Projekte, und fast jedes Team hat nur das erste gemacht. Lesbar heißt, ein Assistent kann dich zusammenfassen und zitieren. Benutzbar heißt, er kann im Namen einer konkreten Person eine Aufgabe auf deinem Produkt erledigen, und er kann gestoppt werden, wenn er es soll. Das Zweite ist überwiegend kein Modellproblem. Es ist ein Problem von Autorisierung, Identität und Fehlersemantik, und deshalb landet es beim Engineering und nicht im Marketing. Zwei verschiedene Fragen LesbarBenutzbar Was der Agent tutAbrufen, parsen, zitieren, zuordnenAuthentifizieren, aufrufen, Zustand ändern, zurückmelden OberflächeHTML, Markdown-Spiegel, llms.txt, JSON-LDTools mit Schemas, Identität, Berechtigungen, Audit FehlerfallDu fehlst in der AntwortEs passiert etwas, das nicht hätte passieren dürfen Preis eines FehlersVerlorene AufmerksamkeitVerlorene Daten, Geld oder Vertrauen Die letzte Zeile ist der Grund, warum die zweite Spalte länger dauert. Ein Lesbarkeitsbug kostet dich ein Zitat. Ein Autorisierungsbug kostet dich einen Incident, das Tempo der Arbeit richtet sich also danach, wie zuverlässig du Nein sagen kannst. Wenn die erste Spalte noch nicht erledigt ist, fang dort an. Unser Guide zu agentenlesbaren Websites behandelt das, und es ist ein Bruchteil des Aufwands. Was „benutzbar“ tatsächlich verlangt Eine Tool-Oberfläche, die ein Agent bedienen kann, braucht fünf Dinge, und die interessanten sind nicht die API. Identität, die nicht die des Agenten ist. Der Agent handelt für einen Nutzer oder einen Mandanten. Wenn deine Tokens nicht ausdrücken können „dieser Agent, im Namen dieser Person, für diesen Scope, bis zu diesem Zeitpunkt“, ist praktisch jeder Aufruf ein Admin-Aufruf. Autorisierung auf der Datenebene. Im Prompt zu filtern ist keine Zugriffskontrolle. Die Grenze gehört dorthin, wo die Query läuft, damit eine überzeugende Anweisung sie nicht verschieben kann. Idempotenz. Agenten wiederholen. Sie wiederholen bei Timeouts, die sie falsch gelesen haben, und bei Teilantworten, die sie nicht verstanden haben. Jeder zustandsändernde Aufruf braucht einen Key, der den zweiten Versuch zu einem No-op macht. Fehlersemantik, mit der ein Modell etwas anfangen kann. Ein 400 mit „invalid request“ erzeugt eine Retry-Schleife. Ein 400, das sagt, welches Feld fehlgeschlagen ist und welche Form erwartet wurde, erzeugt einen korrigierten Aufruf. Das ist Dokumentation als Steuerungsfläche. Discovery. Irgendetwas muss dem Agenten sagen, dass die Tools existieren, was sie kosten und wofür sie da sind. Genau das leisten MCP und veröffentlichte Agent Skills. Wo MCP hingehört und wo nicht MCP gibt dir einen standardisierten Weg, Tools und Ressourcen einem Modell anzubieten, und es ist der richtige Transport. Es ist kein Autorisierungsmodell, und es dafür zu halten ist der häufigste Fehler in diesem Bereich. Das Protokoll trägt deine Entscheidungen; es trifft sie nicht. Die Designfragen darunter sind die bekannten. Für welchen Mandanten ist dieser Aufruf. Welche Datensätze dieses Mandanten darf dieser Scope sehen. Wer genehmigt einen Schreibzugriff. Was wird geloggt, damit ein Incident rekonstruierbar ist. Wir haben beide Hälften ausführlich aufgeschrieben: Enterprise-MCP-Autorisierungsarchitektur", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-08-18", "datePublished": "2026-08-18", "description": "Für einen Agenten lesbar zu sein und von einem benutzbar zu sein sind getrennte Projekte, und die meisten Teams haben nur das erste gemacht. Lesbar heißt, ein Assistent kann dich abrufen, parsen, zitieren und zuordnen. Benutzbar heißt, er kann sich als konkreter Nutzer authentifizieren, ein Tool aufrufen, Zustand ändern und abgelehnt werden, wenn er es soll. Das Zweite ist überwiegend ein Problem von Autorisierung, Identität und Fehlersemantik und nicht des Modells, und sein Tempo hängt daran, wie präzise du Nein sagen kannst, denn ein Lesbarkeitsbug kostet ein Zitat, ein Autorisierungsbug einen Incident. Eine nutzbare Tool-Oberfläche braucht fünf Dinge: delegierte Identität, die ausdrückt, welcher Agent für welchen Nutzer in welchem Scope handelt, Autorisierung auf der Datenebene statt im Prompt, Idempotency-Keys, weil Agenten bei falsch gelesenen Timeouts wiederholen, Fehlermeldungen, die das fehlgeschlagene Feld benennen, damit ein Modell korrigiert statt zu kreisen, und Discovery über MCP und veröffentlichte Agent Skills. MCP ist der Transport und nicht das Autorisierungsmodell; es dafür zu halten ist der häufige Fehler. Eine verteidigbare Reihenfolge sind lesende Tools, dann eine veröffentlichte Karte, dann ein risikoarmer Schreibzugriff hinter menschlicher Genehmigung, und dann Erweiterung nur dort, wo das Audit-Log konsistent korrektes Verhalten zeigt. Niemand kann heute beziffern, wie viel Umsatz über Agenten kommt, das Argument für die frühen Schritte ruht also darauf, dass sie günstig sind und menschlichen Integrationen ohnehin nützen.", "headline": "Kann ein KI-Agent dein Produkt benutzen, oder nur darüber lesen?", "image": "https://wavect.io/img/blog/headers/header_can-an-ai-agent-use-your-product.svg", "inLanguage": "de", "keywords": "KI-Sichtbarkeit, MCP", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/can-an-ai-agent-use-your-product/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/can-an-ai-agent-use-your-product/", "wordCount": 1571 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/agent-engineering/", "name": "Agent Engineering", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/can-an-ai-agent-use-your-product/", "name": "Kann ein KI-Agent dein Produkt benutzen, oder nur darüber lesen? | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Lesbar heißt, ein Assistent kann deine Inhalte abrufen, parsen, zitieren und zuordnen. Benutzbar heißt, er kann sich als konkreter Nutzer authentifizieren, ein Tool aufrufen, Zustand ändern und abgelehnt werden, wenn er es soll. Das Erste ist ein Publishing-Problem, das Zweite ein Autorisierungs- und Identitätsproblem." }, "name": "Was ist der Unterschied zwischen einem agentenlesbaren und einem agentennutzbaren Produkt?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. MCP ist der Transport, um Tools und Ressourcen anzubieten; es trägt deine Autorisierungsentscheidungen, statt sie zu treffen. Mandanten-Scoping, Berechtigungen auf Datenebene, Genehmigung für Schreibzugriffe und Audit-Logging müssen alle dahinter existieren." }, "name": "Genügt ein MCP-Server, um ein Produkt agentennutzbar zu machen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Weil Agenten wiederholen, auch bei Timeouts, die sie falsch gelesen haben, und bei Teilantworten, die sie nicht verstanden haben. Ohne einen Key, der den zweiten Versuch zu einem No-op macht, wird aus einem Retry eine doppelte Bestellung, Nachricht oder Abbuchung." }, "name": "Warum brauchen Agenten Idempotency-Keys?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Oft ja, mit zwei Änderungen. Fehler müssen sagen, welches Feld fehlgeschlagen ist und was erwartet wurde, damit ein Modell sich korrigieren kann statt zu kreisen. Und Scopes müssen ausdrücken können, dass ein Agent im Namen eines Nutzers handelt, statt eines einzigen Keys, bei dem alles freigeschaltet ist." }, "name": "Können wir einfach unsere bestehende REST-API anbieten?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Irgendwann, und eng begrenzt. Fang lesend an, setz dann einen risikoarmen Schreibzugriff hinter eine menschliche Genehmigung mit Idempotenz und vollem Logging, und entferne das Gate nur dort, wo das Log konsistent korrektes Verhalten zeigt." }, "name": "Sollen Agenten in Produktion schreiben dürfen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Für einen kompletten Rebuild ja. Für lesende Tools und veröffentlichte Skills nein, denn typisierte Tools, echte Autorisierungsgrenzen und maschinenlesbare Fehler verbessern deine eigenen Integrationen, ganz unabhängig davon, ob Agent-Traffic wächst." }, "name": "Ist es zu früh, hier zu investieren?" } ] } ```