Privacy Policy

1. Who we are

Palgu is operated by Palgu, Inc., c/o Raie & co, 1875 S. Bascom Ave, Suite 2400, Campbell, CA, United States. For any privacy question or request, contact us via workhub.ai/contact.

2. Information we collect

We collect only what we need to operate the service:

• Account & organization data. Name, work email, role, and organization, supplied at sign-up, waitlist, or via your SSO provider. A waitlist sign-up also keeps what you tell us about your use case, team size and how you heard of us.
• Gateway metadata. For each request routed through Palgu we record the requested and served model, route reason, token counts, cost, latency, and status, scoped to your organization.
• Sign-in and device data. The IP address, user agent and approximate country of sign-in requests, and the name, operating system and app version of each device you sign in from. See “Sign-in and device records” in section 3.
• Provider credentials. API keys and OAuth tokens you connect, including project-tracker tokens and your own OAuth apps, stored encrypted at rest and used solely to reach the providers and trackers you configure. Palgu will not save them unless an encryption key is configured.
• Conversation content. Transcripts, session memory and, if you opt in, session history. See section 3.
• Other content you or your tools send us. Indexed documentation, skills, Palgu Assistant conversations, organization memory, risk-review findings, quality-gate output, web-research excerpts and crawled pages, imported agent instruction files, and questions asked through the assistant on our website. See section 3.

3. Prompt, conversation and other content

Palgu stores some of the content that passes through it. This section explains what is stored, how it is protected, how long it is kept, who can see it, and how to turn it off.

• Audit log. Every request gets an audit record containing the metadata in section 2, a SHA-256 hash of the prompt, and a session id: the one your client sends, or, when it sends none, an id derived one-way from a hash of the conversation's first message, so support can group a conversation's requests. The audit record does not contain prompt or response text.
• Session ids. The Palgu coding agent (in Palgu Studio and the CLI) sends its session id with each request, so that support can match a problem you report to the gateway's records. The gateway checks that it is a well-formed id and stores it in the audit record, scoped to your organization, and every gateway response carries a request id that is stored the same way. The agent keeps the last 20 request ids of each session in that session's file on your machine (~/.srooter/agent/sessions/). Neither id contains prompt or response text, and a session id is never used to grant access to anything.
• Conversation transcripts. Palgu records the messages your coding tools send through the gateway's Anthropic- and OpenAI-compatible endpoints so that sessions can be reviewed and failures diagnosed. On the Anthropic-compatible endpoint (used by Claude Code) it also records the model responses it relays. On the OpenAI-compatible endpoints it records the conversation history your tool sends with each request, which includes the earlier replies the tool sends back, but not a reply the tool never resends, such as the final reply of a session. Because tools include files and command output in their prompts, transcripts can contain source code and anything else a tool sends. Transcript capture is on by default for each organization. The review, council and MCP endpoints are separate capture sources that are off by default. They are recorded only if they are enabled for your organization, and Palgu does not currently offer a setting that enables them.
• Session handoff. When you continue a Claude Code or Codex session in Palgu (--continue-claude, or “Continue where it left off” in Palgu Studio), the coding agent reads that session's transcript on your machine and sends a brief built from it through the gateway: the goal (up to 1,500 characters), a summary (up to 4,000 characters), and recent commands, files and to-dos, with credentials redacted. The brief is then part of that session's requests and is recorded in transcripts like any other request.
• Outbound credential redaction. By default the gateway replaces recognisable credentials in requests to its Anthropic- and OpenAI-compatible endpoints (Anthropic, OpenAI, Stripe, GitHub, Slack, AWS and Google keys, srooter gateway keys, and private keys) with a marker such as [REDACTED:anthropic_key] before the request goes to the model provider. On the Anthropic-compatible endpoint this happens before anything else reads the request, so the routing classifier and council below also receive the redacted text; extended-thinking blocks a model returned are passed back unchanged, because the provider checks their signature. This is pattern matching, so a credential in a format it does not recognise can still be sent. The operator of a self-hosted gateway can turn it off, or also redact email addresses, card numbers and US social security numbers.
• Routing classifier. To choose a model for a request, the gateway sends the first 2,000 characters of the latest developer message (or of the first one, when the latest turn only carries tool results) to your organization's classifier model, on the managed service gemini-3.5-flash (Google). For requests that look like a high-craft build (a deck, a dashboard, a landing page) the same text and the list of matching skills go to that model to confirm the match. Recognised credentials in that text are replaced first (see Outbound credential redaction below); nothing else in it is redacted. The classifier call itself is not stored: the gateway keeps the resulting label in memory for repeated identical text and records only the route reason in the audit log (the request itself is recorded in transcripts as described above). Background calls Claude Code makes on its own (session titles and summaries, which contain conversation text) name retired Claude Haiku models; on the managed service they are served by gemini-3.7-flash (Google), unless your organization routes them elsewhere.
• Council reviews. When a request is classified as security or architecture work, or a session is stuck, the gateway may convene a council: up to 4,000 characters of the latest developer message are sent to five models from different providers (on the managed service Z.ai, DeepSeek, Google, Moonshot and OpenAI), at most once per organization and topic in a cooldown period. Their verdicts are kept in Organization memory (below).
• Risk review. When an agent's edits in an Anthropic-format request (for example from Claude Code) touch sensitive areas (for example authentication, credentials, permissions or database queries), the edits (file paths and new content, up to 6,000 characters) and the names of related code symbols are sent to risk models: on the managed service a first check on Groq, then Cerebras, then OpenAI for the cases that escalate. Their findings are kept as Risk-review findings (below). It is on by default; an organization can turn it off in its routing settings.
• Code review, board review and council deliberation. When you run a code review (srooterctl review, /review in a session, Reviews in Palgu Studio, CI, or the review_changes MCP tool), the diff of your branch and context from your organization's code graph are sent through the gateway to each council model. srooterctl review, /review and the review_changes MCP tool cap the diff at 120,000 characters, and srooterctl review never sends the secret files listed below. Reviews in Palgu Studio (of your working tree, or of a GitHub pull request link) send the whole diff, including uncommitted changes, with no length cap, plus the current source of up to 50 changed files (30 for a pull request), each up to 200,000 bytes; Studio does not exclude secret files. Depending on the review depth, the gateway passes the council models up to 120,000 characters of that changed-file source and up to 80,000 characters of related files a client sends with it. srooterctl quality --run code_review (and the Run button in Studio's Quality view) reviews your working tree: committed and uncommitted changes plus the full contents of up to 300 untracked files, within the same 120,000-character cap; it skips the same secret files, including .env.example. A board review (specs, plans or diffs from the coding agent's flow, or a question and answer from Studio's Explore view, up to about 120,000 characters) is split into parts that each board seat reads, and a lead model then reads the seats' answers. A council deliberation sends the question you type in Studio, with the last 3 questions and answers of that thread as context, to the council models; asking the council about a review finding also sends the finding's file, line and rationale. With the Python CLI srooter review --base (also used by the CI gate that review-init installs), each reviewer model can also read files from your checkout (up to 18,000 characters per file, including files that are not in the diff) and search it, and those results are sent with the diff. srooter review --base never reads or sends .env* files (.env, .env.*, including .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 and *.tfstate.*, kubeconfig, **/.kube/config, **/.aws/credentials, application_default_credentials.json, service-account*.json or *secret* files other than source code (a file such as secrets.py, credentials.py, src/secrets/index.ts or code under a kubeconfig/ directory is code to review; srooterctl review still withholds the *secret* ones), or anything inside a directory with such a name, nor git's own .git directory: they are left out of the file list, the diff, file reads and searches, and so is a file renamed or copied from one of them. This is the same list srooterctl review and srooterctl quality --run use. In srooter review --base and srooterctl review, recognisable keys and tokens pasted into other files (for example OpenAI, Anthropic, Stripe, GitHub, GitLab, Slack, AWS, Google, npm and Hugging Face keys, JWTs, private keys, passwords in URLs, and values assigned to names such as API_KEY or password) are replaced with a marker such as [REDACTED:aws_key len=20] in everything sent to the review models; if redaction fails, that content is withheld rather than sent. This is pattern matching, so a credential in a format it does not recognise can still be sent, and Reviews in Palgu Studio, board reviews and the review_changes MCP tool do not apply it; keep credentials in files like those listed here. An organization admin, and Palgu, can add patterns but not remove these; added patterns apply to srooter review --base only (srooterctl review uses the default list). The review_changes MCP tool sends whatever diff your harness gives it. Those srooter review --base calls use the OpenAI-compatible endpoint, so they are recorded in conversation transcripts while capture is on. On the managed service these models are from Z.ai, DeepSeek, Google, Moonshot and OpenAI, using your keys or ours. Board reviews are not a transcript capture source, so their text is not kept; review and council text is recorded only if review or council capture is enabled for your organization (see Conversation transcripts).
• Adversarial review. When you run an adversarial review of your quality findings (srooterctl quality --run adversarial, review --adversarial, or the Run button in Palgu Studio), each open finding is sent through the gateway with a few redacted lines of code around each finding (secret-looking files, and files with the same content as one, are never sent) to the refuter model your organization's routing chooses. It is a review call: it gets an audit record (metadata and a prompt hash) and, like the review endpoints above, its text is not kept in transcripts unless review capture is enabled. The quality ledger itself, the record of what was checked and what was found, is a file kept on your machine in your repository (.srooter/quality/), not on our servers.
• Session memory. For Anthropic-format requests (for example from Claude Code), Palgu keeps a short working record of each session: the opening request (up to 2,000 characters), the paths of files the session edited or wrote (through Edit, Write or NotebookEdit tool calls), and the text of tool errors. Today it is a record you can inspect: developers see their own sessions in the dashboard (Sessions, Memory tab) and in Palgu Studio, and admins see those of their organization, including through the dashboard's Cortex search. It can also hold three kinds of reference node: a change handoff, a decision (an ADR id) and an incident (a runbook or postmortem path). These hold ids and links only, not copied text; the content stays where it already lives. Its content is not currently added back into your agents' requests.
• Agent replies (voice). You can ask the coding agent to rewrite its replies in short, plain English or to translate them into your language. This is off by default and only runs for users who turn it on. When it is on, the agent sends the prose of its replies to the voice model chosen by your organization's routing settings (today a Google Gemini model). Before it sends anything, the agent redacts credentials it recognizes (API keys, tokens, passwords, email addresses); code, file paths, URLs, commands and numbers are never sent, and text that still looks sensitive is shown unchanged instead. If your organization's policy does not allow that model or its region, nothing is sent. These requests are recorded in transcripts like other requests and are billed like other requests.
• Ask mode. Questions you ask about your code in Palgu Studio's Explore view or with srooterctl ask, the file excerpts the assistant reads to answer them, and its answers travel through the gateway like any other request, so they are recorded in conversation transcripts as described above while capture is on. Secrets the assistant finds in files are masked before they are sent, but ordinary source code is not. Ask conversations are not kept in Studio's history or saved on your machine.
• Page inspection. To check a page instead of asking you about it, the coding agent can open your local development server in a headless browser on your machine (localhost only) and read the rendered page: its title, visible text, headings and buttons, layout measurements, console errors and failed requests, and a screenshot. Credentials it recognizes are redacted from the text first. That text is sent to the model your organization's routing chooses as part of the agent's request, so it is recorded in conversation transcripts as described above while capture is on. The screenshot is also sent to a model: to the agent's model as an image when that model accepts images, otherwise to your organization's validator model, which returns a written verdict that becomes part of the agent's request. A copy of the screenshot is saved as a temporary file on your machine and shown in Palgu Studio's task log. The browser uses a throwaway profile that is deleted when the browser closes. Your organization's admins can limit page inspection to text only (no screenshots) or turn it off with the agent.inspect_page setting, and a developer can do the same locally with SROOTER_INSPECT_PAGE. When the agent is told to check something itself instead of asking, it reports only which rule matched, never the question.
• Chat attachments. Files you paste, drop or upload into a chat (in Palgu Studio, the CLI or the dashboard assistant) are sent to the gateway, which checks their type, applies your organization's attachment settings and extracts what a model can read. Uploaded files, their manifests and any unredacted intermediate extraction output are held only in an ephemeral per-organization scratch on the gateway and are never written to the database or to backups. They expire after 15 minutes and are deleted by a clean-up that runs when attachments are next used, so they can remain on the gateway's disk longer than that. What leaves the gateway: extracted document text, images, video keyframes and PDF page images go to the provider of the model that serves the request; audio (including the sound track of a video) goes to the provider of your organization's transcription model; native video goes to the provider of your organization's video model. On the managed service, an image or video goes to gemini-3.8-flash (Google) when the model serving the request cannot read it, and no transcription model is configured, so audio files are refused and a video is read as keyframes without its sound track. Uploaded media is subject to each provider's own retention, which we list per provider (for example Gemini Files: up to 48 hours), and the gateway deletes an upload after the turn where the provider allows it. Secrets found in extracted text are redacted first. The conversation transcript keeps exactly what the model saw (the redacted, possibly shortened text, the images, keyframes and transcripts), like any other request: on by default, with a 30-day retention setting (see Retention below for how removal works today), encrypted only when SROOTER_SECRETS_KEY is set; otherwise it is not recorded, or, if the operator allows it, stored in plaintext. In Studio and the CLI the original file is copied into your project under .srooter/attachments/<task>/ for the life of the task, and the task log records its name, path, type and manifest id, never the file contents. Attachment previews are kept in memory only; files attached in web chat are not kept after the answer. An organization admin can turn attachments off or limit them to images.
• Parallel run overview. When the Palgu coding agent splits a task into parallel lanes, it keeps the run's events and state on your machine in your repository (.srooter/runs/), with the task name, item titles and step text. It also sends the gateway a copy of the run's state with ids and numbers only: run, phase, lane and item ids, states and reason codes, counts, token usage, cost, elapsed time and budgets, with no task names, item titles or step text. The gateway stores that copy with your organization and the session id the agent sends, so the Sessions page of the dashboard can show the run read-only (it cannot stop or change a run). You see the overview of your own runs, and organization admins see every run in the organization. Item ids come from your plan, so name plan items without secrets. The copy is kept with your organization's data until you ask us to delete it, and it is not encrypted by the application.
• Change handoff. When the Palgu coding agent completes a task that changed your code, it writes a short change handoff (what changed, how it works, the evidence, risks and open questions, plus the names of the architecture components the change added or touched) to the session folder on your machine, with credentials redacted. If transcript capture is on for your organization, the agent also sends that handoff to the gateway, which redacts it again and records it in your transcripts as part of a separate session, with the same retention and access as any other transcript; with capture off, or if redaction fails, nothing is sent or recorded. You can read it with srooter-agent handoff and in the Handoff panel of Palgu Studio. Beside it, on your machine only (file mode 0600), the agent keeps the explanation plan for your view: how much detail to show and why, worked out from your explanation profile. The plan is never sent with the handoff; the session's decision log records only its reason codes (the chosen detail and the explanation rules applied), never your familiarity.
• Session decision log. When the Palgu coding agent records what its framework and code review decided in a session (for example a review finding fixed, deferred or left as a todo), it keeps that log in the session file on your machine and sends the gateway a copy, with the session id it sends on every request. Each entry is rebuilt from a fixed set of fields: ids, decision and reason codes, severity and category, the evidence ids it rests on, the commit, test and file paths it changed (paths of files the agent changed, no line ranges), and notes of up to 200 characters with recognised credentials redacted. The copy also holds the repository URL (without credentials) so the dashboard can link a commit or file, and, for each evidence id, a summary of the review ledger record behind it (record and finding ids, a finding title of up to 160 characters, redacted the same way, evidence level, who produced the evidence and the commit it was checked at). There is no code, prompts or transcripts in it. When the agent later re-issues an entry, or folds entries past the 200-entry limit into a summary, the copy shows the new version and keeps the replaced entry's id and a SHA-256 digest of it (the last 1000), so a change is never silent. The Sessions page of the dashboard shows it in the Decisions tab. You see the log of your own sessions, and organization admins see every session in the organization; admin-only entries (review findings that are not yet verified) are withheld by the gateway from everyone else. The copy is kept with your organization's data until you ask us to delete it, and it is not encrypted by the application.
• Review calibration. To learn how reliable each code reviewer is (a review lens with its prompt version and model), the gateway keeps one row per review-finding event: ids, labels and numbers only, such as the trace and finding ids, the reviewer and model ids, the category, severity and outcome (for example verified, rejected or fixed), flags, latency and cost, and the user id of whoever recorded it (the API key's user or the signed-in admin). There is no code, no finding text and no prompt in these rows. It also keeps each reviewer's calibration state, a log of every promotion and demotion with the admin's user id, and your org's promotion thresholds with the user id of the admin who last changed them. Only your org admins can read the event rows, metrics and change log, on the calibration page of the dashboard. Any API key or member of your org can read the reviewer states, the enforced categories and the withdrawn finding ids (trace and finding ids only), because the coding agent uses them in its review and fix loop. Calibration never blocks a change on its own; it only decides whether a reviewer is trusted enough for your review policy.
• Session stage outcomes. When a Palgu Studio task finishes, Studio sends the gateway what its stage map shows, with the session id: whether a plan was produced and how many items it has, each stage's done and total counts, each check's pass or fail state, the task status and the project folder's name. It sends ids, states and numbers only, with no prompts, task names, item titles, file paths or step text. The gateway keeps the latest report per session with your organization's data until you ask us to delete it, and it is not encrypted by the application. Palgu support staff can look up a session's stage outcome, request metadata, run overview and transcript structure (not its text) to find out why something went wrong; every such lookup is recorded.
• Local agent sessions. The Palgu coding agent (in Palgu Studio and srooterctl) saves each conversation on your own device, under ~/.srooter/agent/sessions, so a task that pauses (for example when your laptop sleeps, shuts down or loses its network) can be resumed. These files contain your prompts and the model's responses. The files themselves are not uploaded (the requests in them went through the gateway as described above), and they are readable only by your user account (file mode 0600). Sessions that stay paused or interrupted for more than 30 days are removed when Palgu Studio starts and when you run srooterctl tasks --prune; other sessions stay until you delete them, and you can delete the folder at any time. Palgu Studio also keeps a log of each task's agent output (replies, tool calls and their output) under ~/.srooter/studio/tasks/ (readable only by your user account), and the prompts of up to 50 recent tasks in ~/.srooter/studio/tasks.json; a task's log is kept until you discard the task, including after its session file is pruned. The interactive agent keeps the prompts you type in ~/.srooter/history. None of these files is uploaded, and you can delete them at any time.
• Local parallel runs. When the Palgu coding agent runs a plan in parallel, it keeps the run in your project, under .srooter/runs/<run>/: the run's progress and spend, a journal of each finished step (ids, commit hashes and the step's inputs as a hash), and the plan it is running (step titles and acceptance criteria, readable only by your user account) so that a run stopped by a crash, a quit or a usage limit can be resumed. These files are not uploaded, and you can delete them at any time.
• Local project memory. So the Palgu coding agent does not ask the same question twice, it remembers a few things about your project in your repository, under .srooter/engine/memory/ (readable only by your user account, file mode 0600): facts it read from your configuration (for example which day your business week ends, with the file path and line it came from and a hash of that file, so a changed file is read again), accepted product policies (which option a signed-in person chose when the agent asked, with a link to that decision and a short one-way fingerprint of the API key that answered, never the key), and important open questions. It keeps ids, option numbers, file paths, line numbers and hashes only: never your task text, code or the text of an answer. Answers chosen automatically or typed as free text are not remembered. These files are not uploaded, and you can delete them at any time, or with srooter-agent assurance engine memory clear.
• Explanation profile. An optional record of how much the Palgu coding agent should explain to you, kept on your own device in ~/.srooter/agent/profile/ (readable only by your user account, file mode 0600). It has three opt-in steps. Your detail preference (guided, standard or compact, per topic) needs no opt-in and is stored only when you set it. Self-description, where you tell Palgu your familiarity with a topic (for example Python or Kafka), is off until you turn it on. Inference from your work in Palgu (tasks verified in Palgu, your answers to comprehension questions, review findings you fixed, your explanation choices) is a separate opt-in, also off by default; it never uses commit counts, chat outside Palgu, HR data, job titles or years of experience. Every change it makes is shown to you with its reason. Only you can see it: no organization admin, Palgu administrator or support path can read it, and it is never used to evaluate you: it is never used for performance reviews, rankings or any team view. You can view, edit, reset, export and delete it with srooterctl profile; turning inference off deletes what inference stored. Syncing it to the gateway, so it follows you across devices, is a further opt-in: the gateway refuses it unless SROOTER_SECRETS_KEY is configured, and stores it only encrypted. A synced copy is deleted at once when you delete your profile or turn sync off, when you are removed from your organization, and by the retention setting for this store (listed below). Palgu Studio (Settings › How Palgu explains) and, for a synced profile, your own web account page show it too; only you can open that page.
• Ownership evidence. For a significant change, the gateway keeps the change's ownership state (for example explained, reviewed, ownership shown, unresolved or stale), the architecture components it covers, its risk tier and references to the code, tests and decisions behind it. It never stores the text of your answers to comprehension questions. Your name and the verifier's verdict on your reasoning are linked to a record only if you opt in for that record; this opt-in is off by default. Your team sees ownership per change, never who answered or how; no organization admin or Palgu administrator API returns it per person, and it is never used for performance reviews, rankings or any evaluation of you, and never decides whether a change can merge, ship or deploy. When a later change touches those components, the state becomes stale. You can view your own records, challenge one, and delete your link and verdicts at once (/v1/me/ownership-evidence); your link is also removed when you leave your organization, and records are deleted by the retention setting for this store (listed below).
• Session history. An optional feature that tags sessions for follow-up. It is off by default and records nothing unless both your organization and the individual user turn it on. Keeping a text excerpt requires a further opt-in. At most 500 open items are kept per organization. Resolved items older than 30 days are removed the next time session history is read or written, not on a fixed schedule; open items are kept until resolved. To label a session as stuck or frustrated, the gateway can send content-free signals (turn number, error counts, whether the developer pushed back) to TypeSafe's classifier when a TypeSafe key is configured; with the text-excerpt opt-in it also sends the latest developer message, after credential and personal-data redaction, up to 600 characters. That excerpt is the one kept, as plain text.

Encryption. When an encryption key (SROOTER_SECRETS_KEY) is configured, transcript and session-memory content is encrypted by the application before it is written to the database, using Fernet (AES-128 in CBC mode with HMAC-SHA256 authentication). The managed service runs with this key set, and its startup log reports transcript content as encrypted. The key is managed by Palgu as the operator of the service; it is not a separate key per customer. Without the key, session memory is stored unencrypted, and transcripts are either not recorded or, if the operator explicitly allows it, stored unencrypted. In a self-hosted deployment you control this setting.

Retention. Transcripts, session memory and the other stores listed below are kept until deleted by default. Palgu can set an expiry in days for each store; the current setting for every store is listed under “Current retention settings” below. A store with an expiry is cleaned by a clean-up that runs every hour, so content can remain up to an hour past its expiry; a store without one is never cleaned. Separately, an organization that has saved its capture settings has a transcript retention setting of 30 days by default, which an organization admin can shorten to as little as 1 day (a longer period can only be set by Palgu, on request); the same hourly clean-up applies it. Removed content also remains in database backups until those backups expire. You can ask us to delete any of this content at any time.

Who can see it. Developers can read their own transcripts in the dashboard (Sessions, Transcript tab). Organization admins can read the transcripts of everyone in their organization. Transcripts are shown as written; they are not redacted. When an admin opens the text of someone else's transcript, the read is recorded in an access log, at most once per admin, session and hour; viewing a transcript's outline without its text is not logged. Admins can review that log through the admin API (GET /admin/ledger/access). Admins can also see session memory across their organization.

Turning it off. An organization admin can turn transcript capture off, or change the retention period, through the admin API (PUT /admin/ledger/config). The dashboard does not yet have a switch for this, so you can also ask us to change it for you. Turning capture off stops new recording; it does not delete what is already stored. Session memory cannot currently be turned off. In a self-hosted deployment all of this stays inside your own infrastructure (see section 5).

Other content we store. The following are stored as plain text in the database: they are not encrypted by the application, have no automatic expiry by default (Palgu can set one for some of them; see the current retention settings below), and are kept until you ask us to delete them unless noted.

• Indexed documentation. When you index a project into Cortex, the text of its documentation files is stored in sections, after AWS access keys and sk-/pk-/rk- style API keys are removed. Other secrets in those files are not removed. Re-indexing replaces it, and clearing the project's docs deletes it. Indexing uploads your source files to the gateway, which parses them in memory; the code graph itself keeps symbol names, file paths, dependencies and docstring-derived intent, not the contents of your source files. For each symbol and dependency it also keeps a provenance class (observed in the code, declared, historical, inferred or unknown) and its source references: file paths with line numbers and commit, ADR ids, test ids and configuration key names, never their values. When someone in your organization promotes an inferred fact to declared or historical, Palgu records the change with who confirmed it (their user id), when, the source reference and the source revision; that record is kept when the project is re-indexed and stays within your organization. Indexing also uploads the numbered architecture decision records under folders such as docs/ADRs and docs/adr; the gateway parses them in memory and keeps each record's id, status, date, file path and the records it supersedes, with links to the file paths and symbols it names, not its text. Each ingested record, proposed link and supersession is added to the same decision record; re-indexing replaces the parsed records and keeps that log. Each index of the merged branch also stores an architecture snapshot of the project: the systems, containers and components Palgu derived from its manifests, configuration files and folders (names, file paths, provenance and source references, never file contents), the commit it was built from and the files it could not place. The latest 20 snapshots per project are kept.
• Palgu Assistant conversations. The questions you ask the assistant in the dashboard (up to 8,000 characters each) and its answers, readable by members of your organization and by Palgu's own administrators for support and abuse review. To answer, the assistant sends the conversation, the most recent assistant questions and answers from your organization (up to 12 messages), and the results of the data tools it uses (which can include your organization's usage and cost per member by email address), to its fast model, on the managed service gemini-3.5-flash (Google), or to its deep model, glm-5.3 (Z.ai); in council mode the question also goes to the council models described above.
• Organization memory. Short notes Palgu keeps to improve routing: when a developer pushes back on an answer, up to 160 characters of their message; the text of provider errors a request ran into (up to 160 characters); and the verdicts from council reviews.
• Risk-review findings. Model-written descriptions of risky edits and the corrective note shown to the agent. These can quote code.
• Agent instruction files. The text of instruction files (such as CLAUDE.md or AGENTS.md) that you import into Palgu.
• Accepted risks. When an organization admin accepts a quality finding as a risk, the finding's identifier, its scope and the admin's stated reason (up to 500 characters) are kept in the audit trail, with who accepted it and when.
• Website assistant. If you use the assistant on our public website, the email address you enter, your question and the answer (questions up to 1,000 characters). Your IP address is stored as an unsalted SHA-256 hash, which can be matched back to the address, so we treat it as personal data. Questions are answered by gemini-3.5-flash (Google) on the managed service. Palgu's own administrators can read these conversations.
• Skills. The text of the skills your organization writes (names, tags and directives) is stored as plain text and added to the system prompt of matching requests. To search skills by meaning, the gateway sends skill text (up to 4,000 characters per skill, when a skill is saved) and each search query (up to 500 characters) to OpenAI's text-embedding-3-small model, using the platform's OpenAI key. The resulting embeddings are stored with a hash of the text they were computed from, not the text itself, with no automatic expiry. Search queries are not stored: their embeddings are cached in memory only. Without an OpenAI key, search matches keywords and nothing is sent.
• Organization standards. Coding standards your organization's admins write in Palgu (a title and directives for each), every version of them, and who proposed and approved each change are stored with no automatic expiry; past versions are kept. The directives are added to your agents' instructions, which the gateway serves to your coding tools, so the models that serve those requests receive them. They are not encrypted at rest.
• Web research. An optional step of spec writing that is off by default: it needs the feature turned on for the service and an organization admin's consent, which is recorded with who gave or withdrew it and when. When it runs, a research query (up to 500 characters) goes to Google Gemini with Google Search grounding, and the gateway then fetches up to five of the cited pages itself. Quoted excerpts of those pages (up to 1,200 characters each), with their URL and title, are stored and expire after 30 days.
• Assistant web tools. When they are configured, the dashboard assistant can crawl a web page or read text aloud. A crawl sends the page URL to Apify, which fetches the page; the page text (up to 40,000 characters) and the URL are stored with no automatic expiry by default, and the URL also appears in a dashboard notification. Reading aloud sends the text the assistant chose (up to 5,000 characters) to ElevenLabs; nothing from it is stored. If your organization adds its own Stripe key, the assistant can also look up an object in your organization's Stripe account by id (read-only); the Stripe object it returns is sent to the assistant's model and can appear in its stored answer. This lookup never uses Palgu's own Stripe account. An organization can use its own Apify or ElevenLabs key instead of ours; the Stripe lookup works only with the organization's own key. Keys an organization adds are stored encrypted.
• Quality gate results. When the coding agent runs your project's quality gates (tests, linters, type checks), it reports each gate's exit code and the last 4,000 characters of its output, which can include file paths, test names and code. The latest result per repository and gate is kept until it is replaced by a newer run.
• Project manifest confirmations. When someone in your organization confirms a field of a project's manifest (.palgu/manifest.yaml) or approves or revokes such a change, the gateway records the project name, the field name, a SHA-256 digest of the value (never the value itself), who asked or approved and their role, and when. These records have no automatic expiry.
• GitHub checks. If you install Palgu's GitHub App for CI, the gateway keeps, per repository, the run, pull request and commit identifiers it verified, the claims of the GitHub Actions token that requested the check (which include the GitHub username that triggered the run), and the text of the check results it publishes to your pull requests. These records have no automatic expiry.
• Sign-in and device records. For each sign-in request: the IP address, approximate country and user agent; for each device you sign in from: its name, operating system, architecture and app version, and the IP addresses it first and last connected from; and a sign-in event log with IP address and user agent. The same event log records deploy approvals (repository, commit, deploy platform account and project, deploy URL, the approver's email and their stated reason, up to 300 characters). Login codes are kept only as a hash and expire after 10 minutes. These records have no automatic expiry; a device is deleted when its user is removed from the organization. Sign-in rate-limit counters are keyed by the requesting IP address (an IPv6 address by its /64 prefix); a scheduled clean-up deletes them every 10 minutes once they are older than the configured period, which is 1 hour unless Palgu changes it (the current value is listed below).
• Synced preferences. Your Palgu app settings, synced between your devices (up to 32 KB; values that look like secrets are refused). They are deleted when you are removed from the organization.

4. How we use information

We use the data above to route and govern requests, enforce your organization's policies and budgets, produce audit and billing records, secure the service, and provide support. We do not sell your data and we do not use your prompts, responses, or code to train models.

5. Self-hosted deployments

When Palgu is self-hosted inside your own infrastructure (Enterprise mode), all gateway data, credentials, and audit logs remain within your environment. Palgu, Inc. does not receive your request metadata or credentials in that configuration.

6. Sharing & sub-processors

For the managed (cloud) service, the companies below process data on our behalf. Requests are sent to the AI provider of the model that serves them: the one your organization pins or configures, or the one Palgu's routing chooses, using either your own provider key or the platform's. Each provider handles that data under its own terms. Section 3 says which content goes to which provider for each feature. In a self-hosted deployment you choose the providers.

• Render (Frankfurt, Germany): hosting of the gateway and website, and the PostgreSQL database that holds everything stored in section 3.
• Cloudflare: an edge relay that forwards Claude Code and Codex traffic to the gateway, so Cloudflare processes each request's client IP address. Our relay code never logs request bodies. From relay version allowlist-v1, the relay writes one log line per request with the method, the path without its query string, the status, the duration and a short list of request headers (such as content type and user agent), never authorization, API-key or cookie headers, and Cloudflare's own invocation logs, which record every request header, are turned off. Earlier relay versions had those invocation logs on, so they recorded request metadata such as the URL, method, headers and the client IP address; those records stay with Cloudflare until its log retention removes them.
• AI model providers: Anthropic, OpenAI, Google (Gemini), DeepSeek, Z.ai (GLM), Moonshot (Kimi), xAI (Grok), Groq, Cerebras and MiniMax. They receive the requests they serve, and the internal calls in section 3: Google for routing classification, media, web research, voice and the assistants; OpenAI for skill-search embeddings and risk review; Groq and Cerebras for risk review; and the council members.
• TypeSafe: session-health labels for opted-in session history (section 3).
• Apify and ElevenLabs: the dashboard assistant's web-crawl and read-aloud tools, when configured (section 3).
• Resend: email delivery. It receives the recipient address and the message: login codes, team and waitlist invitations, new-device sign-in alerts (with the device name), low-balance notices and the welcome email.
• Stripe: payments. It receives your organization id, seat counts, amounts and usage totals; the card number and security code are entered on Stripe's own form and never reach Palgu; we keep only the card brand and last four digits that Stripe returns. The dashboard assistant's Stripe lookup tool reads only from an organization's own Stripe account, with that organization's key (section 3); it never reads Palgu's billing account.
• GitHub: the Palgu GitHub App for CI checks on repositories you connect, review comments posted to your pull requests when you ask for them, and, when bug reporting is enabled, bug reports (title, text and the email you give) filed as issues in Palgu's GitHub repository.
• Google Fonts: our website loads its fonts from Google's servers on every page, without a cookie choice, so Google receives your IP address and browser details.
• Google Analytics: usage analytics on our website, loaded only after you accept cookies, and never on the sign-in pages. You can withdraw that consent at any time: “Cookie settings” in the footer of every page reopens the choice. Your choice is stored only in your browser; we do not record it.

7. Data retention

Account and audit records are retained for the life of your account and any period required for legal, billing, or compliance purposes, after which they are deleted or anonymized. Conversation content has its own retention, described in section 3. You can request export or deletion of your organization's data at any time.

8. Security

Provider credentials are encrypted at rest, and conversation content is encrypted as described in section 3. Access is role-based, and all administrative access requires authentication. No method of transmission or storage is perfectly secure, but we take reasonable measures appropriate to the sensitivity of the data.

9. Your rights

Depending on your jurisdiction you may have rights to access, correct, export, or delete your personal data, and to object to or restrict certain processing. To exercise these rights, contact us at workhub.ai/contact.

10. Changes to this policy

We may update this policy from time to time. Material changes will be reflected by the “Last updated” date above and, where appropriate, communicated to account administrators.