Datenschutzerklärung

1. Wer wir sind

Palgu wird betrieben von Palgu, Inc., c/o Raie & co, 1875 S. Bascom Ave, Suite 2400, Campbell, CA, Vereinigte Staaten. Bei Fragen oder Anliegen zum Datenschutz kontaktieren Sie uns über workhub.ai/contact.

2. Welche Daten wir erheben

Wir erheben nur das, was wir für den Betrieb des Dienstes benötigen:

• Konto- & Organisationsdaten. Name, geschäftliche E-Mail-Adresse, Rolle und Organisation, die bei der Registrierung, auf der Warteliste oder über Ihren SSO-Anbieter angegeben werden. Bei einer Anmeldung zur Warteliste speichern wir außerdem Ihre Angaben zu Ihrem Anwendungsfall, Ihrer Teamgröße und wie Sie von uns erfahren haben.
• Gateway-Metadaten. Für jede über Palgu geleitete Anfrage erfassen wir das angeforderte und das bereitgestellte Modell, den Grund für das Routing, die Token-Anzahl, die Kosten, die Latenz und den Status, jeweils bezogen auf Ihre Organisation.
• Anmelde- und Gerätedaten. Die IP-Adresse, der User-Agent und das ungefähre Land von Anmeldeanfragen sowie der Name, das Betriebssystem und die App-Version jedes Geräts, von dem aus Sie sich anmelden. Siehe „Anmelde- und Geräteprotokolle“ in Abschnitt 3.
• Anbieter-Zugangsdaten. Von Ihnen verbundene API-Schlüssel und OAuth-Tokens, einschließlich Projekt-Tracker-Tokens und Ihrer eigenen OAuth-Apps, werden im Ruhezustand (at rest) verschlüsselt gespeichert und ausschließlich verwendet, um die von Ihnen konfigurierten Anbieter und Tracker zu erreichen. Palgu speichert sie nur, wenn ein Verschlüsselungsschlüssel konfiguriert ist.
• Gesprächsinhalte. Transkripte, Sitzungsspeicher und, sofern Sie dem zustimmen (Opt-in), Sitzungsverlauf. Siehe Abschnitt 3.
• Sonstige Inhalte, die Sie oder Ihre Tools an uns senden. Indizierte Dokumentation, Skills, Konversationen mit dem Palgu Assistant, Organisations-Memory, Ergebnisse der Risikoprüfung, Ausgaben von Quality-Gates, Auszüge aus Webrecherchen und gecrawlte Seiten, importierte Agent-Anweisungsdateien sowie Fragen, die über den Assistenten auf unserer Website gestellt werden. Siehe Abschnitt 3.

3. Prompts, Konversationen und sonstige Inhalte

Palgu speichert einen Teil der Inhalte, die das System durchlaufen. Dieser Abschnitt erläutert, was gespeichert wird, wie es geschützt wird, wie lange es aufbewahrt wird, wer es sehen kann und wie man es ausschaltet.

• Audit-Log. Jede Anfrage erhält einen Audit-Eintrag, der die Metadaten aus Abschnitt 2, einen SHA-256-Hash des Prompts und eine Sitzungs-ID enthält: entweder die von Ihrem Client gesendete oder, falls er keine sendet, eine ID, die per Einwegfunktion aus einem Hash der ersten Nachricht der Konversation abgeleitet wird, damit der Support die Anfragen einer Konversation gruppieren kann. Der Audit-Eintrag enthält keinen Prompt- oder Antworttext.
• Sitzungs-IDs. Der Palgu-Coding-Agent (in Palgu Studio und der CLI) sendet bei jeder Anfrage seine Sitzungs-ID mit, damit der Support ein von Ihnen gemeldetes Problem den Aufzeichnungen des Gateways zuordnen kann. Das Gateway prüft, ob es sich um eine wohlgeformte ID handelt, und speichert sie im Audit-Datensatz, begrenzt auf Ihre Organisation; jede Antwort des Gateways enthält eine Anfrage-ID, die auf dieselbe Weise gespeichert wird. Der Agent speichert die letzten 20 Anfrage-IDs jeder Sitzung in der Datei dieser Sitzung auf Ihrem Rechner (~/.srooter/agent/sessions/). Keine der beiden IDs enthält Prompt- oder Antworttext, und eine Sitzungs-ID wird niemals verwendet, um Zugriff auf irgendetwas zu gewähren.
• Gesprächstranskripte. Palgu zeichnet die Nachrichten auf, die Ihre Coding-Tools über die Anthropic- und OpenAI-kompatiblen Endpunkte des Gateways senden, damit Sitzungen überprüft und Fehler diagnostiziert werden können. Am Anthropic-kompatiblen Endpunkt (der von Claude Code genutzt wird) zeichnet es zudem die weitergeleiteten Modellantworten auf. An den OpenAI-kompatiblen Endpunkten zeichnet es den Gesprächsverlauf auf, den Ihr Tool mit jeder Anfrage mitsendet. Dieser enthält die früheren Antworten, die das Tool zurücksendet, jedoch keine Antwort, die das Tool nicht erneut sendet, wie etwa die letzte Antwort einer Sitzung. Da Tools Dateien und Befehlsausgaben in ihre Prompts einbinden, können Transkripte Quellcode und alles Weitere enthalten, was ein Tool sendet. Die Erfassung von Transkripten ist für jede Organisation standardmäßig aktiviert. Die Review-, Council- und MCP-Endpunkte sind separate Erfassungsquellen, die standardmäßig deaktiviert sind. Sie werden nur aufgezeichnet, wenn sie für Ihre Organisation aktiviert wurden, und Palgu bietet derzeit keine Einstellung an, um sie zu aktivieren.
• Sitzungsübergabe. Wenn Sie eine Sitzung von Claude Code oder Codex in Palgu fortsetzen (--continue-claude oder „Dort weitermachen, wo aufgehört wurde“ in Palgu Studio), liest der Coding-Agent das Transkript dieser Sitzung auf Ihrem Rechner und sendet über das Gateway eine daraus erstellte Kurzfassung: das Ziel (bis zu 1.500 Zeichen), eine Zusammenfassung (bis zu 4.000 Zeichen) sowie aktuelle Befehle, Dateien und offene Aufgaben, wobei Zugangsdaten geschwärzt werden. Die Kurzfassung ist anschließend Teil der Anfragen dieser Sitzung und wird wie jede andere Anfrage in den Transkripten aufgezeichnet.
• Schwärzung ausgehender Zugangsdaten. Standardmäßig ersetzt das Gateway erkennbare Zugangsdaten in Anfragen an seine Anthropic- und OpenAI-kompatiblen Endpunkte (Schlüssel von Anthropic, OpenAI, Stripe, GitHub, Slack, AWS und Google, srooter-Gateway-Schlüssel sowie private Schlüssel) durch eine Markierung wie [REDACTED:anthropic_key], bevor die Anfrage an den Modellanbieter gesendet wird. Am Anthropic-kompatiblen Endpunkt geschieht dies, bevor irgendeine andere Komponente die Anfrage liest, sodass der Routing-Klassifikator und das unten beschriebene Gremium ebenfalls den geschwärzten Text erhalten; von einem Modell zurückgegebene Extended-Thinking-Blöcke werden unverändert weitergeleitet, da der Anbieter deren Signatur prüft. Da dies auf Mustererkennung basiert, können Zugangsdaten in einem nicht erkannten Format dennoch gesendet werden. Der Betreiber eines selbst gehosteten Gateways kann diese Funktion deaktivieren oder zusätzlich E-Mail-Adressen, Kartennummern und US-Sozialversicherungsnummern schwärzen lassen.
• Routing-Klassifikator. Um ein Modell für eine Anfrage auszuwählen, sendet das Gateway die ersten 2.000 Zeichen der letzten Entwicklernachricht (oder der ersten, falls der letzte Durchgang nur Tool-Ergebnisse enthält) an das Klassifikatormodell Ihrer Organisation, beim verwalteten Dienst gemini-3.5-flash (Google). Bei Anfragen, die auf ein anspruchsvolles Build hindeuten (eine Präsentation, ein Dashboard, eine Landingpage), werden derselbe Text und die Liste passender Skills an dieses Modell gesendet, um die Übereinstimmung zu bestätigen. Erkannte Zugangsdaten in diesem Text werden zuvor ersetzt (siehe Schwärzung ausgehender Zugangsdaten unten); darüber hinaus wird nichts geschwärzt. Der Aufruf des Klassifikators selbst wird nicht gespeichert: Das Gateway behält das resultierende Label für wiederholten identischen Text im Arbeitsspeicher und zeichnet lediglich den Routing-Grund im Audit-Log auf (die Anfrage selbst wird wie oben beschrieben in den Transkripten erfasst). Hintergrundaufrufe, die Claude Code selbstständig durchführt (Sitzungstitel und Zusammenfassungen, die Konversationstext enthalten), verweisen auf eingestellte Claude-Haiku-Modelle; beim verwalteten Dienst werden sie von gemini-3.7-flash (Google) bedient, sofern Ihre Organisation sie nicht anderweitig weiterleitet.
• Council-Reviews. Wenn eine Anfrage als Sicherheits- oder Architekturarbeit eingestuft wird oder eine Sitzung feststeckt, kann das Gateway ein Council einberufen: Bis zu 4.000 Zeichen der letzten Entwicklernachricht werden an fünf Modelle verschiedener Anbieter gesendet (beim verwalteten Dienst Z.ai, DeepSeek, Google, Moonshot und OpenAI), höchstens einmal pro Organisation und Thema innerhalb einer Abklingzeit. Deren Urteile werden im Organisationsgedächtnis (siehe unten) gespeichert.
• Risikoprüfung. Wenn die Bearbeitungen eines Agenten in einer Anfrage im Anthropic-Format (zum Beispiel von Claude Code) sensible Bereiche betreffen (etwa Authentifizierung, Zugangsdaten, Berechtigungen oder Datenbankabfragen), werden die Bearbeitungen (Dateipfade und neue Inhalte, bis zu 6.000 Zeichen) sowie die Namen zugehöriger Code-Symbole an Risikomodelldienste gesendet: beim verwalteten Dienst erfolgt eine erste Prüfung über Groq, dann Cerebras und bei eskalierenden Fällen schließlich OpenAI. Deren Ergebnisse werden als Befunde der Risikoprüfung (siehe unten) gespeichert. Diese Funktion ist standardmäßig aktiviert; eine Organisation kann sie in ihren Routing-Einstellungen deaktivieren.
• Code-Review, Board-Review und Ratsberatung (Council Deliberation). Wenn Sie ein Code-Review ausführen (srooterctl review, /review in einer Sitzung, „Reviews“ in Palgu Studio, CI oder das MCP-Tool review_changes), werden der Diff Ihres Branches und der Kontext aus dem Code-Graphen Ihrer Organisation über das Gateway an jedes Ratsmodell gesendet. srooterctl review, /review und das MCP-Tool review_changes begrenzen den Diff auf 120.000 Zeichen, und srooterctl review sendet niemals die unten aufgeführten geheimen Dateien. Reviews in Palgu Studio (Ihres Arbeitsverzeichnisses oder eines GitHub-Pull-Request-Links) senden den gesamten Diff, einschließlich nicht committeter Änderungen, ohne Längenbegrenzung sowie den aktuellen Quellcode von bis zu 50 geänderten Dateien (30 bei einem Pull Request) mit jeweils bis zu 200.000 Byte; Studio schließt keine geheimen Dateien aus. Je nach Review-Tiefe leitet das Gateway bis zu 120.000 Zeichen dieses Quellcodes geänderter Dateien und bis zu 80.000 Zeichen zugehöriger Dateien, die ein Client mitschickt, an die Ratsmodelle weiter. srooterctl quality --run code_review (und die Schaltfläche „Run“ in der Ansicht „Quality“ von Studio) überprüft Ihr Arbeitsverzeichnis: committete und nicht committete Änderungen sowie den vollständigen Inhalt von bis zu 300 unversionierten Dateien innerhalb derselben Obergrenze von 120.000 Zeichen; dabei werden dieselben geheimen Dateien übersprungen, einschließlich .env.example. Ein Board-Review (Spezifikationen, Pläne oder Diffs aus dem Ablauf des Coding-Agenten oder eine Frage und Antwort aus der Ansicht „Explore“ in Studio, bis zu etwa 120.000 Zeichen) wird in Teile aufgeteilt, die jeder Sitz des Boards liest, woraufhin ein leitendes Modell die Antworten der Sitze liest. Eine Ratsberatung sendet die Frage, die Sie in Studio eingeben, zusammen mit den letzten 3 Fragen und Antworten dieses Threads als Kontext an die Ratsmodelle; wenn Sie den Rat zu einem Review-Befund befragen, werden außerdem Datei, Zeile und Begründung des Befunds gesendet. Mit der Python-CLI srooter review --base (die auch von dem durch review-init installierten CI-Gate verwendet wird) kann jedes Reviewer-Modell zudem Dateien aus Ihrem Checkout lesen (bis zu 18.000 Zeichen pro Datei, einschließlich Dateien, die nicht im Diff enthalten sind) und ihn durchsuchen, wobei diese Ergebnisse zusammen mit dem Diff gesendet werden. srooter review --base liest oder sendet niemals .env*-Dateien (.env, .env.*, einschließlich .env.example), *.env, *.pem, *.key, *.p12, *.pfx, *.keystore, id_rsa*, id_ed25519*, credentials, credentials.*, *.credentials, .netrc, .git-credentials, .npmrc, .pypirc, .pgpass, **/.docker/config.json, .envrc, *.jks, Terraform-*.tfvars, *.tfvars.json, *.tfstate und *.tfstate.*, kubeconfig, **/.kube/config, **/.aws/credentials, application_default_credentials.json, service-account*.json oder *secret*-Dateien, bei denen es sich nicht um Quellcode handelt (eine Datei wie secrets.py, credentials.py, src/secrets/index.ts oder Code unter einem Verzeichnis kubeconfig/ ist zu überprüfender Code; srooterctl review hält die *secret*-Dateien dennoch zurück), noch irgendetwas innerhalb eines Verzeichnisses mit einem solchen Namen oder das git-eigene Verzeichnis .git: Sie werden aus der Dateiliste, dem Diff, den Dateilesevorgängen und den Suchvorgängen ausgeschlossen, ebenso wie jede Datei, die aus einer solchen Datei umbenannt oder kopiert wurde. Dies ist dieselbe Liste, die auch srooterctl review und srooterctl quality --run verwenden. In srooter review --base und srooterctl review werden erkennbare Schlüssel und Token, die in andere Dateien eingefügt wurden (zum Beispiel Schlüssel von OpenAI, Anthropic, Stripe, GitHub, GitLab, Slack, AWS, Google, npm und Hugging Face, JWTs, private Schlüssel, Passwörter in URLs sowie Werte, die Namen wie API_KEY oder password zugewiesen sind), in allen an die Review-Modelle gesendeten Daten durch eine Markierung wie [REDACTED:aws_key len=20] ersetzt; schlägt die Schwärzung fehl, wird dieser Inhalt zurückgehalten statt gesendet. Da dies auf Mustererkennung (Pattern Matching) beruht, können Zugangsdaten in einem nicht erkannten Format dennoch gesendet werden, und „Reviews“ in Palgu Studio, Board-Reviews sowie das MCP-Tool review_changes wenden dieses Verfahren nicht an; bewahren Sie Zugangsdaten daher in Dateien wie den hier aufgeführten auf. Ein Organisationsadministrator sowie Palgu können Muster hinzufügen, diese jedoch nicht entfernen; hinzugefügte Muster gelten nur für srooter review --base (srooterctl review verwendet die Standardliste). Das MCP-Tool review_changes sendet den Diff, den Ihr Harness ihm übergibt. Diese Aufrufe von srooter review --base nutzen den OpenAI-kompatiblen Endpunkt und werden daher in Gesprächstranskripten aufgezeichnet, solange die Erfassung aktiviert ist. Beim Managed Service stammen diese Modelle von Z.ai, DeepSeek, Google, Moonshot und OpenAI, wobei Ihre oder unsere Schlüssel verwendet werden. Board-Reviews sind keine Quelle für die Transkripterfassung, sodass ihr Text nicht gespeichert wird; Review- und Ratstexte werden nur aufgezeichnet, wenn die Review- bzw. Ratserfassung für Ihre Organisation aktiviert ist (siehe „Gesprächstranskripte“).
• Adversarial Review. Wenn Sie ein Adversarial Review Ihrer Qualitätsbefunde durchführen (srooterctl quality --run adversarial, review --adversarial oder über die Schaltfläche „Run“ in Palgu Studio), wird jeder offene Befund mit einigen geschwärzten Codezeilen im Umfeld des Befunds (Dateien, die wie Geheimnisse aussehen, und Dateien mit demselben Inhalt werden niemals gesendet) über das Gateway an das widerlegende Modell gesendet, das durch das Routing Ihrer Organisation ausgewählt wird. Es handelt sich um einen Review-Aufruf: Er erhält einen Audit-Eintrag (Metadaten und einen Prompt-Hash), und wie bei den oben genannten Review-Endpunkten wird sein Text nicht in Transkripten gespeichert, es sei denn, die Review-Erfassung ist aktiviert. Das Qualitätsverzeichnis selbst, also das Protokoll darüber, was geprüft und was gefunden wurde, ist eine Datei, die auf Ihrem Rechner in Ihrem Repository (.srooter/quality/) und nicht auf unseren Servern gespeichert wird.
• Sitzungsspeicher. Für Anfragen im Anthropic-Format (beispielsweise von Claude Code) führt Palgu ein kurzes Arbeitsprotokoll jeder Sitzung: die Eröffnungsanfrage (bis zu 2.000 Zeichen), die Pfade der von der Sitzung bearbeiteten oder geschriebenen Dateien (über Tool-Aufrufe von Edit, Write oder NotebookEdit) sowie den Text von Tool-Fehlern. Derzeit dient dies als Protokoll zur Einsichtnahme: Entwickler sehen ihre eigenen Sitzungen im Dashboard (Sessions, Tab „Memory“) und in Palgu Studio, und Administratoren sehen die Sitzungen ihrer Organisation, auch über die Cortex-Suche im Dashboard. Es kann außerdem drei Arten von Referenzknoten enthalten: eine Änderungsübergabe (Change Handoff), eine Entscheidung (eine ADR-ID) und einen Vorfall (einen Runbook- oder Postmortem-Pfad). Diese speichern lediglich IDs und Links, keinen kopierten Text; der Inhalt verbleibt an seinem ursprünglichen Speicherort. Dieser Inhalt wird derzeit nicht wieder in die Anfragen Ihrer Agenten eingefügt.
• Agenten-Antworten (Sprachstil). Sie können den Coding-Agenten bitten, seine Antworten in kurzem, einfachem Englisch umzuschreiben oder in Ihre Sprache zu übersetzen. Diese Funktion ist standardmäßig deaktiviert und läuft nur für Benutzer, die sie einschalten. Wenn sie aktiviert ist, sendet der Agent den Fließtext seiner Antworten an das Sprachmodell, das durch die Routing-Einstellungen Ihrer Organisation ausgewählt wurde (derzeit ein Google-Gemini-Modell). Vor dem Senden schwärzt der Agent erkannte Zugangsdaten (API-Schlüssel, Tokens, Passwörter, E-Mail-Adressen); Code, Dateipfade, URLs, Befehle und Zahlen werden niemals gesendet, und Text, der weiterhin vertraulich aussieht, wird stattdessen unverändert angezeigt. Wenn die Richtlinie Ihrer Organisation dieses Modell oder dessen Region nicht zulässt, wird nichts gesendet. Diese Anfragen werden wie andere Anfragen in Transkripten protokolliert und wie andere Anfragen abgerechnet.
• Ask-Modus. Fragen, die Sie in der Explore-Ansicht von Palgu Studio oder mit srooterctl ask zu Ihrem Code stellen, die Dateiauszüge, die der Assistent zur Beantwortung liest, sowie seine Antworten laufen wie jede andere Anfrage über das Gateway. Sie werden daher wie oben beschrieben in Konversationstranskripten aufgezeichnet, solange die Erfassung aktiviert ist. Geheimnisse, die der Assistent in Dateien findet, werden vor dem Senden maskiert, gewöhnlicher Quellcode jedoch nicht. Ask-Konversationen werden weder im Verlauf von Studio noch auf Ihrem Rechner gespeichert.
• Seiteninspektion. Um eine Seite selbst zu prüfen, anstatt Sie danach zu fragen, kann der Coding-Agent Ihren lokalen Entwicklungsserver in einem Headless-Browser auf Ihrem Rechner (nur localhost) öffnen und die gerenderte Seite auslesen: Titel, sichtbaren Text, Überschriften und Schaltflächen, Layout-Abmessungen, Konsolenfehler und fehlgeschlagene Anfragen sowie einen Screenshot. Erkannte Zugangsdaten werden zuvor aus dem Text geschwärzt. Dieser Text wird als Teil der Anfrage des Agenten an das Modell gesendet, das vom Routing Ihrer Organisation ausgewählt wurde; solange die Aufzeichnung aktiviert ist, wird er daher wie oben beschrieben in den Konversationsprotokollen gespeichert. Der Screenshot wird ebenfalls an ein Modell gesendet: als Bild an das Modell des Agenten, sofern dieses Bilder akzeptiert, andernfalls an das Validierungsmodell Ihrer Organisation, das ein schriftliches Urteil zurückgibt, welches Teil der Anfrage des Agenten wird. Eine Kopie des Screenshots wird als temporäre Datei auf Ihrem Rechner gespeichert und im Aufgabenprotokoll von Palgu Studio angezeigt. Der Browser verwendet ein Einwegprofil, das beim Schließen des Browsers gelöscht wird. Die Administratoren Ihrer Organisation können die Seiteninspektion mit der Einstellung agent.inspect_page auf reinen Text (keine Screenshots) beschränken oder ganz deaktivieren; Entwickler können dies lokal mit SROOTER_INSPECT_PAGE ebenfalls tun. Wenn der Agent angewiesen wird, etwas selbst zu prüfen, anstatt zu fragen, meldet er lediglich, welche Regel zugetroffen hat, niemals jedoch die Frage selbst.
• Chat-Anhänge. Dateien, die Sie in einen Chat einfügen, hineinziehen oder hochladen (in Palgu Studio, der CLI oder dem Dashboard-Assistenten), werden an das Gateway gesendet. Dieses prüft den Dateityp, wendet die Anhangseinstellungen Ihrer Organisation an und extrahiert das, was ein Modell lesen kann. Hochgeladene Dateien, deren Manifeste sowie ungeschwärzte Zwischenergebnisse der Extraktion werden ausschließlich in einem flüchtigen, organisationsspezifischen Zwischenspeicher auf dem Gateway vorgehalten und niemals in die Datenbank oder in Backups geschrieben. Sie laufen nach 15 Minuten ab und werden durch eine Bereinigung gelöscht, die bei der nächsten Nutzung von Anhängen ausgeführt wird; daher können sie länger als diese Zeitspanne auf der Festplatte des Gateways verbleiben. Was das Gateway verlässt: Extrahierter Dokumenttext, Bilder, Video-Keyframes und Bilder von PDF-Seiten gehen an den Anbieter des Modells, das die Anfrage bearbeitet; Audio (einschließlich der Tonspur eines Videos) geht an den Anbieter des Transkriptionsmodells Ihrer Organisation; natives Video geht an den Anbieter des Videomodells Ihrer Organisation. Beim Managed Service wird ein Bild oder Video an gemini-3.8-flash (Google) gesendet, wenn das bearbeitende Modell es nicht lesen kann. Zudem ist dort kein Transkriptionsmodell konfiguriert, sodass Audiodateien abgelehnt und Videos als Keyframes ohne Tonspur gelesen werden. Hochgeladene Medien unterliegen den jeweiligen Aufbewahrungsfristen des Anbieters, die wir pro Anbieter auflisten (z. B. Gemini Files: bis zu 48 Stunden), und das Gateway löscht einen Upload nach dem Durchgang, sofern der Anbieter dies zulässt. Im extrahierten Text gefundene Geheimnisse (Secrets) werden vorab geschwärzt. Das Gesprächstranskript speichert genau das, was das Modell gesehen hat (den geschwärzten, gegebenenfalls gekürzten Text, die Bilder, Keyframes und Transkripte), genau wie bei jeder anderen Anfrage: standardmäßig aktiviert, mit einer Aufbewahrungseinstellung von 30 Tagen (siehe „Aufbewahrung“ weiter unten für Details zur aktuellen Funktionsweise der Löschung) und nur dann verschlüsselt, wenn SROOTER_SECRETS_KEY gesetzt ist; andernfalls wird es nicht aufgezeichnet oder, falls der Betreiber dies zulässt, im Klartext gespeichert. In Studio und der CLI wird die Originaldatei für die Dauer der Aufgabe in Ihr Projekt unter .srooter/attachments/<task>/ kopiert, und das Aufgabenprotokoll erfasst deren Namen, Pfad, Typ und Manifest-ID, niemals jedoch den Dateiinhalt. Anhangsvorschauen werden nur im Arbeitsspeicher gehalten; im Web-Chat angehängte Dateien werden nach der Antwort nicht aufbewahrt. Ein Organisationsadministrator kann Anhänge deaktivieren oder auf Bilder beschränken.
• Übersicht paralleler Durchläufe. Wenn der Palgu-Coding-Agent eine Aufgabe in parallele Spuren (Lanes) aufteilt, speichert er die Ereignisse und den Status des Durchlaufs auf Ihrem Rechner in Ihrem Repository (.srooter/runs/), einschließlich Aufgabenname, Elementtiteln und Schritttexten. Zudem sendet er dem Gateway eine Kopie des Durchlaufstatus, die ausschließlich IDs und Zahlen enthält: Durchlauf-, Phasen-, Spur- und Element-IDs, Statuswerte und Ursachencodes, Zähler, Token-Verbrauch, Kosten, verstrichene Zeit und Budgets, jedoch ohne Aufgabennamen, Elementtitel oder Schritttexte. Das Gateway speichert diese Kopie zusammen mit Ihrer Organisation und der vom Agenten gesendeten Sitzungs-ID, sodass die Seite „Sessions“ im Dashboard den Durchlauf schreibgeschützt anzeigen kann (sie kann einen Durchlauf weder stoppen noch ändern). Sie sehen die Übersicht Ihrer eigenen Durchläufe, und Organisationsadministratoren sehen jeden Durchlauf in der Organisation. Da Element-IDs aus Ihrem Plan stammen, sollten Sie Planelemente ohne Geheimnisse benennen. Die Kopie wird zusammen mit den Daten Ihrer Organisation aufbewahrt, bis Sie uns bitten, sie zu löschen, und wird von der Anwendung nicht verschlüsselt.
• Änderungsübergabe (Change Handoff). Wenn der Palgu-Coding-Agent eine Aufgabe abschließt, die Ihren Code geändert hat, schreibt er eine kurze Änderungsübergabe (was geändert wurde, wie es funktioniert, die Nachweise, Risiken und offenen Fragen sowie die Namen der Architekturkomponenten, die durch die Änderung hinzugefügt oder berührt wurden) mit geschwärzten Zugangsdaten in den Sitzungsordner auf Ihrem Rechner. Wenn die Transkripterfassung für Ihre Organisation aktiviert ist, sendet der Agent diese Übergabe auch an das Gateway, das sie erneut schwärzt und in Ihren Transkripten als Teil einer separaten Sitzung aufzeichnet, mit derselben Aufbewahrungsdauer und demselben Zugriff wie bei jedem anderen Transkript; ist die Erfassung deaktiviert oder schlägt die Schwärzung fehl, wird nichts gesendet oder aufgezeichnet. Sie können sie mit srooter-agent handoff und im Handoff-Bereich von Palgu Studio lesen. Daneben speichert der Agent ausschließlich auf Ihrem Rechner (Dateimodus 0600) den Erklärungsplan für Ihre Ansicht: wie viele Details warum angezeigt werden sollen, abgeleitet aus Ihrem Erklärungsprofil. Der Plan wird niemals mit der Übergabe gesendet; das Entscheidungsprotokoll der Sitzung zeichnet nur dessen Begründungscodes auf (den gewählten Detailgrad und die angewandten Erklärungsregeln), niemals Ihren Kenntnisstand.
• Sitzungs-Entscheidungsprotokoll. Wenn der Palgu-Coding-Agent aufzeichnet, was sein Framework und das Code-Review in einer Sitzung entschieden haben (zum Beispiel ein behobener, zurückgestellter oder als Aufgabe belassener Review-Befund), speichert er dieses Protokoll in der Sitzungsdatei auf Ihrem Rechner und sendet dem Gateway eine Kopie zusammen mit der Sitzungs-ID, die er bei jeder Anfrage mitschickt. Jeder Eintrag wird aus einem festen Satz von Feldern neu aufgebaut: IDs, Entscheidungs- und Begründungscodes, Schweregrad und Kategorie, die zugrunde liegenden Nachweis-IDs, der Commit, die geänderten Test- und Dateipfade (Pfade von Dateien, die der Agent geändert hat, ohne Zeilenbereiche) sowie Notizen von bis zu 200 Zeichen, in denen erkannte Zugangsdaten geschwärzt sind. Die Kopie enthält außerdem die Repository-URL (ohne Zugangsdaten), damit das Dashboard einen Commit oder eine Datei verlinken kann, und für jede Nachweis-ID eine Zusammenfassung des dahinterliegenden Eintrags im Review-Register (Eintrags- und Befund-IDs, ein Befundtitel von bis zu 160 Zeichen, auf dieselbe Weise geschwärzt, Nachweisstufe, wer den Nachweis erbracht hat, und der Commit, bei dem er geprüft wurde). Sie enthält keinen Code, keine Prompts und keine Transkripte. Wenn der Agent später einen Eintrag erneut ausstellt oder Einträge nach Überschreiten des Limits von 200 Einträgen zu einer Zusammenfassung zusammenführt, zeigt die Kopie die neue Version an und behält die ID des ersetzten Eintrags sowie einen SHA-256-Digest davon (die letzten 1000), sodass eine Änderung niemals unbemerkt bleibt. Auf der Seite „Sitzungen“ des Dashboards wird dies im Tab „Entscheidungen“ angezeigt. Sie sehen das Protokoll Ihrer eigenen Sitzungen, und Organisationsadministratoren sehen jede Sitzung in der Organisation; Einträge, die nur für Administratoren bestimmt sind (noch nicht verifizierte Review-Befunde), werden vom Gateway vor allen anderen zurückgehalten. Die Kopie wird zusammen mit den Daten Ihrer Organisation aufbewahrt, bis Sie uns bitten, sie zu löschen, und sie wird von der Anwendung nicht verschlüsselt.
• Review-Kalibrierung. Um zu ermitteln, wie zuverlässig jeder Code-Reviewer ist (eine Review-Linse mit ihrer Prompt-Version und ihrem Modell), speichert das Gateway pro Review-Befund-Ereignis genau eine Zeile: ausschließlich IDs, Labels und Zahlen, wie die Trace- und Befund-IDs, die Reviewer- und Modell-IDs, Kategorie, Schweregrad und Ergebnis (zum Beispiel verifiziert, abgelehnt oder behoben), Flags, Latenz und Kosten sowie die Benutzer-ID der Person, die es erfasst hat (der Benutzer des API-Schlüssels oder der angemeldete Administrator). Diese Zeilen enthalten keinen Code, keinen Befundtext und keinen Prompt. Zudem speichert das Gateway den Kalibrierungsstatus jedes Reviewers, ein Protokoll jeder Hoch- und Herabstufung mit der Benutzer-ID des Administrators sowie die Schwellenwerte Ihrer Organisation für Hochstufungen mit der Benutzer-ID des Administrators, der sie zuletzt geändert hat. Nur die Administratoren Ihrer Organisation können die Ereigniszeilen, Metriken und das Änderungsprotokoll auf der Kalibrierungsseite des Dashboards einsehen. Jeder API-Schlüssel oder jedes Mitglied Ihrer Organisation kann den Status der Reviewer, die durchgesetzten Kategorien und die zurückgezogenen Befund-IDs (nur Trace- und Befund-IDs) auslesen, da der Coding-Agent diese in seiner Review- und Korrekturschleife verwendet. Die Kalibrierung blockiert eine Änderung niemals von sich aus; sie entscheidet lediglich, ob ein Reviewer für Ihre Review-Richtlinie als vertrauenswürdig genug eingestuft wird.
• Phasenergebnisse von Sitzungen. Wenn eine Aufgabe in Palgu Studio abgeschlossen wird, sendet Studio dem Gateway zusammen mit der Sitzungs-ID das, was seine Phasenübersicht (Stage Map) anzeigt: ob ein Plan erstellt wurde und wie viele Punkte er umfasst, die Anzahl der erledigten und gesamten Schritte jeder Phase, den Erfolgs- oder Fehlerstatus jeder Prüfung, den Aufgabenstatus und den Namen des Projektordners. Es werden ausschließlich IDs, Statuswerte und Zahlen gesendet, ohne Prompts, Aufgabennamen, Elementtitel, Dateipfade oder Schritttexte. Das Gateway bewahrt den jeweils letzten Bericht pro Sitzung zusammen mit den Daten Ihrer Organisation auf, bis Sie uns zur Löschung auffordern; er wird nicht durch die Anwendung verschlüsselt. Mitarbeiter des Palgu-Supports können das Phasenergebnis einer Sitzung, Anfragemetadaten, die Ausführungsübersicht und die Transkriptstruktur (nicht jedoch deren Text) einsehen, um herauszufinden, warum ein Fehler aufgetreten ist; jeder solche Zugriff wird protokolliert.
• Lokale Agent-Sitzungen. Der Palgu-Coding-Agent (in Palgu Studio und srooterctl) speichert jede Konversation auf Ihrem eigenen Gerät unter ~/.srooter/agent/sessions, sodass eine pausierte Aufgabe (beispielsweise wenn Ihr Laptop in den Ruhezustand wechselt, herunterfährt oder die Netzwerkverbindung verliert) fortgesetzt werden kann. Diese Dateien enthalten Ihre Prompts und die Antworten des Modells. Die Dateien selbst werden nicht hochgeladen (die darin enthaltenen Anfragen liefen wie oben beschrieben über das Gateway) und sind nur für Ihr Benutzerkonto lesbar (Dateimodus 0600). Sitzungen, die länger als 30 Tage pausiert oder unterbrochen bleiben, werden beim Start von Palgu Studio und beim Ausführen von srooterctl tasks --prune entfernt; andere Sitzungen bleiben bestehen, bis Sie sie löschen, und Sie können den Ordner jederzeit löschen. Palgu Studio speichert außerdem ein Protokoll der Agent-Ausgaben jeder Aufgabe (Antworten, Tool-Aufrufe und deren Ausgaben) unter ~/.srooter/studio/tasks/ (nur für Ihr Benutzerkonto lesbar) sowie die Prompts von bis zu 50 aktuellen Aufgaben in ~/.srooter/studio/tasks.json; das Protokoll einer Aufgabe wird aufbewahrt, bis Sie die Aufgabe verwerfen, auch nachdem die zugehörige Sitzungsdatei bereinigt wurde. Der interaktive Agent speichert die von Ihnen eingegebenen Prompts in ~/.srooter/history. Keine dieser Dateien wird hochgeladen, und Sie können sie jederzeit löschen.
• Lokale parallele Ausführungen. Wenn der Palgu-Coding-Agent einen Plan parallel ausführt, speichert er den Lauf in Ihrem Projekt unter .srooter/runs/<run>/: den Fortschritt und die Ausgaben des Laufs, ein Journal jedes abgeschlossenen Schritts (IDs, Commit-Hashes und die Eingaben des Schritts als Hash) sowie den ausgeführten Plan (Schritttitel und Akzeptanzkriterien, nur für Ihr Benutzerkonto lesbar), damit ein durch einen Absturz, ein Beenden oder ein Nutzungslimit gestoppter Lauf fortgesetzt werden kann. Diese Dateien werden nicht hochgeladen, und Sie können sie jederzeit löschen.
• Lokales Projektgedächtnis. Damit der Palgu-Coding-Agent nicht zweimal dieselbe Frage stellt, merkt er sich einige Dinge über Ihr Projekt in Ihrem Repository unter .srooter/engine/memory/ (nur für Ihr Benutzerkonto lesbar, Dateimodus 0600): Fakten, die er aus Ihrer Konfiguration gelesen hat (zum Beispiel an welchem Tag Ihre Arbeitswoche endet, zusammen mit dem Dateipfad und der Zeile, aus der die Information stammt, sowie einem Hash dieser Datei, damit eine geänderte Datei erneut gelesen wird), akzeptierte Produktrichtlinien (welche Option eine angemeldete Person gewählt hat, als der Agent nachfragte, mit einem Link zu dieser Entscheidung und einem kurzen Einweg-Fingerabdruck des antwortenden API-Schlüssels, niemals dem Schlüssel selbst) sowie wichtige offene Fragen. Gespeichert werden ausschließlich IDs, Optionsnummern, Dateipfade, Zeilennummern und Hashes: niemals Ihr Aufgabentext, Ihr Code oder der Text einer Antwort. Automatisch gewählte oder als Freitext eingegebene Antworten werden nicht gespeichert. Diese Dateien werden nicht hochgeladen, und Sie können sie jederzeit manuell oder mit srooter-agent assurance engine memory clear löschen.
• Erklärungsprofil. Ein optionaler Datensatz darüber, wie ausführlich der Coding-Agent von Palgu Ihnen Dinge erklären soll; er wird auf Ihrem eigenen Gerät unter ~/.srooter/agent/profile/ gespeichert (nur für Ihr Benutzerkonto lesbar, Dateimodus 0600). Es gibt drei Opt-in-Stufen. Ihre Detailpräferenz (geführt, Standard oder kompakt, je Thema) erfordert kein Opt-in und wird nur gespeichert, wenn Sie sie festlegen. Die Selbstbeschreibung, bei der Sie Palgu Ihre Vertrautheit mit einem Thema mitteilen (zum Beispiel Python oder Kafka), ist deaktiviert, bis Sie sie einschalten. Die Ableitung aus Ihrer Arbeit in Palgu (in Palgu verifizierte Aufgaben, Ihre Antworten auf Verständnisfragen, von Ihnen behobene Review-Befunde, Ihre Erklärungsentscheidungen) ist ein separates Opt-in und ebenfalls standardmäßig deaktiviert; sie nutzt niemals Commit-Zahlen, Chats außerhalb von Palgu, HR-Daten, Berufsbezeichnungen oder Berufserfahrungsjahre. Jede vorgenommene Änderung wird Ihnen samt Begründung angezeigt. Nur Sie können das Profil einsehen: Kein Organisationsadministrator, Palgu-Administrator oder Support-Weg kann es lesen, und es wird niemals verwendet, um Sie zu bewerten: Es wird niemals für Leistungsbeurteilungen, Rankings oder irgendeine Teamansicht genutzt. Sie können es mit srooterctl profile ansehen, bearbeiten, zurücksetzen, exportieren und löschen; das Ausschalten der Ableitung löscht alles, was durch die Ableitung gespeichert wurde. Die Synchronisierung mit dem Gateway, damit das Profil Ihnen über Geräte hinweg folgt, ist ein weiteres Opt-in: Das Gateway lehnt sie ab, sofern nicht SROOTER_SECRETS_KEY konfiguriert ist, und speichert das Profil ausschließlich verschlüsselt. Eine synchronisierte Kopie wird sofort gelöscht, wenn Sie Ihr Profil löschen oder die Synchronisierung ausschalten, wenn Sie aus Ihrer Organisation entfernt werden sowie gemäß der Aufbewahrungseinstellung für diesen Speicher (unten aufgeführt). Palgu Studio (Settings › How Palgu explains) und, bei einem synchronisierten Profil, Ihre eigene Web-Kontoseite zeigen es ebenfalls an; nur Sie können diese Seite öffnen.
• Verantwortungsnachweise (Ownership Evidence). Bei einer wesentlichen Änderung speichert das Gateway den Verantwortungsstatus der Änderung (z. B. erklärt, geprüft, Verantwortung nachgewiesen, ungeklärt oder veraltet), die abgedeckten Architekturkomponenten, die Risikostufe sowie Verweise auf den zugrunde liegenden Code, die Tests und die Entscheidungen. Der Text Ihrer Antworten auf Verständnisfragen wird niemals gespeichert. Ihr Name und das Urteil des Prüfers über Ihre Begründung werden nur dann mit einem Datensatz verknüpft, wenn Sie für diesen Datensatz ausdrücklich zustimmen (Opt-in); dieses Opt-in ist standardmäßig deaktiviert. Ihr Team sieht die Verantwortung pro Änderung, jedoch niemals, wer wie geantwortet hat; keine API für Organisationsadministratoren oder Palgu-Administratoren gibt diese Daten personenbezogen zurück, sie werden niemals für Leistungsbeurteilungen, Rankings oder sonstige Bewertungen Ihrer Person verwendet und entscheiden niemals darüber, ob eine Änderung zusammengeführt (Merge), ausgeliefert oder per Deployment bereitgestellt werden kann. Wenn eine spätere Änderung diese Komponenten berührt, wird der Status als veraltet markiert. Sie können Ihre eigenen Datensätze einsehen, einen Datensatz anfechten und Ihre Verknüpfung sowie Urteile sofort löschen (/v1/me/ownership-evidence); Ihre Verknüpfung wird außerdem entfernt, wenn Sie Ihre Organisation verlassen, und Datensätze werden gemäß der Aufbewahrungseinstellung für diesen Speicher (unten aufgeführt) gelöscht.
• Sitzungsverlauf. Eine optionale Funktion, die Sitzungen für eine Nachverfolgung markiert. Sie ist standardmäßig deaktiviert und zeichnet nichts auf, es sei denn, sowohl Ihre Organisation als auch der einzelne Nutzer schalten sie ein. Das Speichern eines Textauszugs erfordert ein weiteres Opt-in. Pro Organisation werden höchstens 500 offene Einträge aufbewahrt. Erledigte Einträge, die älter als 30 Tage sind, werden beim nächsten Lesen oder Schreiben des Sitzungsverlaufs entfernt, nicht nach einem festen Zeitplan; offene Einträge werden bis zur Erledigung aufbewahrt. Um eine Sitzung als festgefahren oder frustriert einzustufen, kann das Gateway inhaltsfreie Signale (Rundennummer, Fehleranzahl, ob der Entwickler widersprochen hat) an den Klassifikator von TypeSafe senden, sofern ein TypeSafe-Schlüssel konfiguriert ist; mit dem Opt-in für Textauszüge sendet es außerdem die letzte Entwicklernachricht nach Schwärzung von Zugangs- und personenbezogenen Daten mit bis zu 600 Zeichen. Dieser Auszug wird als Klartext gespeichert.
• Verbindungen zu Projekt-Trackern. Wenn ein Organisationsadministrator einen Projekt-Tracker (Jira, Linear, Asana, GitHub Issues oder GitLab Issues) verbindet, speichert Palgu den Tracker, seine Adresse, die gewährten Berechtigungsumfänge (Scopes), wer ihn wann verbunden hat sowie die Zugriffs- und Aktualisierungs-Tokens (Access und Refresh Tokens), verschlüsselt mit SROOTER_SECRETS_KEY. Palgu speichert diese Daten nur, wenn ein Verschlüsselungsschlüssel konfiguriert ist. Bei einem persönlichen Zugriffs-Token (Personal Access Token) werden die letzten vier Zeichen gespeichert, damit Administratoren Tokens unterscheiden können; kein anderer Teil eines Tokens wird im Dashboard oder in der API angezeigt oder in Protokolle geschrieben. Eine Organisation, die ihre eigene OAuth-App verwendet, speichert die Client-ID und das Client-Secret dieser App auf dieselbe Weise verschlüsselt. Jedes Verbinden, Rotieren, Verwenden, erneute Autorisieren und Trennen wird ohne das Token protokolliert. Beim Trennen der Verbindung wird das Token beim Tracker widerrufen, sofern dieser dies unterstützt, und das gespeicherte Token gelöscht. Wenn ein Administrator Tracker-Webhooks aktiviert, wird das Signaturgeheimnis (Signing Secret) auf dieselbe Weise verschlüsselt und nur einmal angezeigt; der Inhalt (Body) eines Webhooks wird geprüft und anschließend verworfen. Palgu speichert lediglich den Ticketschlüssel, seinen Status und seine Revision sowie die Anzahl der akzeptierten und abgelehnten Zustellungen, niemals jedoch den Text des Tickets.
• Ticket-Verknüpfungen. Wenn eine Aufgabe oder Sitzung aus einem Ticket gestartet wird, erfasst Palgu, aus welchem Ticket sie stammt: ausschließlich Schlüssel und IDs (den Verbindungs-, Tracker-, Projekt- und Ticket-Schlüssel, die IDs von Aufgabe, Sitzung und Planelement, die von der Aufgabe geöffneten Pull-Request-Links, die von Palgu zuletzt gesehene Ticket-Revision und den Status sowie wer sie gestartet hat). Die Rücksynchronisierung und die pro Ticket aufgewendete Zeit lesen diese Daten aus. Der eigentliche Text des Tickets wird unten unter „Tickets in einer Aufgabe“ behandelt.
• Beiträge in Projekt-Trackern. Wenn Ihre Organisation Palgu erlaubt, in einen verbundenen Projekt-Tracker zu schreiben (standardmäßig deaktiviert, bis ein Organisationsadministrator Schreibzugriffe aktiviert), erhält jeder Schreibvorgang, jeder abgelehnte Schreibvorgang und jeder Konflikt einen Audit-Eintrag: Benutzer und Sitzung, Tracker, Ticket und Aktion, das Ergebnis sowie einen SHA-256-Hash und die Größe des Textes. Der Text wird vor der Veröffentlichung geschwärzt: Erkennbare Zugangsdaten, E-Mail-Adressen, interne Hostnamen und Dateipfade außerhalb des Repositorys werden entfernt; Code, Diffs und Transkripte werden niemals veröffentlicht. Dieser geschwärzte Text wird zusammen mit dem Eintrag 30 Tage lang verschlüsselt aufbewahrt, damit ein strittiger Beitrag überprüft werden kann, und anschließend gelöscht; Palgu bewahrt ihn nur auf, wenn ein Verschlüsselungsschlüssel konfiguriert ist. Die Audit-Einträge selbst können nicht bearbeitet werden: Jeder Eintrag ist über seinen Hash mit dem vorherigen verkettet.
• Plan-Export. Wenn ein Plan in einen Tracker exportiert wird, speichert Palgu, zu welchem Ticket jeder Plan-Meilenstein und jedes Planelement wurde: die IDs, den Ticket-Schlüssel und die Revision, die Spur-ID (Lane-ID) sowie einen SHA-256-Hash des Titels. Die veröffentlichten Titel, Akzeptanzkriterien und Spur-Labels befinden sich im Tracker, und jeder Beitrag wird wie oben beschrieben als Projekt-Tracker-Beitrag protokolliert.
• Tickets in einer Aufgabe. Wenn Sie eine Aufgabe aus einem Ticket starten (in Palgu Studio, mit srooterctl tickets oder --ticket oder mit srooter-agent plan from-ticket), liest das Gateway das Ticket über die Verbindung Ihrer Organisation aus Ihrem Tracker, prüft die Tracker-Richtlinie Ihrer Organisation und gibt Titel, Beschreibung, Akzeptanzkriterien, Labels und Links zurück. Der Coding-Agent fügt diesen Text den Anfragen der Aufgabe als nicht vertrauenswürdigen Kontext hinzu, der so markiert ist, dass er die Einstellungen der Aufgabe nicht ändern kann. Der Ticket-Text wird daher überall dort gespeichert, wo auch die Anfragen der Aufgabe liegen: in Gesprächstranskripten, solange die Aufzeichnung aktiviert ist, im Sitzungsspeicher, wenn er Teil der Eröffnungsanfrage ist (bis zu 2.000 Zeichen), und in den Sitzungsdateien des Agenten auf Ihrem Rechner (~/.srooter/agent/sessions), mit derselben Aufbewahrungsdauer und denselben Zugriffsrechten wie für den Rest der Aufgabe. Transkripte und Sitzungsspeicher werden verschlüsselt, wenn SROOTER_SECRETS_KEY gesetzt ist (siehe Verschlüsselung unten). Links in einem Ticket werden aufgelistet, niemals automatisch geöffnet, und Anhänge werden nicht heruntergeladen.

Verschlüsselung. Wenn ein Verschlüsselungsschlüssel (SROOTER_SECRETS_KEY) konfiguriert ist, werden Inhalte von Transkripten und des Sitzungsgedächtnisses von der Anwendung verschlüsselt, bevor sie in die Datenbank geschrieben werden; hierfür wird Fernet verwendet (AES-128 im CBC-Modus mit HMAC-SHA256-Authentifizierung). Der verwaltete Dienst läuft mit diesem gesetzten Schlüssel, und sein Startprotokoll meldet Transkriptinhalte als verschlüsselt. Der Schlüssel wird von Palgu als Betreiber des Dienstes verwaltet; es handelt sich nicht um einen separaten Schlüssel pro Kunde. Ohne den Schlüssel wird das Sitzungsgedächtnis unverschlüsselt gespeichert, und Transkripte werden entweder nicht aufgezeichnet oder, sofern der Betreiber dies ausdrücklich zulässt, unverschlüsselt gespeichert. In einem selbst gehosteten Deployment steuern Sie diese Einstellung selbst.

Aufbewahrung. Transkripte, Sitzungsspeicher und die anderen unten aufgeführten Speicher werden standardmäßig bis zu ihrer Löschung aufbewahrt. Palgu kann für jeden Speicher eine Ablaufzeit in Tagen festlegen; die aktuelle Einstellung für jeden Speicher ist unten unter „Aktuelle Aufbewahrungseinstellungen“ aufgeführt. Ein Speicher mit Ablaufzeit wird durch eine stündlich ausgeführte Bereinigung geleert, sodass Inhalte bis zu einer Stunde nach Ablauf ihrer Frist verbleiben können; ein Speicher ohne Ablaufzeit wird niemals automatisch bereinigt. Unabhängig davon gilt für eine Organisation, die ihre Erfassungseinstellungen gespeichert hat, standardmäßig eine Aufbewahrungsfrist für Transkripte von 30 Tagen, die ein Organisationsadministrator auf bis zu 1 Tag verkürzen kann (ein längerer Zeitraum kann nur von Palgu auf Anfrage eingestellt werden); dieselbe stündliche Bereinigung setzt diese Frist um. Entfernte Inhalte verbleiben zudem in Datenbanksicherungen (Backups), bis diese Sicherungen ablaufen. Sie können uns jederzeit bitten, diese Inhalte zu löschen.

Wer es sehen kann. Entwickler können ihre eigenen Transkripte im Dashboard lesen (Sessions, Tab „Transcript“). Organisationsadministratoren können die Transkripte aller Personen in ihrer Organisation lesen. Transkripte werden so angezeigt, wie sie geschrieben wurden; sie werden nicht geschwärzt. Wenn ein Administrator den Text des Transkripts einer anderen Person öffnet, wird dieser Lesevorgang in einem Zugriffsprotokoll erfasst, höchstens einmal pro Administrator, Sitzung und Stunde; das Anzeigen der Gliederung eines Transkripts ohne dessen Text wird nicht protokolliert. Administratoren können dieses Protokoll über die Admin-API (GET /admin/ledger/access) einsehen. Administratoren können außerdem den Sitzungsspeicher ihrer gesamten Organisation einsehen.

Ausschalten. Ein Organisationsadministrator kann die Transkriptaufzeichnung über die Admin-API (PUT /admin/ledger/config) ausschalten oder die Aufbewahrungsdauer ändern. Im Dashboard gibt es dafür noch keinen Schalter, Sie können uns also auch bitten, dies für Sie zu ändern. Das Ausschalten der Aufzeichnung beendet neue Aufzeichnungen; bereits Gespeichertes wird dadurch nicht gelöscht. Der Sitzungsspeicher kann derzeit nicht ausgeschaltet werden. Bei einem selbst gehosteten Deployment verbleibt all dies innerhalb Ihrer eigenen Infrastruktur (siehe Abschnitt 5).

Sonstige von uns gespeicherte Inhalte. Die folgenden Daten werden im Klartext in der Datenbank gespeichert: Sie werden von der Anwendung nicht verschlüsselt, haben standardmäßig kein automatisches Ablaufdatum (Palgu kann für einige davon eines festlegen; siehe die aktuellen Aufbewahrungseinstellungen unten) und werden, sofern nicht anders angegeben, so lange aufbewahrt, bis Sie uns bitten, sie zu löschen.

• Indexierte Dokumentation. Wenn Sie ein Projekt in Cortex indexieren, wird der Text der Dokumentationsdateien in Abschnitten gespeichert, nachdem AWS-Zugangsschlüssel sowie API-Schlüssel im Format sk-/pk-/rk- entfernt wurden. Andere Geheimnisse in diesen Dateien werden nicht entfernt. Eine Neuindexierung ersetzt diesen Text, und das Leeren der Projektdokumentation löscht ihn. Beim Indexieren werden Ihre Quelldateien an das Gateway hochgeladen, das sie im Arbeitsspeicher parst; der Code-Graph selbst speichert Symbolnamen, Dateipfade, Abhängigkeiten und die aus Docstrings abgeleitete Absicht, nicht jedoch den Inhalt Ihrer Quelldateien. Für jedes Symbol und jede Abhängigkeit speichert er zudem eine Herkunftsklasse (im Code beobachtet, deklariert, historisch, abgeleitet oder unbekannt) sowie die Quellreferenzen: Dateipfade mit Zeilennummern und Commit, ADR-IDs, Test-IDs und Namen von Konfigurationsschlüsseln, niemals jedoch deren Werte. Wenn jemand in Ihrer Organisation einen abgeleiteten Fakt zu „deklariert“ oder „historisch“ hochstuft, protokolliert Palgu die Änderung zusammen mit der Person, die sie bestätigt hat (deren Benutzer-ID), dem Zeitpunkt, der Quellreferenz und der Quellrevision; dieser Eintrag bleibt bei einer Neuindexierung des Projekts erhalten und verbleibt innerhalb Ihrer Organisation. Beim Indexieren werden auch die nummerierten Architecture Decision Records (ADRs) unter Ordnern wie docs/ADRs und docs/adr hochgeladen; das Gateway parst sie im Arbeitsspeicher und speichert von jedem Eintrag die ID, den Status, das Datum, den Dateipfad und die dadurch ersetzten Einträge sowie Verknüpfungen zu den darin genannten Dateipfaden und Symbolen, nicht jedoch den Text selbst. Jeder eingelesene Eintrag, jede vorgeschlagene Verknüpfung und jede Ersetzung wird demselben Entscheidungsprotokoll hinzugefügt; eine Neuindexierung ersetzt die geparsten Einträge und behält dieses Protokoll bei. Jede Indexierung des zusammengeführten Branches speichert außerdem einen Architektur-Snapshot des Projekts: die Systeme, Container und Komponenten, die Palgu aus den Manifesten, Konfigurationsdateien und Ordnern abgeleitet hat (Namen, Dateipfade, Herkunft und Quellreferenzen, niemals Dateiinhalte), den Commit, aus dem er erstellt wurde, sowie die Dateien, die nicht zugeordnet werden konnten. Pro Projekt werden die letzten 20 Snapshots aufbewahrt.
• Konversationen mit dem Palgu Assistant. Die Fragen, die Sie dem Assistenten im Dashboard stellen (jeweils bis zu 8.000 Zeichen), und dessen Antworten; diese sind für Mitglieder Ihrer Organisation sowie für Administratoren von Palgu zur Support- und Missbrauchsprüfung einsehbar. Um zu antworten, sendet der Assistent die Konversation, die letzten Fragen und Antworten des Assistenten aus Ihrer Organisation (bis zu 12 Nachrichten) sowie die Ergebnisse der von ihm genutzten Datentools (die auch die Nutzung und Kosten Ihrer Organisation pro Mitglied nach E-Mail-Adresse enthalten können) an sein schnelles Modell, im verwalteten Dienst gemini-3.5-flash (Google), oder an sein tiefgehendes Modell, glm-5.3 (Z.ai); im Gremiumsmodus (Council Mode) wird die Frage zusätzlich an die oben beschriebenen Gremiumsmodelle gesendet.
• Organisationsgedächtnis. Kurze Notizen, die Palgu speichert, um das Routing zu verbessern: wenn ein Entwickler einer Antwort widerspricht, bis zu 160 Zeichen seiner Nachricht; der Text von Anbieterfehlern, auf die eine Anfrage gestoßen ist (bis zu 160 Zeichen); sowie die Urteile aus Council-Reviews.
• Befunde der Risikoprüfung. Vom Modell verfasste Beschreibungen riskanter Bearbeitungen sowie der dem Agenten angezeigte Korrekturhinweis. Diese können Code zitieren.
• Agenten-Anweisungsdateien. Der Text von Anweisungsdateien (wie CLAUDE.md oder AGENTS.md), die Sie in Palgu importieren.
• Akzeptierte Risiken. Wenn ein Organisationsadministrator einen Qualitätsbefund als Risiko akzeptiert, werden die Kennung des Befunds, sein Geltungsbereich und die vom Administrator angegebene Begründung (bis zu 500 Zeichen) zusammen mit der Information, wer ihn wann akzeptiert hat, im Audit-Trail gespeichert.
• Website-Assistent. Wenn Sie den Assistenten auf unserer öffentlichen Website nutzen, werden die von Ihnen eingegebene E-Mail-Adresse, Ihre Frage und die Antwort gespeichert (Fragen bis zu 1.000 Zeichen). Ihre IP-Adresse wird als ungesalzener SHA-256-Hash gespeichert, der wieder der Adresse zugeordnet werden kann, weshalb wir ihn als personenbezogene Daten behandeln. Fragen werden im verwalteten Dienst von gemini-3.5-flash (Google) beantwortet. Die Administratoren von Palgu können diese Gespräche lesen.
• Skills. Der Text der Skills, die Ihre Organisation verfasst (Namen, Tags und Direktiven), wird als Klartext gespeichert und dem System-Prompt passender Anfragen hinzugefügt. Um Skills nach Bedeutung zu durchsuchen, sendet das Gateway den Skill-Text (bis zu 4.000 Zeichen pro Skill beim Speichern eines Skills) und jede Suchanfrage (bis zu 500 Zeichen) unter Verwendung des OpenAI-Schlüssels der Plattform an das Modell text-embedding-3-small von OpenAI. Die daraus resultierenden Embeddings werden zusammen mit einem Hash des Textes, aus dem sie berechnet wurden, gespeichert, nicht mit dem Text selbst, und haben kein automatisches Ablaufdatum. Suchanfragen werden nicht dauerhaft gespeichert: Ihre Embeddings werden lediglich im Arbeitsspeicher zwischengespeichert. Ohne einen OpenAI-Schlüssel gleicht die Suche Stichwörter ab und es wird nichts gesendet.
• Organisationsstandards. Coding-Standards, die die Administratoren Ihrer Organisation in Palgu verfassen (jeweils ein Titel und Anweisungen), jede Version davon sowie wer jede Änderung vorgeschlagen und genehmigt hat, werden ohne automatisches Ablaufdatum gespeichert; frühere Versionen bleiben erhalten. Die Anweisungen werden den Instruktionen Ihrer Agenten hinzugefügt, die das Gateway an Ihre Coding-Tools ausliefert, sodass die Modelle, die diese Anfragen bearbeiten, sie erhalten. Sie werden im Ruhezustand (at rest) nicht verschlüsselt.
• Web-Recherche. Ein optionaler Schritt beim Schreiben von Spezifikationen, der standardmäßig deaktiviert ist: Er erfordert, dass die Funktion für den Dienst aktiviert ist und die Zustimmung eines Organisationsadministrators vorliegt, wobei protokolliert wird, wer sie wann erteilt oder widerrufen hat. Bei der Ausführung wird eine Rechercheanfrage (bis zu 500 Zeichen) an Google Gemini mit Google-Search-Grounding gesendet, und das Gateway ruft anschließend selbst bis zu fünf der zitierten Seiten ab. Zitierte Auszüge dieser Seiten (jeweils bis zu 1.200 Zeichen) werden zusammen mit ihrer URL und ihrem Titel gespeichert und laufen nach 30 Tagen ab.
• Web-Tools des Assistenten. Wenn sie konfiguriert sind, kann der Dashboard-Assistent eine Webseite crawlen oder Text vorlesen. Beim Crawlen wird die Seiten-URL an Apify gesendet, das die Seite abruft; der Seitentext (bis zu 40.000 Zeichen) und die URL werden standardmäßig ohne automatisches Ablaufdatum gespeichert, und die URL erscheint zudem in einer Dashboard-Benachrichtigung. Beim Vorlesen wird der vom Assistenten ausgewählte Text (bis zu 5.000 Zeichen) an ElevenLabs gesendet; davon wird nichts gespeichert. Wenn Ihre Organisation ihren eigenen Stripe-Schlüssel hinzufügt, kann der Assistent auch ein Objekt im Stripe-Konto Ihrer Organisation anhand der ID nachschlagen (schreibgeschützt); das zurückgegebene Stripe-Objekt wird an das Modell des Assistenten gesendet und kann in dessen gespeicherter Antwort erscheinen. Diese Abfrage nutzt niemals das eigene Stripe-Konto von Palgu. Eine Organisation kann anstelle unseres Schlüssels ihren eigenen Apify- oder ElevenLabs-Schlüssel verwenden; die Stripe-Abfrage funktioniert nur mit dem eigenen Schlüssel der Organisation. Von einer Organisation hinzugefügte Schlüssel werden verschlüsselt gespeichert.
• Ergebnisse von Quality Gates. Wenn der Coding-Agent die Quality Gates Ihres Projekts (Tests, Linter, Typprüfungen) ausführt, meldet er den Exit-Code jedes Gates und die letzten 4.000 Zeichen seiner Ausgabe, die Dateipfade, Testnamen und Code enthalten können. Das jeweils neueste Ergebnis pro Repository und Gate wird aufbewahrt, bis es durch einen neueren Durchlauf ersetzt wird.
• Bestätigungen des Projektmanifests. Wenn jemand in Ihrer Organisation ein Feld des Manifests eines Projekts (.palgu/manifest.yaml) bestätigt oder eine solche Änderung genehmigt oder widerruft, protokolliert das Gateway den Projektnamen, den Feldnamen, einen SHA-256-Hashwert des Werts (niemals den Wert selbst), wer die Anfrage gestellt oder genehmigt hat, dessen Rolle sowie den Zeitpunkt. Diese Aufzeichnungen haben keine automatische Ablaufzeit.
• GitHub-Checks. Wenn Sie die GitHub App von Palgu für CI installieren, speichert das Gateway pro Repository die von ihm verifizierten Run-, Pull-Request- und Commit-Kennungen, die Claims des GitHub-Actions-Tokens, das den Check angefordert hat (wozu auch der GitHub-Benutzername gehört, der den Run ausgelöst hat), sowie den Text der Check-Ergebnisse, die es in Ihren Pull Requests veröffentlicht. Diese Aufzeichnungen haben kein automatisches Ablaufdatum.
• Anmelde- und Geräteprotokolle. Für jede Anmeldeanfrage: die IP-Adresse, das ungefähre Land und der User-Agent; für jedes Gerät, von dem aus Sie sich anmelden: dessen Name, Betriebssystem, Architektur und App-Version sowie die IP-Adressen der ersten und letzten Verbindung; außerdem ein Anmelde-Ereignisprotokoll mit IP-Adresse und User-Agent. Dasselbe Ereignisprotokoll erfasst Deployment-Freigaben (Repository, Commit, Konto und Projekt der Deployment-Plattform, Deployment-URL, E-Mail-Adresse des Freigebenden und dessen angegebene Begründung mit bis zu 300 Zeichen). Anmeldecodes werden nur als Hash gespeichert und verfallen nach 10 Minuten. Diese Protokolle haben kein automatisches Ablaufdatum; ein Gerät wird gelöscht, wenn sein Nutzer aus der Organisation entfernt wird. Rate-Limit-Zähler für Anmeldungen werden nach der anfragenden IP-Adresse geschlüsselt (bei einer IPv6-Adresse nach ihrem /64-Präfix); eine geplante Bereinigung löscht sie alle 10 Minuten, sobald sie älter als der konfigurierte Zeitraum sind, der 1 Stunde beträgt, sofern Palgu ihn nicht ändert (der aktuelle Wert ist unten aufgeführt).
• Synchronisierte Einstellungen. Ihre Palgu-App-Einstellungen, die zwischen Ihren Geräten synchronisiert werden (bis zu 32 KB; Werte, die wie Geheimnisse aussehen, werden abgelehnt). Sie werden gelöscht, wenn Sie aus der Organisation entfernt werden.

4. Wie wir Daten verwenden

Wir verwenden die oben genannten Daten für das Routing und die Steuerung von Anfragen, zur Durchsetzung der Richtlinien und Budgets Ihrer Organisation, zur Erstellung von Audit- und Abrechnungsunterlagen, zur Absicherung des Dienstes und zur Bereitstellung von Support. Wir verkaufen Ihre Daten nicht und verwenden Ihre Prompts, Antworten oder Ihren Code nicht zum Trainieren von Modellen.

5. Self-Hosted-Deployments

Wenn Palgu in Ihrer eigenen Infrastruktur selbst gehostet wird (Enterprise-Modus), verbleiben alle Gateway-Daten, Zugangsdaten und Audit-Logs in Ihrer Umgebung. Palgu, Inc. erhält in dieser Konfiguration weder Ihre Anfragemetadaten noch Ihre Zugangsdaten.

6. Weitergabe & Unterauftragsverarbeiter

Beim verwalteten Dienst (Cloud) verarbeiten die unten genannten Unternehmen Daten in unserem Auftrag. Anfragen werden an den KI-Anbieter des Modells gesendet, das sie bedient: entweder an denjenigen, den Ihre Organisation festlegt oder konfiguriert, oder an denjenigen, den das Routing von Palgu auswählt, wobei entweder Ihr eigener Anbieter-Schlüssel oder der der Plattform verwendet wird. Jeder Anbieter verarbeitet diese Daten gemäß seinen eigenen Bedingungen. In Abschnitt 3 ist aufgeführt, welche Inhalte für welche Funktion an welchen Anbieter gesendet werden. Bei einem selbst gehosteten Deployment wählen Sie die Anbieter selbst aus.

• Render (Frankfurt, Deutschland): Hosting des Gateways und der Website sowie der PostgreSQL-Datenbank, die alle in Abschnitt 3 genannten Daten enthält.
• Cloudflare: ein Edge-Relay, das den Datenverkehr von Claude Code und Codex an das Gateway weiterleitet, sodass Cloudflare bei jeder Anfrage die Client-IP-Adresse verarbeitet. Unser Relay-Code protokolliert niemals Anfrageinhalte (Request Bodies). Ab der Relay-Version allowlist-v1 schreibt das Relay pro Anfrage eine Protokollzeile mit der Methode, dem Pfad ohne Query-String, dem Status, der Dauer und einer kurzen Liste von Request-Headern (wie Content-Type und User-Agent), jedoch niemals Authorization-, API-Key- oder Cookie-Header. Zudem sind die Cloudflare-eigenen Aufrufprotokolle (Invocation Logs), die jeden Request-Header erfassen, deaktiviert. In früheren Relay-Versionen waren diese Aufrufprotokolle aktiviert, sodass Anfragemetadaten wie URL, Methode, Header und die Client-IP-Adresse aufgezeichnet wurden; diese Einträge verbleiben bei Cloudflare, bis sie im Rahmen der dortigen Protokollaufbewahrung gelöscht werden.
• KI-Modellanbieter: Anthropic, OpenAI, Google (Gemini), DeepSeek, Z.ai (GLM), Moonshot (Kimi), xAI (Grok), Groq, Cerebras und MiniMax. Sie erhalten die Anfragen, die sie verarbeiten, sowie die internen Aufrufe aus Abschnitt 3: Google für Routing-Klassifizierung, Medien, Web-Recherche, Sprachausgabe und die Assistenten; OpenAI für Skill-Such-Embeddings und Risikoprüfung; Groq und Cerebras für die Risikoprüfung; sowie die Mitglieder des Councils.
• TypeSafe: Labels zum Sitzungszustand für den Sitzungsverlauf nach Opt-in (Abschnitt 3).
• Apify und ElevenLabs: die Web-Crawling- und Vorlese-Tools des Dashboard-Assistenten, sofern konfiguriert (Abschnitt 3).
• Resend: E-Mail-Zustellung. Dieser Dienst erhält die Empfängeradresse und die Nachricht: Anmeldecodes, Team- und Wartelisteneinladungen, Warnmeldungen bei Anmeldungen über neue Geräte (mit dem Gerätenamen), Benachrichtigungen über niedriges Guthaben sowie die Willkommens-E-Mail.
• Stripe: Zahlungen. Es erhält Ihre Organisations-ID, die Anzahl der Lizenzen (Seats), Beträge und Nutzungssummen; die Kartennummer und der Sicherheitscode werden direkt im Formular von Stripe eingegeben und erreichen Palgu niemals; wir speichern lediglich die Kartenmarke und die letzten vier Ziffern, die Stripe zurückgibt. Das Stripe-Abfragetool des Dashboard-Assistenten liest ausschließlich aus dem eigenen Stripe-Konto einer Organisation unter Verwendung des Schlüssels dieser Organisation (Abschnitt 3); es liest niemals das Abrechnungskonto von Palgu.
• GitHub: die Palgu GitHub App für CI-Checks auf von Ihnen verbundenen Repositories, Review-Kommentare, die auf Ihre Anforderung hin in Ihren Pull Requests veröffentlicht werden, und, sofern die Fehlermeldung aktiviert ist, Fehlerberichte (Titel, Text und die von Ihnen angegebene E-Mail-Adresse), die als Issues im GitHub-Repository von Palgu angelegt werden.
• Google Fonts: Unsere Website lädt ihre Schriftarten auf jeder Seite ohne Cookie-Auswahl von den Servern von Google, sodass Google Ihre IP-Adresse und Browserdaten erhält.
• Google Analytics: Nutzungsanalyse auf unserer Website, die erst geladen wird, nachdem Sie Cookies akzeptiert haben, und niemals auf den Anmeldeseiten. Sie können diese Einwilligung jederzeit widerrufen: Über „Cookie-Einstellungen“ in der Fußzeile jeder Seite lässt sich die Auswahl erneut öffnen. Ihre Auswahl wird ausschließlich in Ihrem Browser gespeichert; wir zeichnen sie nicht auf.

Projekt-Tracker sind keine Unterauftragsverarbeiter. GitHub Issues, Jira Cloud, Jira Data Center, Linear, Asana und GitLab Issues sind Ziele, die Ihre Organisation verbindet und auswählt; sie verarbeiten die empfangenen Daten gemäß der eigenen Vereinbarung Ihrer Organisation mit ihnen. Palgu liest Tickets über die Verbindung Ihrer Organisation und sendet einem Tracker nur das, was Ihre Organisation in ihrer Tracker-Richtlinie aktiviert hat: nichts, bis ein Administrator Schreibzugriffe aktiviert, danach Kommentare, Statusänderungen, erfasste Zeit und exportierte Planelemente, geschwärzt wie unter „Beiträge in Projekt-Trackern“ in Abschnitt 3 beschrieben. Code, Diffs und Transkripte werden niemals veröffentlicht. Bei einem selbst gehosteten Deployment ruft das Gateway die Tracker aus Ihrer Infrastruktur heraus auf.

7. Datenspeicherung

Konto- und Audit-Aufzeichnungen werden für die gesamte Lebensdauer Ihres Kontos sowie für jeden Zeitraum aufbewahrt, der für rechtliche, Abrechnungs- oder Compliance-Zwecke erforderlich ist; danach werden sie gelöscht oder anonymisiert. Gesprächsinhalte haben eine eigene Aufbewahrungsdauer, die in Abschnitt 3 beschrieben wird. Sie können jederzeit den Export oder die Löschung der Daten Ihrer Organisation anfordern.

8. Sicherheit

Anbieter-Zugangsdaten werden im Ruhezustand verschlüsselt, und Gesprächsinhalte werden wie in Abschnitt 3 beschrieben verschlüsselt. Der Zugriff ist rollenbasiert, und jeder administrative Zugriff erfordert eine Authentifizierung. Keine Übertragungs- oder Speichermethode ist vollkommen sicher, aber wir ergreifen angemessene Maßnahmen, die der Sensibilität der Daten entsprechen.

9. Ihre Rechte

Je nach Ihrer Rechtsordnung haben Sie möglicherweise das Recht, auf Ihre personenbezogenen Daten zuzugreifen, sie zu berichtigen, zu exportieren oder zu löschen sowie einer bestimmten Verarbeitung zu widersprechen oder diese einzuschränken. Um diese Rechte auszuüben, kontaktieren Sie uns unter workhub.ai/contact.

10. Änderungen dieser Richtlinie

Wir können diese Richtlinie von Zeit zu Zeit aktualisieren. Wesentliche Änderungen werden durch das Datum unter „Zuletzt aktualisiert“ oben ausgewiesen und gegebenenfalls an Kontoadministratoren kommuniziert.