Data, privacy & telemetry
What data goes where, which switches control it, and exactly what leaves your machine when someone sends feedback.
Start from the execution boundary. Build (Agent Dev) processes your workspace locally, and Wingman does not upload a general copy of your workspace to Axelera. What leaves your machine is each request the coding agent sends to its model, and the provider you pick decides where that request goes. With Axelera AI, the default provider, each request passes through our server to a model run by Anthropic, OpenAI, DeepSeek or Zhipu (Z.ai), depending on the model. Our server stores no conversation and keeps no whole request or answer. It records token counts, cost and request identifiers so the request can be billed, and its operational logs can hold short technical terms from answers, such as flag or variable names, for up to 60 days. Requests to OpenAI are sent with storage turned off; the other vendors apply their own retention terms. When a question needs Axelera knowledge, a cleaned copy of it also goes to our knowledge service and its embedding vendor (Voyage AI by default) to find matching passages. With Claude, ChatGPT, Gemini, Kimi or your own API key, the request goes from your machine straight to that vendor, under your agreement with them, with one exception: milestone verification. It is on by default and runs on every provider once the desktop app holds an Axelera endpoint key, which it fetches when you use the Axelera AI provider while signed in. After a turn, it sends your first prompt, your recent requests, the final answer and a short digest of the work (changed file names and command summaries) to our server, where a second model checks the work. Turn it off with the desktop setting wingman.agentDev.verification.enabled. The Wingman tools also send the agent’s knowledge-search queries to our knowledge service on every provider; the service uses each query to find passages and keeps none of them in a database. Chat conversations, agents, and team knowledge live in the hosted deployment, because that is what makes them shareable. Everything else on this page is about the narrow, explicit channels that cross that line: telemetry, analytics cookies, and feedback reports.
| Data | Where it lives | Who controls it |
|---|---|---|
| Chat topics, messages, agents | Hosted deployment (Supabase, Dublin) | Axelera AI B.V. as controller; access managed by you and your admins. Authorised Axelera staff can review stored chats in an audited console. With the metadata permission they see when each message was sent, the model and provider, the chat title (which is generated from the conversation), the agent title, and the account’s name and email. With the separate content permission they also see short previews, with known secret formats redacted, and can open one message at a time; every opened message is logged. Axelera employees have a chat review choice under Settings, Privacy: it starts off, which hides their titles and message content from this review, and turning it on allows review. Customers have no such switch, and their chats stay reviewable |
| Prompts and outputs sent to a model | Anthropic or OpenAI (United States). On the Axelera AI provider some requests go to DeepSeek or Zhipu (Z.ai), and knowledge lookups send a cleaned copy of the question to our embedding vendor (Voyage AI by default) | Transfers to Anthropic and OpenAI rely on the EU-US Data Privacy Framework or standard contractual clauses. DeepSeek, Zhipu and the embedding vendor are not yet named in the published recipient list, which is being updated with Legal |
| Team knowledge base | Hosted deployment | Knowledge access scopes and admins |
| Agent Dev files, terminals, device runs | Your machine | You |
| Build requests on the Axelera AI provider | Pass through the hosted service to the model. No conversation is stored and no whole request or answer is kept. A usage record keeps token counts, cost and request identifiers, and operational logs can hold short technical terms from answers for up to 60 days | Axelera AI B.V. as controller; pick another provider and requests go straight to that vendor, except milestone verification |
| Build milestone verification | On every provider once the desktop app holds an Axelera endpoint key: your first prompt, recent requests, the final answer and a work digest go to the hosted service, which handles them like a Build request on the Axelera AI provider | On by default; the desktop setting wingman.agentDev.verification.enabled turns it off |
| Knowledge searches from the Build Wingman tools | Sent to the hosted knowledge service on every provider and used to find passages; not kept in a database | Axelera AI B.V. as controller |
| Secrets and credentials | Settings / secure secret storage on device | You — never paste them into chat |
| Chat telemetry events | Hosted, only while the Chat telemetry switch is on | Axelera AI B.V. as controller; each user controls the switch |
| Build usage counts (prompts, commands, sessions, patches, errors, context size) | Hosted for 60 days, only while both telemetry switches are on. Each count carries your account, your email domain and a session id, and never prompt text | Axelera AI B.V. as controller; either the desktop setting wingman.telemetry.enabled or the Chat switch turns it off |
| MCP tool usage counts | Hosted, only while the Chat telemetry switch is on | Axelera AI B.V. as controller; counted on the server, so only the Chat switch turns it off |
| Feedback reports | Axelera’s private issue tracker | Sent only when a user submits one |
| Anonymous page-load counts | Hosted, as one integer per surface and per day, plus one per campaign code and per day, kept indefinitely | Nobody is identified in the count, so there is nothing to switch off: the visit records hold no cookie, identifier or address |
| Anonymous sign-in step counts | Hosted, as one integer per sign-in step and per day, kept indefinitely | Nobody is identified in the count: the step records hold no cookie, identifier, account or address |
Turn telemetry on or off
There are two switches. The Chat telemetry switch is a choice you make at onboarding: the first-run wizard has a dedicated step, existing sessions that never chose get a one-time notification, and you can change it any time under Settings, Privacy. It governs Chat product usage data, and it also governs whether the server records Build and MCP tool counts against your account, including the tool counts produced on the server, which no desktop setting can reach. The second switch, wingman.telemetry.enabled in the desktop app, works earlier in the chain: it stops both new collection of Build counts and the upload of anything already queued, so nothing leaves your machine in the first place. Either switch stops Build counts. Only the Chat switch stops MCP tool counts. The desktop setting is on by default. The onboarding step shows the Chat switch off, so if you continue without turning it on, Chat telemetry stays off. An account with no recorded choice counts as on until a choice is made.
Cookie consent in the browser
In the browser, the cookie consent banner is the equivalent switch for analytics. On first visit, hosted chat shows one banner with two buttons: Accept and Reject. Reject keeps non-essential analytics off, in a single click. The choice is stored in your browser’s local storage under axelera-cookie-consent, not on the server. Clearing site data resets the choice and the banner asks again.
The anonymous page-load count
Separately from analytics, every hosted surface counts how many times it was opened: the chat shell, the sign-in pages, the web dashboard, and the dashboard inside the desktop app each keep one running total per day. When a page loads, the browser sends the name of that surface. If the address you opened carries a campaign code in its ref parameter (up to 40 lowercase letters, digits and hyphens), as our campaign links and QR codes do, the browser also sends that code. A code from our own campaign list adds one to its own total for the day; any other code adds one to a single shared total for unrecognised codes, and its text is not kept. Nothing else is sent, and the request carries no cookies or sign-in credentials. No new cookie is set, no identifier is created, and the visit records hold neither your address nor your browser details, so the count cannot say who opened the page or whether two opens came from the same person. The request is handled like any other request to the service: it passes the usual rate limiter, which keeps only a scrambled form of the network address for a few minutes, and it appears in the standard operational logs described under retention. Because the count itself holds no personal data and nothing is stored on your device, it needs no consent, so it sits outside the cookie banner and outside both telemetry switches, and Reject does not change it. Unique visitors are not counted at all: the earlier visitor-cookie counter was retired for exactly this reason, and its historical figure is shown as frozen where it appears.
The anonymous sign-in count
The hosted sign-in counts its own steps the same way: one running total per step and per day, kept indefinitely. The steps are: we sent you to your identity provider, your identity provider sent you back, the sign-in finished, an account was created, and a sign-in failed after reaching your identity provider. The server adds one when a step happens, and your browser sends nothing for it. The step records hold the day, the step and the total, with no cookie, identifier, account, address or browser details, so the count cannot say who signed in or whether two steps came from the same person. So that a replayed sign-in link counts only once, the service keeps a scrambled form of the random value it made for that one sign-in attempt for ten minutes; it names no one and expires with the attempt. Administrators see these totals on the admin statistics page, next to the page-load counts and, for each sign-up day, the number of new accounts and how many of them sent a first prompt within a day and within a week. Those last figures come from the account and message records the service already keeps, and the page shows only totals.
What a feedback report contains
Feedback is the most detailed channel, so it is the most disclosed. When you send feedback from the desktop app, you choose the screenshot first: App window, Whole screen, or No screenshot. The Whole screen option warns you to close sensitive windows first, and before anything is sent you can Preview screenshot or choose Submit without screenshot. Chat may temporarily hide screenshot controls when attachments are unavailable; text and chosen diagnostics still submit normally. A report contains your message, an optional title, a screenshot only if the form offered one and you kept it, and — if diagnostics are enabled — app and extension versions, workspace counts, the active file path, and recent Wingman log lines.
Diagnostics and redaction
Diagnostics are controlled by one setting: wingman.feedback.includeDiagnostics, on by default. Turn it off and the diagnostics block is dropped. A smaller context block still travels with every report: your workspace folder names, the active file and its language, the app and platform versions, and a hashed machine identifier that is stable for the device. The log lines that diagnostics include are redacted before they leave the machine — known credential and token formats are automatically replaced with a redaction marker, and the buffer is capped so a report can never drag a full log file with it.
Retention and erasure
Reports are filed in Axelera’s private GitHub tracker without your name or email address. Any screenshot is stored separately on Axelera infrastructure, auto-deleted per the published retention period, and covered by erasure requests, which also break the screenshot link in the filed issue. The published retention periods are: prompts, outputs, sessions and files are kept for the life of your account and deleted or anonymised within 90 days of account deletion; prompts used for product improvement are kept no longer than 12 months; security, abuse-detection and operational logs are kept no longer than 60 days. To exercise any data protection right, contact legal@axelera.ai, and we respond within one month at the latest.