Privacy Policy

This policy explains how the current WingGate implementation handles your data. We deliberately distinguish behavior that is implemented today from parts that depend on the operator, and we make no promises beyond the implementation. This policy is updated as the implementation evolves; the deployed version is authoritative.

WingGate is currently delivered as self-hosted software: the WingGate service and its storage run in an environment controlled by you or your team. In this document, “the service operator” means whoever deploys and runs that service.

What data we process

WingGate processes two categories of data: your account identity data, and the operational data inside your Organization.

Account and identity data

Registration and login involve: your username and email address, a hash of your password (plaintext passwords are never stored), MFA factors (a TOTP authenticator or passkey/WebAuthn credentials) and one-time recovery codes, and — if you choose to bind one — the identity returned by an external OAuth identity provider. This data is used only to authenticate you.

Organization data

Within an Organization, the system stores: Assets (target host addresses and metadata), Connection Profiles (how to connect to an asset; secret fields are write-only), Projects and Project access grants (authorization relationships), Session lifecycle records, and Audit entries. Visibility of this data is strictly limited by the corresponding Organization and Project authorization scopes.

Data we do not collect today

The current implementation includes no statistics or usage-analytics service, does not track page behavior, and reports no telemetry to third-party analytics platforms.

Asset credentials and the connector boundary

Credentials used to reach target assets (SSH keys, passwords) are stored in the asset's Connection Profile or in a separate credential record the asset references, fully isolated from your login credentials. Those secret fields are write-only under the regular APIs: list and detail responses never return secret contents.

The wing-connector is deployed in your own network, next to the target machines, and uses these credentials to connect to the target SSH hosts or file backends. The connector connects to WingGate over an outbound-only mTLS channel; target assets need no inbound exposure.

When you connect with your own SSH client, you authenticate to WingGate's SSH endpoint with your public key; WingGate never holds your SSH private key. A compromise of either credential class (login or asset) does not by itself expose the other.

Logging and audit

Audit covers authentication events, authorization changes, Session creation and termination, and file and MCP operations, so you can reconstruct who did what to which asset and when. Audit entries use a fixed vocabulary of results and decisions for reliable search and review.

Secrets never enter logs, audit entries or error responses. When an operation fails, the error code and message are returned without ever including the credential that failed.

Storage, backups and residency

WingGate is self-hosted: the service's database and backups live inside the operator's own trust boundary and contain asset metadata, authorization relationships and audit history. Where data resides, how long backups are kept and when data is purged are entirely the operator's decisions.

In practice: if you are an end user, your data residency and backup posture depend on how the team that invited you runs its deployment; if you are the operator, these are your operational responsibilities.

Deletion and account closure

The current implementation has no self-service account deletion or closure. To request deletion of an account or specific data, contact us via the channels below and the service operator will handle it manually. We do not promise deletion timelines or retention periods that are not implemented.

Revoking access takes effect immediately: an Organization Owner/Admin can revoke a Project access grant at any time, the revocation applies at the next authorization check, and active Sessions can be terminated.

Third-party services

External identity providers (OAuth) are an optional login method; whether one is enabled, and which provider is used, is configured by the operator. When enabled, the login callback completes on the WingGate service and the returned identity is used only for authentication — it never touches asset credentials.

The current implementation includes no email service and sends no email. Invitations and notifications do not depend on any email channel.

WingGate transmits no data to third parties beyond what you choose to submit through the contact options on this site.

Browser extension

This section covers the WingGate browser extension (the Chrome/Chromium extension you install to bind one of your own browsers as a WingGate asset). The extension runs in your browser and is distinct from the self-hosted WingGate service described above.

Data the extension processes

The extension stores only its own minimal state locally. Its identity keypair is kept as a non-exportable key in IndexedDB (the private key never leaves the extension); the agent identity JSON (including the recovery credential) is stored in chrome.storage.local; currently trusted tabs and the session-confirmation state live in chrome.storage.session (memory, cleared when the browser restarts). It does not read or store your browsing history.

What it transmits and where

The extension connects, over an authenticated WebSocket, only to the WingGate server you chose when binding (by default the operator's server, or your own self-hosted one). By default it transmits the page state of the tabs you have explicitly trusted, plus the commands/results needed to act on them. If you enable the opt-in auto-approve mode in the extension options, the bound server's agents can also act on tabs without per-tab trust, and the state of those tabs is then likewise sent only to that server. It does not upload data to any other third party.

Permissions and their purpose

The extension uses host access, the debugger API, tabs, tabGroups and storage so that it can snapshot and act on pages (navigate, click, fill) at your WingGate agents' request — by default within the tabs or tab group you trust (the opt-in auto-approve mode relaxes this to any non-protected tab). The debugger API is used to capture native dialogs on an authorized tab and to capture a screenshot of a tab that is not the visible one: on your own tabs it is released again right after that capture, while on the agent's own tab it stays attached (Chrome shows its debugging infobar) until you cancel it or the tab closes. No remote code is downloaded or executed.

Your control

By default, sensitive page actions and full page-state reads require your trust, which you grant per tab or to the dedicated agent tab group; you can revoke it at any time or disable the agent group in the extension options. The options also offer an opt-in auto-approve mode: when enabled, the bound server's agents can operate on tabs without per-tab trust or per-action confirmation. With auto-approve off (the default), untrusted tabs are not acted on: they never appear in agent-visible tool output, and the widest listing mode shows only masked metadata (URL origin, no title) for every tab. Unbinding the extension deletes its locally stored identity and key.

Contact

For privacy questions, data deletion requests or security disclosures, use the contact page: Contact page

Changes to this policy

This policy is updated together with the implementation. When data-handling behavior changes, this page is revised and shipped with the release. The version served by your current deployment is authoritative.