Document details
HubBound Privacy and Data Processing Policy
- Version
- 1.0
- Last updated
- 2026-09-04
- Effective date
- 2026-09-01
- Controller
- HubBound SAS
- Planned public URL
- https://hubbound.net/privacy
1Summary
HubBound is a Windows application, together with its associated services, that helps engineering teams manage artifacts and distributions, connect development tools, observe technical activity and generate operational analytics. This Policy explains what data we may access, collect, receive, generate, store or transmit; why we use it; with whom we may share it; how long we retain it; and what controls users have.
HubBound does not sell personal data and does not use the data described in this Policy for behavioral advertising. We do not request health data, financial data, precise location, official identity documents or passwords for core functionality. Users must not upload secrets, credentials, private keys, health information, financial data or unnecessary personal data inside files, code, prompts, configurations, comments or artifacts.
When an account is created or administered by an organization, that organization may determine what data is processed, who can access it and when it should be deleted. In those cases, HubBound may act as a service provider or processor on the organization’s behalf, and the organization may be the relevant controller. Requests related to a corporate account may also be directed to the organization administrator.
For operations in Colombia, HubBound SAS primarily applies Statutory Law 1581 of 2012 and its implementing rules, including Decree 1074 of 2015. The Colombian authority responsible for personal data protection is the Superintendence of Industry and Commerce. When the service is offered in other countries, the mandatory rules applicable to the user, organization and specific processing will also apply.
2Who this applies to
- The HubBound application distributed through the Microsoft Store;
- The HubBound CLI, daemon, local agent and integration tools that the application installs or uses;
- The HubBound API and cloud services;
- The web console, public registry and artifact distribution services linked to the account;
- Integrations enabled by the user or organization, such as AI providers, GitHub, GitLab, Bitbucket Cloud, Azure DevOps, Jira, Linear, CI/CD, observability, security and other supported connectors.
This Policy does not control processing performed by Microsoft, Google, GitHub, an OIDC provider, an AI provider or any other third party under its own policies. Review those services’ policies before connecting them.
3Data we process
The table below summarizes the categories that may be processed. Not all categories are collected in every installation: some depend on the enabled feature, plan, organization configuration, permissions granted and integration selected.
| Category | Examples | Source and condition | Primary purpose |
|---|---|---|---|
| Book a demo request | Email address, name, phone number, company, role, plan of interest, message and dates | Received when a person submits a Book a demo request without authentication | Respond to the request and communicate HubBound-related updates |
| Account and authentication | Email address, name, username, Google or OIDC identifiers, avatar, onboarding status, role and organization | Received when a person registers, signs in or is invited | Create and protect the account, authenticate, show the profile and apply permissions |
| Organization and collaboration | Organization name and label, teams, memberships, invitations, comments, settings, authorship and changes | Generated while using workspaces and collaborative features | Administer the workspace, share content and maintain an operational history |
| Session and security | Session-token hashes, one-time codes, expirations, revocations, attempts, nonce, OAuth state and recovery data | Generated during login, SSO, OTP, logout and session renewal | Prevent fraud, abuse, replay and unauthorized access |
| Plans and billing | Organization, plan, renewal cycle, status, discounts, amount, currency, description and change history | Generated when an organization views or manages a plan or contract | Apply entitlements, limits, benefits and contract administration |
| Devices and CLI | Device identifier, key identifier, public key or JWK thumbprint, device name, platform, version, scopes, use dates and, if configured, Git name and email | Generated when an authorized device is registered or used | Link uploads to the correct device and account, control scopes and protect ingestion |
| Usage telemetry | Session, provider, tool, product, model and version identifiers; events, metrics, spans, duration, status, token usage, reported cost and resource snapshots | Local collection is on by default; delivery and cloud synchronization may be restricted by local settings and by the organization administrator or entitlement | Diagnostics, reliability, capacity, usage measurement and aggregated analytics |
| Development provenance | Branch, commit, repository, remote, working directory, Git status, paths, line ranges, hashes, line counts, author/committer identity and provenance signals | Generated through integrations or hooks enabled by the user or organization | Reconstruct technical evidence and distinguish known, unknown, ambiguous or conflicting results |
| GitHub | Installation and account, authorized repositories, names and branches, members and teams, logins, observed public emails, pull requests, commits, pushes, webhooks, statuses, diff statistics and structured notes | Only after GitHub is connected and the corresponding permissions are granted | Engineering metrics, synchronization, webhook health and historical analytics |
| Artifacts and files | Code, skills, hooks, subagents, rules, configuration, manifests, descriptions, file names and paths, type, size, SHA-256, content, versions, images, comments and history events | Received when a user or organization creates, uploads, publishes, distributes or modifies content | Version, store, analyze, distribute and display content according to its visibility |
| Derived analytics | Aggregated metrics, counts, timings, team/project/provider/model dimensions, user or organization attribution, identity states and measurement metadata | Calculated from authenticated uploads, GitHub and enabled telemetry | Dashboards, reports, operational queries, security and product improvement |
| Security audits | Artifact content or necessary fragments, manifest digest, findings, severity, score, verdict and engine metadata | Generated when an artifact security audit is requested or applied | Detect risks in skills and artifacts before they are used or distributed |
| Communications and support | Verification email, invitations, operational alerts and support messages; logs or metadata from a diagnostic package started by the user | Generated when the relevant communication or support is requested | Deliver the service, report security events and resolve incidents |
| Technical request data | IP address, user agent, route, method, status, duration, request ID, trace ID, span ID, errors and authentication data needed for logging | Generated when using the API and web services | Security, rate limiting, auditing, diagnostics and abuse prevention |
| Public registry and distribution | Version identifiers, publisher, names, descriptions, icons, tags, aggregated download counts and distribution metadata | Generated when public content is published or downloaded | Operate the registry and display public content |
3.1 Telemetry, prompts and raw content
The default telemetry configuration applies an allowlist and redaction to submitted attributes. Normal provenance retains technical metadata and structured evidence; it does not copy the full text of prompts, transcripts or complete source code by default.
Some identifiers, paths, branch names, working directories, Git emails and repository names may reveal personal, company or team information. They should therefore be treated as potentially confidential data even when they are not the content of a prompt or file.
A raw diagnostic upload may be enabled only through an explicit setting by an administrator or authorized operator, with a recognized policy and a limited expiration date. If an organization enables that option, submitted data may include additional provider, tool, session, conversation, model, path, token, cost, event or hook-payload attributes. The organization must inform its users and apply its own legal basis and controls before enabling that mode.
3.2 GitHub, connectors and AI/human provenance
GitHub is an optional integration connected through a HubBound GitHub App. Disconnection is currently performed from the console. When connected, HubBound processes the metadata needed to synchronize installations, repositories, teams, members, pull requests, commits, pushes and webhook deliveries. Analytics may include author identity, change statistics, paths or ranges and structured evidence of tools, models or sessions.
The platform may receive data from connectors activated by the organization, including Cursor; Claude Cowork and Claude Code; ChatGPT Work and Codex CLI; Gemini CLI and Google Antigravity; GitHub Copilot; GitHub, GitLab, Bitbucket Cloud and Azure DevOps; Jira and Linear; CI/CD pipelines; incident and observability providers; quality and security scanners; and internal billing, survey, roster or identity sources. Each connector should be enabled only with the permissions it needs and is also subject to the relevant provider’s policy.
Provenance results may indicate AI, human, unknown, overlap or conflict, together with the method and evidence level. These labels are technical measurements and do not constitute an infallible determination about a person’s conduct, productivity, job performance or the legal authorship of a work. HubBound must not turn an unknown or conflict state into an authorship conclusion based on temporal inference.
The integration is not designed to store the complete content of all GitHub files or patches. Even so, users should review the permissions, payloads and data made accessible by their GitHub configuration and should not grant more permissions than necessary.
3.3 Artifacts, files and user-provided content
Artifacts may be private, restricted to an organization, shared with a team or published. The selected visibility determines who can see the content and its metadata inside HubBound. A public artifact, its manifest, published versions and publisher metadata may be accessible to other people and may be indexed, cached or copied by third parties.
Users remain responsible for not including secrets, credentials, tokens, private keys, third-party personal data, regulated information or material they do not have the right to share. The security audit provides guidance-oriented findings and does not guarantee that an artifact is safe or free of secrets.
Plan and billing information described in this Policy is contract, entitlement and history metadata. The application does not need to receive complete card or bank-account details for those functions. If a purchase is made through the Microsoft Store or another processor, that provider may process payment data under its own terms and policies.
4How we use data
We use data for the following purposes:
- provide requested functions, including accounts, authentication, organizations, teams, artifacts, distribution, registry, analytics and support;
- validate permissions, apply organization isolation, control device scopes and prevent unauthorized access;
- synchronize an enabled integration, such as GitHub, and return metrics or synchronization status to the user;
- process enabled telemetry, generate aggregated metrics and detect performance or availability errors;
- create technical provenance evidence and maintain upload histories and idempotency;
- analyze submitted artifacts to generate security findings when the feature is active;
- send transactional authentication, invitation, security and operational emails;
- maintain security, investigate abuse, apply rate limits, debug failures and comply with legal obligations;
- display content that a user has made public and measure aggregated registry downloads;
- improve product reliability, documentation and functionality using aggregated or de-identified information where reasonably possible.
We do not use content for targeted advertising or sell personal profiles. We do not make legal, credit, employment, housing or insurance decisions based solely on an automated output from HubBound.
5Legal bases
When applicable law requires a legal basis, the specific basis will depend on the product contracted, configuration, country and HubBound’s role in relation to the organization. In general, we may rely on:
| Possible basis | Examples |
|---|---|
| Performance of a contract or pre-contractual measures | Create the account, authenticate, provide the service, manage organizations, store artifacts and deliver requested functions |
| Consent | Enable optional telemetry, raw uploads, an external integration or non-essential communications when the law requires consent |
| Legitimate interest | Security, fraud and abuse prevention, availability, support, operational auditing and service improvement, balanced against the person’s rights |
| Legal obligation | Respond to valid requests, maintain required records and establish or defend claims |
| Instructions from the customer organization | When HubBound processes data on behalf of a company, team or other organization |
When processing is based on consent, users may withdraw it through the relevant control or by writing to the privacy contact. Withdrawing consent does not affect the lawfulness of processing carried out before withdrawal.
In Colombia, personal-data processing will be carried out with prior, express and informed authorization where required, or under another basis permitted by Law 1581 of 2012. Submitting a Book a demo request does not constitute authorization for marketing: commercial updates require separate consent and must include a way to unsubscribe. That consent can be withdrawn by writing to support@hubbound.net.
7Storage and retention
7.1 Where data is stored
Data may be stored in the HubBound database, object storage, processing queues, analytics stores, logs and operational caches. The local application may also temporarily retain a segmented queue to deliver telemetry when connectivity is unavailable.
The local queue is not an analytics history file. After successful delivery, the local payload is deleted. Details and manifests for terminal failures are kept for up to 20 days; local operational auditing is kept for up to 7 days; some operational counters may be kept for the life of the installation. These periods may change to correct incidents, comply with obligations or adapt to a new version.
Cloud data is retained for as long as needed to provide the feature, maintain security and integrity, comply with legal obligations, resolve disputes and recover the service. The currently defined operational values are:
| Dataset or component | Observed operational retention |
|---|---|
| Pointer analytics payloads in S3 | 7 days |
| Events, delta history and raw analytics payloads in S3 | 365 days |
| Messages in analytics, GitHub and skill-audit queues | 14 days |
| CloudWatch logs for workers and receivers | 30 days as an infrastructure value |
| Unreferenced artifact CAS blobs | Eligible for GC after a minimum 7-day grace period |
| Unreferenced cached bundles | Eligible for GC after a minimum 7-day grace period |
| Local telemetry queue | Successful delivery: immediate deletion; terminal failures: up to 20 days; operational auditing: up to 7 days |
Accounts, organizations, billing histories, webhook deliveries, audit jobs, artifacts and versions are retained while needed for the account, contract, service integrity, security or a legal obligation. There is currently no single expiration job for all of those records. Book a demo requests are retained while needed to respond and manage consented communications, or until deletion is requested.
7.2 Retention cases
- Authentication records, tokens and challenges have expiration, revocation and rotation controls. Access tokens are not retained as visible text in business records; session mechanisms use hashes or protected values where appropriate.
- Signing out invalidates the session and its refresh lineage. It does not automatically delete all account, organization, artifact, log or historical analytics data.
- Disconnecting GitHub from the console stops future reads and synchronization for that installation. Already synchronized data, derived metrics, histories and security records may be retained as needed or until a valid deletion request is handled.
- Deleting a comment or artifact may be a logical deletion. Versions, references, storage objects, backups, caches or audit evidence do not necessarily disappear immediately.
- Public artifacts may remain visible in copies, caches or third-party repositories outside HubBound’s control.
- Backups, security logs, delivery ledgers and records needed for system integrity may be kept for limited additional cycles, including after account deletion. The specific backup period depends on the applicable infrastructure policy and must not be understood as immediate deletion of every copy.
8User controls
Depending on the feature and jurisdiction, users may:
- disable local telemetry when the control is available, or ask the organization administrator to disable analytics and its cloud synchronization;
- sign out and revoke active sessions;
- disconnect GitHub and other authorized integrations;
- view, correct and update profile data available in the application;
- control the visibility, members and permissions of artifacts and workspaces;
- delete comments, artifacts or other content when the feature and permissions allow it;
- request access, rectification, deletion, restriction, objection, portability or withdrawal of consent, when those rights are available under applicable law;
- request information about derived data, the source of an integration and the categories of providers receiving it.
To exercise rights, write to support@hubbound.net with the subject “Privacy request.” Include the account, organization or resource to which the request refers, but do not send passwords, tokens or private keys. We may request reasonable information to verify identity, protect other people and prevent fraudulent requests.
If the account belongs to an organization, some data may only be modified or deleted by that organization’s administrator. HubBound may retain information when necessary for security, fraud prevention, legal compliance, dispute resolution or transaction integrity.
In Colombia, personal-information inquiries are handled within a maximum of ten (10) business days; if it is not possible to respond within that period, we will explain the delay and provide a response date, which may not exceed five (5) additional business days. Claims for correction, updating, deletion or revocation are handled within a maximum of fifteen (15) business days counted from the day after receipt; an informed extension may not exceed eight (8) additional business days. If you believe processing violates the rules, you may file a complaint with the Superintendence of Industry and Commerce or the data-protection authority in your country.
9Security
We apply technical and organizational measures that are reasonable and proportionate to risk, which may include:
- modern encryption in transit and access controls by identity, organization, team, resource and scope;
- rotation, expiration, revocation and protected storage of session credentials;
- cryptographically bound device tokens and storage of the public material needed to validate the proof;
- short-lived object-access URLs with limited permissions;
- separation between raw content, provenance metadata and analytics projections;
- redaction and allowlists for default telemetry;
- idempotency controls, auditing, rate limiting, security logs and operational monitoring;
- review of artifact content for risks when a security audit is requested.
No system can guarantee absolute security. Users should keep Windows and connected tools up to date, protect credentials and private keys, review GitHub permissions and avoid uploading secrets or information that is not necessary.
If you detect a security incident, contact support@hubbound.net. Do not include credentials or secrets in the first contact.
10International transfers
HubBound SAS is incorporated in Colombia and uses primary AWS infrastructure in us-east-1. HubBound and its providers may process data in countries other than the user’s country of residence. When applicable law requires it, we will use a valid international-transfer mechanism, such as an adequacy decision, standard contractual clauses, supplementary measures or another recognized mechanism. The enterprise DPA and applicable contracts will detail the specific mechanism when necessary.
The region and effective location may vary according to the cloud environment, organization and connected provider. Contract-specific information applicable to an organization may be available in the services agreement or data-processing addendum.
11Local data, cookies and similar technologies
The application and local agent may store configuration, protected credentials, public keys, identifiers, logs and a temporary delivery queue on the device. Some of this information is needed to sign in, maintain the integration or deliver data when the device reconnects. Local access is subject to operating-system controls and the permissions of the account running the application.
The web console may use cookies, local storage or other strictly necessary technologies for authentication, security, preferences and session continuity. We do not use these technologies to sell data or for behavioral advertising. If we add non-essential technologies in the future, we will provide the controls and notices required by applicable law before enabling them.
12Children
HubBound is a platform for engineering teams and organizations. The final age classification for Microsoft Store publication must be confirmed before this version is published: if HubBound is not directed to children under 13, we will not knowingly collect personal data from children under that age; if any version is directed to children under 13 or to a higher age set by local law, the corresponding notices, controls and parental consents will apply. If you believe a child provided us with data, write to support@hubbound.net so we can investigate and take appropriate action.
13Changes to this Policy
We may update this Policy when features, integrations, providers, legal requirements or retention practices change. We will publish the new version at the URL indicated in the Microsoft Store and update the last-modified date. If the change is material, we will show a notice in the product or through a reasonable channel before it applies when required by law.
The published Policy must remain consistent with the application, Microsoft Store listing, declared permissions and effective production configuration.
14Contact
Controller: HubBound SAS
Legal and compliance contact: Angel Eduardo Lindarte Lopez, angel@hubbound.net
Address: Dg 40Sur #34D-23, Bogotá, Colombia
Privacy: support@hubbound.net
Security: support@hubbound.net
Support: support@hubbound.net
Data Protection Officer: Angel Eduardo Lindarte Lopez, angel@hubbound.net