Privacy Policy

1. Scope

This policy covers the Tangigo platform at tangigo.com — the web application, the admin and help sites, the APIs behind them, and the agents that run work on your behalf. It describes the data we hold, where it is processed, who else touches it and how long it stays.

Where you connect Tangigo to your own systems — a source-control host, a cloud account, a device — that system remains yours and is governed by its own terms. We describe what we send it and what we keep about it, not how it handles what it receives.

2. The data we hold

We group your data into six classes. The class decides how it is protected and how long it is kept.

3. How credentials and secrets are protected

Everything reaching us travels over TLS. Two categories of stored data get encryption of their own on top of the disk encryption our hosting providers apply, and they work differently. We describe both rather than one, because only the first is sealed under a key that belongs to a single organization.

Secret fields on your records. Integration configuration, TLS private keys, Apple and Google Play signing material, cloud-account keys, Kubernetes and database connection details, environment variables and payment mandate tokens are sealed value by value before they are written. Each value gets its own data key and is encrypted with AES-256 in GCM mode; that data key is itself encrypted with a key-encryption key that exists for your organization alone and is held in Google Cloud KMS. Only the wrapped data key is stored, so no key material sits in our database. Your organization identifier is bound into both layers as additional authenticated data, which means a ciphertext lifted from one organization fails its integrity check when opened under another organization’s key.

Credentials you register in the credential store. When you attach a credential to a tool, an MCP source or an environment, the record you and your team can see holds only a reference and metadata — never the value. In the hosted service the value is held in Google Secret Manager, labelled with your organization. A self-managed deployment that has not enabled Secret Manager keeps the value in our own database instead, encrypted with AES-256 in GCM mode under a platform key with your organization identifier bound in as additional authenticated data. In both configurations the value is write-only: no API route returns it to a browser, and reads are restricted to internal services, rate-limited per binding and written to the audit log.

4. How we use your data

We use it to run the product you asked for: to authenticate you, to hold and version your products, modules and documents, to run agents, tests, builds and deployments on your instruction, to meter and bill usage, to send you the transactional email the product generates, to investigate faults, and to meet legal obligations.

We do not sell, rent or trade personal information, and we do not use your content to build audience profiles or to advertise. Access to production data by our staff is limited to named operator accounts and is recorded in the audit log.

5. Agents, models and training

Running an agent means sending content to a model provider. Depending on the model selected for a request, that is Anthropic, OpenAI, or Google. What is sent is the prompt, the parts of your repository, documents or registry the agent reads, the tool calls it makes and the results that come back. Story builds run in an isolated job whose working copy of your repository is discarded when the job finishes.

Tangigo does not train models. We have no model of our own and we do not fine-tune on your content. Whether a provider trains on traffic sent to its API is governed by that provider’s terms, not by ours, so rather than summarise them we point you at them: Anthropic’s Commercial Terms of Service, OpenAI’s API data-usage policy and Google’s Gemini API / Vertex AI terms each state the position for the paid API endpoints we call. Read them directly — they are the operative commitment, and they can change without us changing this page.

If your organization requires that no content leaves your own infrastructure, the platform cannot meet that requirement with the hosted model providers above, and you should talk to us before sending content you cannot share.

6. Sub-processors

These vendors process data on our behalf in the normal operation of the platform. Each is engaged under its own data-processing terms.

These are engaged only when you connect them, and only for the organization that connected them:

Application-monitoring providers — Datadog, New Relic, Sentry, Dynatrace, AppDynamics and Firebase Crashlytics — are deliberately not on either list when you connect one as an APM integration. That connection runs the other way: using credentials you supply, we read metrics and error counts out of your account and show them in Tangigo. We send those providers a query, not your content, so they are not processing your data on our behalf. Datadog appears in the table above for a separate reason — it is our own front-end monitoring vendor for the web and help sites.

We will update this list before adding a sub-processor that reaches a new data class.

7. Retention and deletion

We keep your content for as long as your organization exists, because it is the product. Audit-log entries are kept as a record of who did what. Billing records are kept for as long as tax and company law requires. Application logs and front-end telemetry are kept for the retention period of the vendor holding them.

When an organization is deleted, three things happen and all three are recorded in the audit log: its records are deleted; its key-encryption key is destroyed; and every value the credential store holds for it is destroyed. Destroying the key is the part ordinary deletion cannot do — it makes every copy of that organization’s encrypted fields permanently unreadable, including copies that already exist in database backups and replicas, because there is no longer a key that opens them.

Data that is not encrypted under that key — the product content, the agent transcripts, the usage records — is removed from the live database on deletion, but a backup taken before the deletion retains it until that backup expires on our database provider’s schedule. Content already sent to a model provider or pushed to your own source-control host is subject to that party’s retention, not ours.

8. Cookies, analytics and session replay

We set a session cookie so the application knows you are signed in, and store your session token in your browser. Google Analytics runs on the public marketing pages. Datadog collects performance and error telemetry in the application and records a sampled share of sessions as replays.

Session replay is configured to mask by default: rendered text is recorded as placeholder characters and form values as asterisks, and screens that display secrets — API keys, webhook settings, database panels, the code editor, terminal output and build logs — carry an additional mask marker. URLs recorded in telemetry have token and signature parameters stripped, and recording is stopped across any navigation whose address carries a credential.

Your email address and name are attached to telemetry only where the deployment enables that; it is off unless turned on. Automated browsers do not report telemetry at all.

9. Your rights

You can access and correct your personal information from your account settings, export your organization’s data, request deletion of your account or your organization, and opt out of non-transactional email. Transactional email about your account, your builds and your billing cannot be switched off while the account is active.

Where an organization holds your data, its owners and administrators control it, and a deletion request may need to go to them. Write to us at the address in section 11 and we will tell you which.

10. Where data is processed

Our backend services run on Google Cloud Run, and each organization’s key-encryption key is held in Cloud KMS in the same Google Cloud region as those services. The deployed region is asia-south1 (Mumbai, India). The sub-processors in section 6 operate globally, so content sent to a model provider, telemetry sent to Datadog, and payments processed by Razorpay may be handled outside India under that vendor’s own transfer terms.