Paperclip für KI-Agententeams: Wann KMU eine Steuerungsebene brauchen

Paperclip macht aus KI-Agenten keine Mitarbeiter. Aber es versucht, aus verstreuten Agenten einen steuerbaren Betrieb zu machen – mit Zuständigkeiten, Budgets, Freigaben und Protokollen.

Für KMU ist deshalb nicht die spannendste Frage, wie viele Agenten sich „einstellen“ lassen. Sondern ab wann deren Koordination ein eigenes Betriebsproblem wird.

„KI-Unternehmen“ und „KI-Mitarbeiter“ sind hier Produktmetaphern: Paperclip gründet keine Firma, übernimmt keine rechtliche Verantwortung und macht Agentenergebnisse nicht automatisch richtig. Software, Zugriffsrechte und Verantwortung bleiben beim Betreiber.

Kurzantwort: Paperclip ist weder ein Sprachmodell noch ein Ersatz für n8n. Es ist eine Steuerungsebene, die bestehende KI-Agenten über Rollen, Aufgaben, Budgets, Freigaben und Aktivitätsdaten koordiniert. Sinnvoll wird sie vor allem dann, wenn mehrere Agenten und ihre Übergaben bereits messbar Zeit, Risiko oder Kosten erzeugen. Für einen einzelnen Agenten oder einen stabilen Wenn-dann-Prozess ist sie meist mehr Infrastruktur als Lösung.

Produkt-, Richtlinien- und Quellenstand: 15. September 2026. Volatile Angaben sind vor einer Umsetzung erneut zu prüfen.

Was Paperclip genau ist

Paperclip bezeichnet sich als Orchestrierungsplattform für autonome Unternehmen. Für eine belastbare Entscheidung ist die nüchternere Kategorie hilfreicher: eine zentrale Steuerungs- und Kontrollebene (Control Plane) für mehrere KI-Agenten.

Das System führt nicht selbst die eigentliche Modellarbeit aus. Stattdessen verbindet es Agenten-Laufzeiten, organisiert Aufträge und stellt eine gemeinsame Bedien- und Kontrollebene bereit. Laut Produktdefinition ist Paperclip ausdrücklich kein Chatbot, kein Agenten-Framework, kein Prompt-Manager, kein Single-Agent-Assistent und kein visueller Workflow-Builder.

Eine „Company“ ist in Paperclip ein Organisationscontainer. Sie bündelt laut Dokumentation der Kernkonzepte ein Unternehmensziel, Agenten, Hierarchie, Projekte, Aufgaben und Budget. Agenten berichten entlang einer Organisationsstruktur; an ihrer Spitze steht ein CEO-Agent, der dem menschlichen Board untergeordnet bleibt.

Die praktische Arbeit läuft vereinfacht so:

1. Ein Mensch definiert Ziel, Projekte und Rollen.
2. Aufgaben werden als Issues beziehungsweise Tickets angelegt und Agenten zugeordnet.
3. Eine Anbindung – bei Paperclip „Adapter“ – startet die passende Agenten-Laufzeit.
4. Ein Arbeitslauf – in der Oberfläche „Heartbeat Run“ – bearbeitet den Auftrag.
5. Status, Kosten und Aktivitäten fließen in die gemeinsame Oberfläche zurück.
6. Bestimmte Entscheidungen oder Überschreitungen können eine menschliche Freigabe auslösen.

Das ist deutlich mehr als eine lose Sammlung von Prompts. Es ist aber noch keine Garantie für gute Arbeit. Paperclip kann Zuständigkeiten und Kontrollpunkte strukturieren; ob ein Agent den Inhalt versteht, ein Werkzeug korrekt bedient oder ein Geschäftsrisiko erkennt, bleibt eine eigene Frage.

Welche Agenten-Laufzeiten kann Paperclip anbinden?

Die Übersicht der Anbindungen nennt am Quellenstichtag unter anderem Claude Code, Codex, Gemini CLI, Cursor, OpenCode, Pi, Hermes, Grok und Kimi. Paperclip ersetzt diese Laufzeiten nicht, sondern startet und koordiniert sie.

Wichtig: Eine solche Liste bedeutet nicht, dass jede Anbindung dieselbe Reife, dieselben Funktionen oder dieselbe Bedienoberfläche besitzt. Statushinweise unterscheiden sich. Auch die neuen Connections v3 und Apps sind laut offizieller Doku experimentell: ohne Kompatibilitätsgarantie, mit einem frühen Katalog und noch unvollständigen Einrichtungsabläufen. Das Ziel eines fertigen One-click-App-Erlebnisses wird beschrieben – es ist nicht der vollständig gelieferte Ist-Zustand.

Ein Agent, n8n, Projektmanagement oder Paperclip?

Die vier Ansätze lösen unterschiedliche Hauptprobleme. Die folgende Matrix ist deshalb kein Ranking, sondern eine Wogenfels-Kategorisierung für die Vorentscheidung.

Ausgangslage	Passender Startpunkt	Was damit zuerst gelöst wird	Typische Grenze
Eine offene Aufgabe soll mit Werkzeugen bearbeitet werden	Ein einzelner KI-Agent	Die konkrete Arbeit ausführen	Rollen, Übergaben und Gesamtbudget mehrerer Agenten bleiben außerhalb
Ein Ablauf ist vorab klar beschreibbar	Typischer Startpunkt: Workflow-first, etwa n8n	Häufig zuerst gelöst: wiederholbare Schritte und definierte Übergaben	Offene Teilaufgaben brauchen bei Bedarf einen begrenzten Agentenschritt
Menschen und Teams brauchen Aufgabenübersicht	Typischer Startpunkt: bestehendes Projektmanagement	Häufig zuerst gelöst: Zuständigkeit, Termin und Status	Agentensteuerung und ihre Laufzeiten bleiben ein separates Architekturthema
Mehrere Agenten arbeiten mit Übergaben, Kosten und Freigaben	Paperclip-Pilot	Agenten als gemeinsames Betriebsmodell koordinieren	Zusätzliche Plattform, Sicherheitsfläche und Betriebsverantwortung

Paperclip ist daher nicht pauschal eine „n8n-Alternative“. n8n beginnt workflow-first bei einem definierten Kontrollgraphen; Paperclip beginnt bei einer Agentenorganisation. In vielen realen Architekturen können beide Ebenen nebeneinander sinnvoll sein: Ein Workflow übernimmt den festen Außenrahmen, Agenten bearbeiten eng begrenzte offene Schritte, und eine Control-Plane koordiniert mehrere solcher Agenten.

Wenn Sie noch klären, ob Ihr Prozess überhaupt einen Agenten benötigt, hilft zuerst der Beitrag „Hermes Agent oder n8n?“. Paperclip wird erst in der nächsten Komplexitätsstufe interessant.

Wogenfels-Einordnung nach dem jeweils zuerst zu lösenden Betriebsproblem; keine Rangliste und keine universelle Toolaussage.

Wo Paperclip echten Betriebsnutzen liefern kann

1. Eine gemeinsame Sicht auf mehrere Agenten

Sobald verschiedene Agenten recherchieren, entwickeln, prüfen oder Inhalte vorbereiten, entsteht Koordinationsarbeit. Wer arbeitet woran? Welche Aufgabe blockiert? Welcher Lauf gehört zu welchem Ergebnis? Paperclip verbindet laut den dokumentierten Kernkonzepten Agenten, Projekte, Aufgaben und Arbeitsläufe in einer gemeinsamen Struktur. Das kann verstreute Terminal-Sitzungen und Einzelprotokolle besser nachvollziehbar machen.

2. Zuständigkeiten statt eines allmächtigen Universalagenten

Das dokumentierte Organisationsmodell erlaubt getrennte Rollen und Berichtslinien. Das ist organisatorisch wertvoll, wenn Rechte und Aufgaben tatsächlich unterschiedlich zugeschnitten werden. Ein Rechercheagent braucht keine Buchungsrechte; ein Coding-Agent nicht automatisch Zugriff auf Kundendaten; ein Prüfer sollte nicht dieselben Änderungen ungeprüft selbst freigeben.

Die Hierarchie allein erzwingt diese Trennung jedoch nicht. Rollen im Organigramm müssen mit technischen Identitäten, minimalen Berechtigungen und getrennten Ausführungsumgebungen übereinstimmen.

3. Budgets sichtbar machen und Läufe stoppen

Paperclip dokumentiert Budgets auf Unternehmens- und Agentenebene. Dazu gehören Warnungen, ein Stopp beim Erreichen des Limits und ein Freigabeweg für Budgetüberschreitungen. Die Kostenansicht kann Nutzung nach Agent, Modell, Provider, Projekt oder Aufgabe aufschlüsseln.

Das ist nützlich – aber kein garantierter Deckel Ihrer Gesamtrechnung. Die Kosten-API kennt ausdrücklich noch nicht bepreiste Nutzung (unpriced). Anbieterrechnungen bleiben für die endgültige Abstimmung maßgeblich; Abonnementkosten können bis zur Abstimmung nur geschätzt sein. Hinzu kommen Hosting, Speicher, Tools, Sandboxes und interne Arbeitszeit.

Budgetstopp heißt: Paperclip stoppt anhand der von Paperclip erfassten Nutzung. Er heißt nicht: Kein externer Anbieter kann danach noch Kosten verrechnen.

4. Freigaben und Aktivität an einer Stelle

Die Freigabedokumentation nennt unter anderem Strategie- beziehungsweise Einstellungsentscheidungen, neue Agenten und Budget-Overrides. Plan- und Aufgabenreviews lassen sich ebenfalls abbilden. Der Activity-/Audit-Feed ordnet Ereignisse unter anderem Agenten, Runs und verantwortlichen Nutzern zu und kann als CSV exportiert werden.

Das verbessert Nachvollziehbarkeit. Es belegt aber weder kryptografische Unveränderbarkeit noch regulatorische Revisionssicherheit. Und es bedeutet nicht, dass jede externe Aktion automatisch vorab genehmigt wird.

Für Werkzeugaufrufe beschreibt Paperclip ein Tool Gateway, das Aktionen erlauben, blockieren, zur Freigabe vorlegen und protokollieren kann. Diese Oberfläche ist am Stichtag jedoch experimentell und standardmäßig deaktiviert. Die entscheidende Architekturregel lautet daher:

Governance wirkt nur dort zuverlässig, wo Identität, Berechtigung und Aktion tatsächlich durch den kontrollierten Pfad laufen.

Ein lokal gestarteter Agent mit direkten Betriebssystem- oder API-Rechten wird nicht allein durch ein schönes Organigramm sicher.

Architekturprinzip für einen kontrollierten Pilot: Externe Provider und Datenwege bleiben eigene Prüfpunkte.

Was Paperclip kostet – und warum es keine seriöse Einheitszahl gibt

Der Code steht laut Lizenzdatei unter MIT. Für eine selbst betriebene Installation fällt damit keine Paperclip-Open-Source-Lizenzgebühr an. „Kostenlos“ wäre trotzdem die falsche Schlussfolgerung.

Am 15. September 2026 bot die Website den lokalen Start und eine Cloud-Warteliste an. Eine belastbare öffentliche Cloud-Preisliste war in den geprüften offiziellen Seiten nicht auffindbar. Die in der Einführungsdokumentation genannten Dollarbereiche sind Beispiele für mögliche Modell- und Agentennutzung – keine Paperclip-Tarife und kein Angebot.

Für eine KMU-Kalkulation gehören mindestens sechs Kostenblöcke auf dasselbe Mengengerüst:

Kostenblock	Was Sie erfassen sollten
Einführung	Prozessdesign, Rollen, Integration, Tests, Migration und Schulung
Plattformbetrieb	Host, Datenbank, Speicher, Backups, Monitoring und Updates
Modelle	Tokens, Laufzeiten, unterschiedliche Provider und noch nicht bepreiste Nutzung
Agenten und Werkzeuge	Laufzeit-Abos, APIs, Browser, Sandboxes und weitere Dienste
Menschliche Arbeit	Freigaben, Qualitätsprüfung, Nacharbeit und Störungsbehandlung
Sicherheit und Compliance	Rechtekonzept, Isolation, Verträge, Dokumentation und regelmäßige Prüfung

Vergleichen Sie diese Summe mit dem heutigen Prozess und nicht mit null. Ein Pilot ist wirtschaftlich, wenn er bei vergleichbarer Qualität und vertretbarem Risiko mehr spart oder ermöglicht, als Einführung und Betrieb kosten. Ob das gelingt, ist eine Messfrage – keine Produkteigenschaft.

Self-hosted ist kontrollierbarer – aber nicht automatisch DSGVO-konform

Paperclip lässt sich selbst betreiben. Die Deployment-Dokumentation unterscheidet einen lokalen Vertrauensmodus für localhost ohne Login, einen authentisierten privaten Betrieb etwa im internen Netz oder über VPN und einen authentisierten öffentlichen Betrieb mit strengeren Prüfungen.

Für den schnellen lokalen Start verwendet Paperclip standardmäßig eingebettetes PostgreSQL und lokalen Dateispeicher. Für geteilte oder produktionsnahe Setups sind externe PostgreSQL- und S3-kompatible Speicheroptionen dokumentiert.

Das schafft Kontrolle über die Paperclip-Datenhaltung. Es beantwortet aber nur einen Teil des Datenwegs. Der Agent kann weiterhin ein entferntes Modell, eine Such-API, einen Browser, einen MCP-Server, ein Messaging-System oder ein anderes Werkzeug ansprechen. Daten können deshalb trotz lokaler Paperclip-Instanz an externe Empfänger fließen.

Für jede Variante – lokal, private Cloud oder Hosted Service – sollten Sie deshalb den gesamten Datenweg dokumentieren:

• Welche personenbezogenen oder vertraulichen Daten erreichen Paperclip?
• Welche Inhalte gehen an welches Haupt- oder Hilfsmodell?
• Welche Tools und verbundenen Konten können Daten lesen, verändern oder versenden?
• Wer ist Betreiber, Verantwortlicher und gegebenenfalls Auftragsverarbeiter?
• Welche Verträge, Speicherorte, Löschfristen und Schutzmaßnahmen gelten?
• Welche Telemetrie ist aktiv und wie wird sie deaktiviert oder begrenzt?
• Welche Protokolle sind für Nachweis und Fehlersuche nötig – und welche Inhalte gehören nicht hinein?

Auch die Telemetrie gehört in die Prüfung. Das README beschreibt standardmäßig aktive, abschaltbare OSS-Telemetrie. Sie soll laut Hersteller keine Prompts, Ticketinhalte, Dateipfade, Secrets oder personenbezogenen Daten enthalten. Diese Aussage ist eine Herstellerbeschreibung, kein unabhängiges Datenschutzaudit.

Für den gehosteten Dienst nennt die Privacy Policy Konto-, Nutzungs-, Telemetrie-, Geräte-/Technik- und Verbindungsdaten, eingesetzte Dienstleister und mögliche Verarbeitung beziehungsweise Transfers in die USA. Die Terms trennen den gehosteten Dienst vom MIT-Code und enthalten eine funktionsbezogene Lizenz an übermittelte Inhalte; detaillierte Opt-in-Telemetrie kann laut Bedingungen zur Verbesserung maschineller Lernsysteme verwendet werden.

In den am Stichtag untersuchten öffentlichen Primärquellen waren kein öffentlicher AVV/DPA, keine öffentliche Unterauftragsverarbeiterliste, keine feste EU-Datenresidenz-Zusage und kein SOC-2- oder ISO-Zertifikat auffindbar. Das beweist nicht, dass solche Unterlagen auf Anfrage fehlen. Es bedeutet: Vor einem Hosted-Pilot müssen sie konkret angefordert und geprüft werden.

Die allgemeinere Architekturentscheidung erklärt der Beitrag „Nur lokale KI ist DSGVO-konform?“.

Diese Einordnung ist allgemeine Orientierung und keine Rechtsberatung. Die konkrete Verarbeitung, Rollenverteilung, Rechtsgrundlage, Verträge und Schutzmaßnahmen sind im Einzelfall zu prüfen.

Die oft übersehene Sicherheitsfrage: Wo laufen die Agenten wirklich?

Die Dokumentation zu Ausführungsumgebungen sagt klar: Agentenläufe werden standardmäßig auf dem Paperclip-Host ausgeführt. Alternative Ziele über SSH oder Sandbox-Provider lassen sich zuweisen, gehören am Stichtag aber zu den experimentellen Funktionen.

„Experimentell“ bedeutet bei Paperclip nicht bloß eine kleine Beta-Markierung. Die offizielle Definition sagt: Opt-in, keine Kompatibilitätsgarantie, Änderungen oder Entfernung ohne Vorankündigung möglich und nicht für kritische Produktionsworkflows empfohlen.

Für ein KMU folgt daraus eine praktische Sicherheitsgrenze: Wer einem Agenten Terminal-, Datei-, Netzwerk- oder API-Rechte gibt, muss den möglichen Schaden bei einem Fehlzugriff – den „Blast Radius“ – so begrenzen, als könnte der Agent einen falschen oder manipulierten nächsten Schritt wählen. Minimale Rechte, getrennte technische Identitäten und eine geeignete Isolation sind wichtiger als der Rollenname im Dashboard.

Was die veröffentlichten Advisories sagen – und was nicht

Paperclip veröffentlicht eine Security Policy und Security Advisories. Zwei konkrete Advisories dokumentieren eine nicht authentisierte Remote-Code-Ausführung beziehungsweise eine OS-Command-Injection in Versionen vor 2026.416.0; als behobene Version wird jeweils 2026.416.0 genannt.

Das ist kein Beweis, dass die aktuelle Version unsicher ist. Eine aktuelle Versionsnummer ist umgekehrt kein Beweis für einen sicheren Betrieb. Die richtige Konsequenz ist nüchterner:

• eine unterstützte aktuelle Version festlegen und pinnen,
• Advisories und Release Notes beobachten,
• Updates zuerst in einer Testumgebung prüfen,
• Agentenrechte und Netzwerkwege minimal halten,
• Backup, Restore und Abschaltung tatsächlich testen,
• kritische Außenwirkung nicht einem unkontrollierten Agentenlauf überlassen.

Die schnelle Release-Folge und mehrere experimentelle Oberflächen sprechen für ein aktives, aber junges Produkt. Für kontrollierte Early-Adopter-Piloten kann das attraktiv sein. Für einen geschäftskritischen Standardbetrieb erhöht es den Prüf- und Wartungsbedarf.

Zugangsschlüssel: guter Ansatz mit einer wichtigen Lücke

Paperclip dokumentiert einen eingebauten Speicher für Zugangsschlüssel namens local_encrypted. Ein lokaler Hauptschlüssel schützt die gespeicherten Werte; Verweise darauf können in Agentenkonfigurationen eingebunden werden. Ein strikter Modus („Strict Mode“) weist bestimmte sensible Umgebungsvariablen zurück, wenn sie als Klartext statt als Schlüsselreferenz gespeichert werden.

Die gleiche Dokumentation nennt jedoch eine wichtige Ausnahme: config.llm.apiKey ist derzeit ein Klartextfeld und unterstützt keine secret_ref. Für durchgängige Secret-Hygiene empfiehlt die Doku, dieses Feld leer zu lassen und API-Schlüssel je Agentenadapter über Secret-Referenzen zu binden.

Bei externen Schlüsselspeichern ist AWS Secrets Manager heute aktiv beschrieben. GCP Secret Manager und HashiCorp Vault werden laut Doku nur als Entwurfsmetadaten gespeichert. Auch hier gilt: Ein sichtbarer Anbietername ist noch keine fertig nutzbare Integration.

Für einen Pilot sollte daher gelten:

• keine Zugangsschlüssel in Prompts, Tickets oder Protokollen,
• den strikten Schlüsselmodus außerhalb einer rein lokalen Testinstanz aktivieren,
• config.llm.apiKey leer lassen,
• Schlüssel pro Agent und Zweck trennen,
• Rotation und Entzug testen,
• Hostzugriff auf den Master Key begrenzen.

Der 9-Punkte-Pilotcheck für KMU

Paperclip sollte nicht mit „Wir bauen eine autonome Firma“ starten. Ein guter Pilot beantwortet neun engere Fragen:

1. Mehragentenbedarf: Gibt es mindestens zwei klar getrennte Agentenrollen und echte Übergaben – oder reicht ein Agent?
2. Begrenzter Prozess: Ist der Anwendungsfall messbar, reversibel und vor Außenwirkung menschlich prüfbar?
3. Datenweg: Sind Datenkategorien, Modelle, Tools, Empfänger, Speicherorte und Vertragsfragen dokumentiert?
4. Deployment: Ist bewusst entschieden, ob die Instanz lokal, privat authentisiert oder öffentlich betrieben wird?
5. Schadensradius: Sind Host, Dateien, Netzwerk, Systeme und technische Identitäten minimal berechtigt und passend isoliert?
6. Zugangsschlüssel: Werden Schlüssel referenziert, getrennt, rotiert und nicht im Klartextfeld config.llm.apiKey abgelegt?
7. Kostenabgleich: Werden Paperclip-Werte regelmäßig mit Providerrechnungen abgeglichen und externe Kosten separat begrenzt?
8. Freigaben: Ist für jede kritische Aktion klar, wer prüft – und läuft die Aktion technisch tatsächlich durch den kontrollierten Pfad?
9. Betrieb und Exit: Gibt es Versionspin, Patchprozess, Backup-/Restore-Test, Export und eine sichere Abschaltung?

Bewerten Sie jeden Punkt mit erfüllt, offen oder nicht relevant – begründet. Ein Pilot geht erst live, wenn kein sicherheits-, datenschutz- oder geschäftskritischer Punkt unbeantwortet bleibt.

Entscheidung in drei Minuten

Der 9-Punkte-Check enthält die vollständige Prüfung. Für die erste Auswahl reichen drei klare Signale je Richtung.

Paperclip ist einen Pilot wert, wenn …

• mehrere bereits getestete Agenten echte Rollen und Übergaben haben,
• Koordination, Blockaden oder Kosten heute nicht ausreichend sichtbar sind,
• technische Rechte, menschliche Freigaben und laufender Betrieb verantwortlich organisiert werden können.

Beginnen Sie einfacher, wenn …

• ein einzelner Agent oder ein vollständig beschreibbarer Ablauf genügt,
• vorhandenes Projektmanagement das eigentliche Koordinationsproblem bereits löst,
• produktive Zugriffe noch nicht minimal begrenzt werden können.

Stoppen Sie vor dem Livebetrieb, wenn …

• externe Aktionen am Freigabeweg vorbeilaufen oder der Datenweg unklar bleibt,
• Kostenwerte als garantierter Gesamtkostendeckel gelten oder breite Rechte ohne geeignete Isolation bestehen,
• niemand Updates, Vorfälle und eine sichere Abschaltung verantwortet.

Fazit: Erst Agenten beweisen, dann ihre „Firma“ bauen

Paperclip löst ein reales Problem: Mehrere KI-Agenten brauchen irgendwann mehr als getrennte Chats, Terminalfenster und lose Tickets. Rollen, Aufgaben, Budgets, Freigaben und Aktivitätsdaten in einer gemeinsamen Steuerungsebene können dann wertvoll werden.

Der Nutzen beginnt aber nicht mit der Installation. Er beginnt dort, wo mehrere Agenten bereits einen wirtschaftlich sinnvollen, eng begrenzten Prozess bearbeiten – und ihre Koordination messbar zur Belastung wird.

Für österreichische KMU ist Paperclip am Quellenstand 2026 deshalb vor allem ein Early-Adopter-Werkzeug für kontrollierte Piloten. Self-hosting, MIT-Lizenz und Governance-Funktionen sind starke Argumente. Experimentelle Integrationen, die Standardausführung auf dem Host, die schnelle Produktentwicklung und offene Hosted-Vertragsfragen verlangen zugleich erfahrenen Betrieb.

Die vernünftige Reihenfolge lautet:

1. einen begrenzten Agentenprozess fachlich und wirtschaftlich beweisen,
2. Daten-, Rechte- und Kostenweg dokumentieren,
3. erst bei echtem Mehragentenproblem Paperclip als Steuerungsebene testen,
4. kritische Außenwirkung bis zur belastbaren Abnahme menschlich und technisch begrenzen.

Wenn Sie einen solchen Pilot unabhängig von Produktmarketing zuschneiden möchten, können wir gemeinsam den Prozess, die Messgrößen und die Kontrollpunkte klären. Kontakt aufnehmen.

Quellen und weiterführende Primärdokumentation

Alle Quellen wurden am 15. September 2026 direkt geprüft. Am Stichtag war v2026.831.1, veröffentlicht am 2. September 2026, die jüngste stabile GitHub-Release in der geöffneten Release-Liste. Die sichtbare schnelle Release-Folge ist eine Momentaufnahme; volatile Angaben müssen vor einer Umsetzung erneut geprüft werden.

• Was ist Paperclip?
• Kernkonzepte und Organisationsmodell
• Offizielles GitHub-Repository und README
• MIT-Lizenz
• Adapterübersicht
• Deployment-Modi
• Kosten und Budgets
• Kosten-API und noch nicht bepreiste Nutzung
• Freigaben
• Tool Gateway
• Activity-/Audit-Feed
• Secrets
• Experimentelle Funktionen
• Connections v3 und Apps
• Privacy Policy
• Terms
• GitHub Releases
• Security Policy
• Security Advisories