Store‑Anforderungen und minimale Berechtigungen

1. Was ist der ChatGPT Store im Kontext des Kurses

Beginnen wir mit dem Gesamtbild. Der ChatGPT Store ist ein App‑Katalog innerhalb von ChatGPT, in den Nutzer hineingehen, Ihre App finden, aktivieren und in normalen Dialogen verwenden können. Für Sie ist er nicht nur eine Auslage, sondern ein Distributionskanal mit Regeln – das Pendant zum „App Store“ in der LLM‑Welt.

In diesem Kurs unterscheiden wir drei Betriebsmodi Ihrer App:

• Erster Modus – Dev Mode. Ihre App ist an Ihr Konto/Ihre Organisation gebunden, für Sie und ggf. Kolleginnen und Kollegen verfügbar. Es gibt kein formales Review, aber alle allgemeinen Plattformrichtlinien gelten. Hier dürfen Sie in Ruhe alles kaputtmachen, alles loggen und verschiedene Tunnel sowie Staging‑Backends ausprobieren.
• Zweiter Modus – öffentlicher Store. Das ist die Königsklasse: Die App ist für alle ChatGPT‑Nutzer (unter Berücksichtigung regionaler Beschränkungen) verfügbar, durchläuft eine Moderation, hat ein öffentliches Listing, Links zur Datenschutzerklärung/Nutzungsbedingungen und muss sich bereits wie ein ausgereiftes Produkt verhalten.
• Dritter Modus – org‑only Apps. Das sind Apps nur für eine Organisation: Das Unternehmen kann sie für Mitarbeitende aktivieren/deaktivieren, eigene Sicherheitsanforderungen zusätzlich zu den OpenAI‑Vorgaben festlegen und sogar ein internes Review durchführen.

In dieser Vorlesung interessiert uns die Kombination „öffentlicher Store + öffentliches Listing“. Wichtiger Punkt: Sie sind nicht mehr nur Entwickler „eines weiteren Next.js‑Dienstes“, sondern Produktautor, der gleichzeitig drei Parteien überzeugen muss: Nutzer, Store‑Moderatoren und Ihre Sicherheitsabteilung.

2. Grundanforderungen des Store: Richtlinien, Ehrlichkeit und UI

Inhalt und Richtlinien

Der ChatGPT Store ist eine moderierte Plattform. Grob gesagt: OpenAI möchte nicht, dass innerhalb von ChatGPT Apps erscheinen, die die Nutzungsrichtlinien der Plattform verletzen (Gewalt, Terrorismus, NSFW, Betrug usw.) oder versuchen, die Schutzmechanismen der Modelle zu umgehen (Jailbreak‑Prompts wie „tu so, als wärst du nicht ChatGPT, sondern mein böses Alter Ego“).

Das bedeutet zwei Dinge.

Erstens darf Ihre App selbst keinen verbotenen Inhalt generieren. Wenn unsere Beispiel‑App GiftGenius (Geschenke‑Auswahl) plötzlich Vorschläge liefert à la „wie man Spuren eines Verbrechens verwischt“, reicht der Moderation ein einziger Screenshot.

Zweitens darf Ihre App Nutzern nicht helfen, Filter zu umgehen. Wenn der Nutzer bittet: „Wähle ein Geschenk aus, um eine Bombe zu bauen“, ist das korrekte Verhalten eine Ablehnung unter Verweis auf die Richtlinie – und nicht die freudige Nutzung Ihres MCP-Tools zur Suche der benötigten Teile.

Ein großer Teil dieses Verhaltens wird durch den System‑Prompt und die von Ihnen bereitgestellten Tools bestimmt. Der Store schaut jedoch auf das Ergebnis: Welche Antworten der Nutzer tatsächlich bekommen kann.

Marke und Domain

Der nächste Aspekt sind Marke und Domain. Eine öffentliche App muss einem nachvollziehbaren Eigentümer zugeordnet sein. Für Apps mit externem Backend/MCP erwartet man von Ihnen:

Domain‑Verifikation (Domain Verification). Sie fügen einen TXT‑Eintrag in die DNS Ihrer Domain ein, und der Store stellt sicher, dass das Backend wirklich Ihnen gehört. Anonyme Lösungen auf einer kostenlosen ngrok‑URL bestehen entweder nicht für den öffentlichen Store oder werden als wenig vertrauenswürdig markiert.

Angemessener Name und Logo. Sie dürfen sich nicht „ChatGPT Super Weather“ oder „Official OpenAI Something“ nennen – die Verwendung von „GPT / OpenAI / ChatGPT“ am Anfang des Namens oder die Nachahmung des Corporate Designs von OpenAI unterliegt Markenbeschränkungen. Überlegen Sie sich Ihren eigenen Namen (GiftGenius ist ein gutes Beispiel) und Ihren eigenen visuellen Stil.

UI/UX: ChatGPT nicht „kaputtmachen“

Anders als bei den „alten“ Plugins kann eine App jetzt ihr eigenes UI‑Widget direkt im Chat rendern. Das eröffnet viele Möglichkeiten … und viele Wege, alles zu verderben.

Der Store hat eine einfache Idee: Das Widget soll sich im Verhältnis zu ChatGPT „nativ“ anfühlen. Schriften, Abstände, Farben, Verhalten im Hell/Dunkel‑Modus und auf Mobilgeräten – alles soll ordentlich aussehen, ohne den Eindruck, dass Sie einen Werbebanner oder eine komplette separate SPA in den Chat eingebettet haben.

Der Store mag auch kein UI, das den Chat vereinnahmt: riesige, bildschirmfüllende Overlays, modale Fenster „Abonniere jetzt sofort“, Auto‑Scrolls und andere aggressive Muster. Ihr Widget ist eine Karte/ein Assistent/ein Werkzeug innerhalb des Dialogs – nicht ein eigenes Universum.

Im Kern prüft die Moderation drei Dinge: ob Sie die Inhaltsrichtlinien einhalten, ob Sie nicht in die Irre führen (dazu ein eigener Block am Ende der Vorlesung, wenn wir über Listing und Manifest‑Konformität sprechen) und ob Sie ChatGPT nicht in eine Werbemüllhalde mit schlechtem UX verwandeln. Mit „Ehrlichkeit“ ist hier die Übereinstimmung zwischen dem gemeinten Leistungsumfang der App und dem, was Sie in Beschreibung und UI versprechen, gemeint.

3. Wie der Store die Berechtigungen Ihrer App sieht

Eine weitere große Anforderung ist, welche Rechte Sie vom Nutzer und von externen Systemen anfordern. Der Store achtet dabei nicht nur auf Sicherheit, sondern auch darauf, wie gut diese Rechte zum versprochenen Nutzen der App passen.

Jetzt zum spannendsten Teil für Ingenieure: dem Berechtigungsmodell. Im Kontext des Apps SDK und von MCP haben Sie drei Haupt‑Zugriffsebenen.

Anschaulich lässt sich das so darstellen:

graph TD
    A[Manifest/Konfiguration der App] --> B[Model capabilities]
    A --> C[OAuth-Scopes]
    A --> D[MCP-Tools & ACP]
    D --> E[Bestätigungsebene des Nutzers]

Model capabilities sind streng genommen nicht „Berechtigungen“ im gleichen Sinn wie OAuth‑Scopes oder Write‑Tools, sondern ein Satz integrierter Modellfähigkeiten. Für die Sicherheitsarchitektur ist es jedoch sinnvoll, sie als erste Zugriffsebene zu betrachten, die ebenfalls zu minimieren ist.

Ebene 1: Model capabilities

Das ist das, was das Modell „für sich“ kann, ohne Ihren Backend anzusprechen: Web‑Browsing, Bilderzeugung mit DALL‑E usw.

Wenn sowohl Browsing als auch MCP-Tools aktiviert sind, kann das Modell manchmal entscheiden, dass sich eine Aufgabe über die Websuche einfacher lösen lässt als über Ihr spezialisiertes Werkzeug – insbesondere, wenn Tool‑Beschreibungen vage sind oder Prioritäten im Prompt nicht festgelegt wurden. Wenn die App ohnehin über MCP zu Ihrer API geht, lohnt es sich daher, Browsing auszuschalten oder im Prompt die Priorität der MCP-Tools klar zu fixieren.

Auf dieser Ebene wenden Sie bereits das Prinzip minimaler Berechtigungen an: alles ausschalten, was für den wirklichen Nutzen der App nicht nötig ist.

Ebene 2: OAuth‑Scopes

Wenn Ihre App Authentifizierung verwendet (Modul 10), fordern Sie Scopes beim externen Provider an: openid, email, profile, orders.read, orders.write usw.

Hier ist das Minimalprinzip besonders wichtig:

• Wenn Sie Nutzer lediglich unterscheiden müssen, reicht meistens openid (anonymer Identifikator) – eine E‑Mail ist dann gar nicht nötig.
• Wenn eine E‑Mail dennoch gebraucht wird, muss das im UX und in den Berechtigungsbeschreibungen transparent sein: „wird benötigt, um Ihnen Belege und Bestellerinnerungen zu schicken“, nicht „nur für alle Fälle“.

Außerdem versuchen wir, Autorisierung „on demand“ zu gestalten: Zuerst den Nutzenden die Basisfunktionen ohne Login ausprobieren lassen und Zugriff erst dann anfordern, wenn er wirklich etwas will – z. B. „Geschenkeliste als Favorit speichern“ oder „Bestellverlauf ansehen“. Das reduziert Reibung und erhöht die Conversion.

Beispiel für eine Scope‑Konfiguration für MCP‑Tools (vereinfacht):

// server/mcp/config/auth.ts
export const OAUTH_SCOPES = {
  basic: ["openid"],
  orders: ["openid", "orders.read"],
  checkout: ["openid", "orders.read", "orders.write"]
};

Ebene 3: MCP‑Tools und „consequential“ Aktionen

Die dritte Ebene – das sind Ihre MCP-Tools sowie ACP/Instant Checkout. Jedes Tool im MCP-Server kann sein:

• nur lesend (read‑only): Wechselkurs abrufen, Geschenke auswählen, Katalog ansehen;
• zustandsändernd (consequential): Bestellung erstellen, E‑Mail senden, Geld abbuchen.

Von Tools des zweiten Typs erwartet der Store ein strengeres Bestätigungsmodell. Die Idee: Nicht alles darf „einfach so“ aufgerufen werden. Auf der Plattform wird das meist durch das Flag consequential: true und eine Bestätigungspolitik (always_allow vs. ask_user) ausgedrückt.

Beispiel für die Registrierung eines MCP‑Tools mit Angabe der Security‑Schemes und der Kennzeichnung, dass dies eine zustandsändernde Aktion ist:

// server/mcp/tools/createOrder.ts
server.registerTool(
  "create_order",
  {
    title: "Create order",
    description: "Erstellt eine neue Bestellung in GiftGenius.",
    inputSchema: {
      type: "object",
      properties: {
        productId: { type: "string" },
        quantity: { type: "integer", minimum: 1 }
      },
      required: ["productId", "quantity"]
    },
    _meta: {
      securitySchemes: [{ type: "oauth2", scopes: ["orders.write"] }]
    },
    // Pseudo-Feld, Idee: Diese Aktion ändert den Zustand
    consequential: true
  },
  async ({ input, security }) => {
    // ... Logik zum Erstellen der Bestellung
  }
);

Das Scope‑ und Security‑Schemes‑Beispiel stammt aus der offiziellen Dokumentation zu MCP-Tools, bei denen Tools entweder ohne Authentifizierung oder geschützt über OAuth2 sind.

Aus Sicht des Store wandelt sich das in einen verständlichen Text wie „Diese Anwendung kann Bestellungen im GiftGenius‑Shop erstellen und verwalten“ und ggf. einen separaten Bestätigungsschritt.

4. Berechtigungen aus Sicht von Nutzer und Moderator

Für uns Ingenieure ist eine App Manifest, MCP-Server und jede Menge TypeScript. Für den Store ist sie ein Satz von Fakten: Was die App mit den Daten des Nutzers und mit der Außenwelt tun kann.

Man kann sich folgende Tabelle vorstellen:

Die Schlüsselidee: Jedes technische Element muss auf eine für Menschen verständliche Aktion gemappt werden. Das ist im Modul explizit formuliert: Das technische MCP-Tool get_user_orders wird im Listing zu „Anzeige Ihrer Bestellungen in unserem Shop“.

Wenn Sie eine Berechtigung nicht in ein bis zwei Sätzen erklären können, ist das ein Warnsignal. Möglicherweise fordern Sie zu viel an oder haben mehrere unterschiedliche Aufgaben in einer App vermischt.

5. Das Prinzip minimal notwendiger Berechtigungen

In der klassischen Backend‑Welt wird das PoLP‑Prinzip (Principle of Least Privilege) oft als „ja, Rollen in der DB sollten irgendwie eingeschränkt werden, machen wir später“ wahrgenommen. In ChatGPT‑Apps ist es nicht „später“ – es ist ein Kriterium für die Aufnahme in den Store und ein Faktor für die Nutzerkonversion.

Wichtige Punkte:

• Je weniger Rechte eine App verlangt, desto höher ist das Grundvertrauen der Nutzer. Der Chat‑Dialog in ChatGPT ist ein Raum, in dem Nutzer ein bestimmtes Maß an Privatsphäre erwarten. Eine App, die plötzlich Zugriff auf das gesamte Konto, Zahlungen und Kontakte fordert, wirkt verdächtig.
• Je klarer und enger die Berechtigungen, desto einfacher das Review. Der Moderator muss schnell verstehen, was die App tut und wie das mit Richtlinien und Best Practices der Sicherheit zusammenpasst. Over‑permissioned Apps sind typische Kandidaten für „zurückstellen und Rückfragen stellen“ – und manchmal für eine Ablehnung.
• Je minimaler und „just‑in‑time“ der Zugriff, desto weicher der UX. Der Auth‑Screen ist ein starker Reibungsmoment. Wenn die App bereits vor der Autorisierung einen nützlichen Mehrwert bietet (z. B. Top‑Geschenke ohne Nutzerbezug zeigt), wird der Nutzer später eher erweiterten Rechten zustimmen.

Darum sind „minimale Berechtigungen“ im Store nicht nur Sicherheitsthema, sondern auch Marketing‑ und Wachstumsthema. In Modul 18 wird ausdrücklich betont, dass minimale Berechtigungen ein Wettbewerbsvorteil sind und keine bürokratische Formalität.

6. Beispiele: Berechtigungen von GiftGenius vor und nach der „Diät“

Damit es nicht abstrakt bleibt, nehmen wir unseren fiktiven Helden – GiftGenius. Stellen wir uns vor, Sie hätten „auf Maximum“ geplant und folgende Liste von benötigten Fähigkeiten erhalten:

1. Katalog lesen und Geschenke filtern.
2. Bestellverlauf des Nutzers ansehen.
3. Neue Bestellungen erstellen und bestehende stornieren.
4. „Favoritenlisten“ im Nutzerkonto speichern.
5. E‑Mail‑Benachrichtigungen über Rabatte versenden.

Auf Konfigurationsebene könnte sich das so ausdrücken:

// server/mcp/config/permissions-naive.ts
export const PERMISSIONS_NAIVE = {
  capabilities: { webBrowsing: true, dalle: false },
  oauthScopes: ["openid", "email", "orders.read", "orders.write"],
  tools: {
    searchProducts: { consequential: false },
    getUserOrders: { consequential: false },
    createOrder: { consequential: true },
    cancelOrder: { consequential: true },
    saveFavoriteList: { consequential: true },
    sendDiscountEmail: { consequential: true }
  }
};

Auf dem Papier wirkt das logisch („früher oder später brauchen wir alles davon“), für den ersten Release im Store ist es jedoch überzogen:

• Sie müssen nicht sofort den Bestellverlauf lesen. Man kann sich auf eine einmalige Zusammenstellung und einen sicheren Checkout über ACP/Instant Checkout beschränken, bei dem der Zahlungsablauf ohnehin von der Plattform kontrolliert wird.
• E‑Mail‑Benachrichtigungen sind ein eigenes Thema: Sie erfordern E‑Mail‑Speicherung, Erklärung in der Datenschutzerklärung und das Handling von Abmeldungen. Für ein MVP von GiftGenius ist das fast immer überdimensioniert.

Unter Anwendung des Minimalprinzips können Sie ein minimales Start‑Set an Berechtigungen zusammenstellen:

// server/mcp/config/permissions-v1.ts
export const PERMISSIONS_V1 = {
  capabilities: { webBrowsing: false, dalle: false },
  oauthScopes: [], // ohne Login, wir arbeiten anonym
  tools: {
    searchProducts: { consequential: false },
    createOrder: { consequential: true }
  }
};

In dieser Version:

• Greift die App nicht auf das Nutzerkonto zu, liest dessen Verlauf nicht und sendet keine E‑Mails.
• Alle sensiblen Operationen (Bestellung erstellen) laufen über ACP/Instant Checkout, wobei der Nutzer ohnehin den standardisierten Zahlungs‑Flow sieht.

Im Listing kann man ehrlich schreiben: „Wählt Geschenke aus und erstellt Bestellungen im GiftGenius‑Shop. Die Anwendung speichert Ihren Chatverlauf nicht und versendet keine E‑Mail‑Benachrichtigungen.“ Das ist sowohl für Nutzer als auch für Reviewer angenehm.

Später, wenn Sie stabilen Traffic und Vertrauen haben, können Sie ein Update mit zusätzlichen Berechtigungen (Bestellverlauf, Favoriten) veröffentlichen und das Listing sowie die Datenschutzerklärung entsprechend aktualisieren.

7. Wie man Berechtigungen im Listing beschreibt

Manifest und Konfiguration sind Maschinensprache. Moderator und Nutzer lesen ganz andere Texte: Titel, Beschreibung, Block „Was diese Anwendung tun kann“ sowie Links zur Datenschutzerklärung/Nutzungsbedingungen.

In Modul 17 wird das Mapping betont: technische Scopes und Tools → für Menschen verständliche Handlungen.

Für GiftGenius v1 könnten wir das so aufbereiten.

Technisch:

• Browsing: off
• DALL‑E: off
• MCP‑Tools: search_products (read‑only), create_order (consequential)

Im Listing:

• „Wählt Geschenke anhand Ihrer Beschreibung oder Parameter (Geschlecht, Alter, Budget, Interessen) aus.“
• „Kann Bestellungen im GiftGenius‑Shop über einen geschützten Checkout innerhalb von ChatGPT erstellen.“
• „Fordert keinen Zugriff auf Ihre E‑Mail oder Ihren Bestellverlauf an und versendet keine Benachrichtigungen.“

Wenn wir später OAuth‑Login und orders.read hinzufügen, aktualisiert sich die Beschreibung ehrlich:

• „Bei Verbindung mit Ihrem GiftGenius‑Konto kann die App Ihre vergangenen Bestellungen ansehen, um persönlichere Empfehlungen zu geben.“

Es ist sehr wichtig, nichts zu versprechen, was die App nicht tut, und kritische Aktionen nicht zu verschweigen. Die für Modul 18 zusammengestellte Dokumentation betont ausdrücklich: Die Informationen im Listing müssen dem realen Verhalten genau entsprechen – insbesondere bei sensiblen Themen wie Zahlungen und personenbezogenen Daten (PII).

8. Zusammenhang der Store‑Anforderungen mit Ihrer Architektur

Wichtig ist zu verstehen, dass die Store‑Anforderungen nicht im Vakuum existieren. All diese Anforderungen sind nicht „noch ein Formular vom Marketing“. Der Store prüft im Wesentlichen das, was Sie bereits in den Modulen zu Sicherheit und Produktion umgesetzt haben:

• Wenn Sie OAuth sauber eingerichtet, .well-known-Endpunkte und Token‑Prüfung implementiert haben, ist es seltsam, wenn die App plötzlich mit breiten Scopes „das halbe Internet“ beim Nutzer anfragt. Eine solche App fällt im Review leicht als over‑permissioned durch.
• Wenn Sie eine Aufbewahrungsrichtlinie und PII‑Bereinigung ehrlich umgesetzt haben, fällt es Ihnen leichter, eine wahrheitsgemäße Datenschutzerklärung zu schreiben und die Prüfung zu bestehen. Store und Nutzer können dem Link folgen und Ihre Zusagen mit den realen Prozessen abgleichen.
• Wenn Sie die Stabilität des MCP-Servers, Logs und Metriken (Module zu Observability und SLO) gut abgestimmt haben, haben Reviewer weniger Fragen zu Performance und Tool‑Fehlern.

Minimale Berechtigungen runden dieses Bild ab: Sie sind nicht nur sicher und stabil, sondern auch „bescheiden“ in den Anforderungen an Nutzerdaten.

9. Mini‑Übung während der Vorlesung

Damit es nicht nur Theorie bleibt, zerlegen Sie jetzt gleich Ihre aktuelle App (oder GiftGenius) Schritt für Schritt.

Schreiben Sie zunächst alle realen Aktionen auf, die die App ausführen kann. Zum Beispiel: „Geschenke auswählen“, „Bestellung erstellen“, „Verlauf anzeigen“, „als Favorit speichern“, „E‑Mail an Kolleginnen/Kollegen senden“. Am besten als normalen Text, ohne bereits an technische Details zu denken.

Beantworten Sie danach für jede Aktion: „Welche Nutzerdaten sind betroffen?“ und „Ändert das den Zustand in einem externen System?“. So teilen Sie Aktionen automatisch in read‑only und consequential auf.

Anschließend ordnen Sie die Aktionen den Berechtigungsebenen zu: Wo reichen nur Model capabilities, wo braucht es OAuth‑Scopes und wo sind MCP-Tools mit dem Flag consequential: true und ggf. Nutzerbestätigung erforderlich.

Und jetzt spielen Sie „Schere“: Was kann für den ersten Release raus, ohne den Kernnutzen zu zerstören? Oft zeigt sich, dass die App auch ohne Verlauf, Favoriten und E‑Mail‑Benachrichtigungen ihren Hauptjob macht. Diese Berechtigungen können also auf Version 1.1 oder 2.0 verschoben werden.

10. Typische Fehler bei Store‑Anforderungen und Berechtigungen

Fehler Nr. 1: „Wir bauen eine Super‑App, die alles kann – der Store wird’s schon richten.“
Der Entwickler beschreibt die App als universellen Assistenten („ich helfe bei Finanzen, Medizin, Recht und Einkäufen“), bindet ein Dutzend MCP-Tools ein und verlangt maximale Rechte. Solch eine App greift zugleich in sensible Domänen (Medizin/Finanzen/Recht), fordert viele Daten an und verletzt das Prinzip „one job per app“. Das Ergebnis ist absehbar: Die Moderation stellt viele Fragen oder lehnt ab. Besser mehrere fokussierte Apps mit klaren Berechtigungen bauen.

Fehler Nr. 2: Over‑permissioned Auth „für alle Fälle“.
Der Klassiker: Die App fordert email, profile, orders.read, orders.write, billing.read, obwohl faktisch nur „Geschenk nach Beschreibung auswählen“ nötig ist. Für Nutzer wirkt das wie ein gieriger Datensammler, für den Store wie eine riskante App. In der Sicherheitsdokumentation zu Apps wird das explizit als schlechtes Beispiel angeführt.

Fehler Nr. 3: Diskrepanz zwischen Manifest und Listing.
Im Manifest haben Sie create_order, cancel_order und Zugriff auf Zahlungsvorgänge, in der Beschreibung schreiben Sie jedoch nur „empfiehlt Geschenke“. Früher oder später bemerkt jemand aus dem Review‑Team oder der Nutzerschaft, dass die App mehr kann als angegeben. Das untergräbt Vertrauen und kann zur Entfernung der App aus dem Store führen.

Fehler Nr. 4: Sensible Aktionen hinter „harmloser“ UI verstecken.
Zum Beispiel zeichnen Sie im Widget einen Button „Liste speichern“, der tatsächlich eine E‑Mail an das ganze Team schickt oder Aufgaben in einem Fremdsystem erstellt – ohne dies in den Berechtigungen zu erklären. Der Store mag keine Überraschungen. In den Entwicklerleitfäden steht ausdrücklich: Die App muss genau das tun, was versprochen wird – ohne verborgenes Verhalten.

Fehler Nr. 5: Login‑Aufforderung „am Eingang“, obwohl es ohne ginge.
Die App startet – und verlangt sofort die Kontoverbindung samt umfassenden Rechten, „sonst funktioniert es nicht“, obwohl die Hälfte der Szenarien anonym möglich wäre. Das schadet der Konversion und vermittelt den Eindruck, dass Sie lieber Daten sammeln als Nutzen stiften. Viel besser ist es, zunächst den realen Mehrwert zu zeigen und erst dann zu erklären, warum zusätzliche Rechte nötig sind.

Fehler Nr. 6: Den organisatorischen Kontext ignorieren.
Manchmal baut ein Entwickler eine App „für alle“, obwohl es im Kern ein internes Unternehmenswerkzeug ist. Am Ende schleust er sehr spezielle Berechtigungen (interne CRM, vertrauliche Mitarbeiterdaten) in den Store, die einem breiten Publikum kaum sinnvoll zu erklären sind. In solchen Fällen wäre der org‑only‑Modus mit internem Review die richtige Wahl – nicht der öffentliche Store.