Tently (“Tently”, “we”, “us”) provides a pull request review service that checks changes against the architectural decisions of your codebase. This policy explains what we collect when you use tently.dev, the Tently dashboard, the Tently GitHub App and the Tently MCP server (together, the “Service”), and what we do with it. The short version is on our home page; this is the long one.
1. What we collect
Account data
When you sign in with GitHub we receive your GitHub user id, login, display name, avatar and — where GitHub provides it — your email address. We store your workspace memberships and roles, and invitations you send or receive (including the invitee’s email address).
Repository-derived data
To review your code the Service reads repositories you connect through the GitHub App. We do not store your source code. Repositories are cloned with a short-lived installation token into a temporary workspace that is deleted when the job finishes. What we do keep is derived from it:
- Decisions — short natural-language descriptions of architectural rules, with references (file paths, symbol names, commit and pull request links) to where they came from.
- Findings — review results posted to your pull requests: a title, an explanation, the file location, severity, and the feedback your team gives them.
- Embeddings — numerical vectors computed from decisions so they can be searched. They are computed on our own servers, not by a third party.
- Repository metadata — names, default branches, detected services, pull request numbers, titles and authors, indexing status.
Documents you upload
If you import decisions from a document, the file is processed in memory to extract candidate decisions and is not stored. Only the decisions you choose to save are kept.
Credentials
API keys you create for the MCP server are stored only as a one-way hash. If you bring your own model provider key, it is stored encrypted at rest and is only decrypted to make model calls for your workspace. We never display it again in full.
Usage and technical data
Server logs (IP address, request path, timestamps), error reports, and model-call metadata (tokens, cost, latency) used to run, secure and bill the Service. The marketing site does not use advertising or cross-site tracking cookies. The dashboard uses a single session cookie to keep you signed in.
2. How we use it
- To provide the Service: index repositories, review pull requests, answer MCP queries.
- To secure it: authenticate users, enforce workspace isolation, prevent abuse.
- To operate it: debug errors, measure cost and performance, contact you about the Service.
- To improve it, using aggregate metrics and the feedback you give on findings.
We do not train machine-learning models on your code, decisions or findings, and we do not sell personal data.
3. Model providers
Reviewing and indexing require sending excerpts of your code — the diff under review, the surrounding context and the relevant decisions — to a large language model. By default these requests go through OpenRouter to Anthropic, under their API terms, which do not permit training on API inputs. If your workspace adds its own OpenRouter API key, requests for your workspace are made with that key instead: they are billed to your OpenRouter account and are governed by your agreement and privacy settings with OpenRouter and the providers you allow there.
4. Sub-processors
We rely on these service providers to run Tently:
| Provider | Purpose | Location |
|---|---|---|
| GitHub | Sign-in (OAuth) and repository access through the Tently GitHub App | Global |
| Google Cloud | Application hosting and compute | EU / US |
| Supabase | Managed Postgres database for account and workspace data | EU / US |
| OpenRouter | Routing of model requests to the model provider | US |
| Anthropic | Large language model that performs reviews and indexing | US |
| Cloudflare | DNS and network edge | Global |
| Resend | Transactional email (workspace invites) | US |
| Loops | Early-access waitlist email | US |
| Sentry | Error monitoring | US |
| Langfuse | Model-call observability (cost, latency, request traces) | EU |
We will update this list before adding a sub-processor that handles repository data.
5. Retention and deletion
- Source code: not retained — deleted at the end of each job.
- Workspace data (decisions, findings, metadata): kept while your workspace is active. Disconnecting a repository stops all processing of it.
- Model-call traces and logs: kept for up to 30 days for debugging and cost accounting.
- On request, or when you delete your workspace, we delete its data within 30 days, except where we must keep records to meet legal obligations.
6. Security
Data is encrypted in transit (TLS) and at rest. Every workspace-scoped table is protected by Postgres row-level security, and the application connects with a role that cannot bypass it. Access to production systems is limited to the people who operate the Service.
7. Your rights
Depending on where you live (for example under the GDPR or UK GDPR), you may have the right to access, correct, export or delete your personal data, and to object to or restrict its processing. Write to [email protected] and we will respond within 30 days. You can also complain to your local data protection authority.
For personal data inside your repositories (for example commit authors), your organization is the controller and we process it on your behalf; we will support your organization in responding to requests about it.
8. International transfers
Our providers may process data outside your country, including in the United States. Where required, transfers rely on the European Commission’s Standard Contractual Clauses or an equivalent safeguard.
9. Children
The Service is for professional use and is not directed to anyone under 16.
10. Changes
We will post changes here and update the date above. For material changes we will notify workspace owners by email or in the dashboard before they take effect.
11. Contact
Questions about this policy: [email protected].