Security at Specsight
How we handle your code, your data, and your access. We aim to be specific and honest — including about what is and is not in place at this stage of the product.
Your source code is never stored
Repositories are cloned to a temporary environment, analysed, and deleted in the same job. Only the extracted specification persists.
Read-only GitHub access
Specsight uses a fine-grained GitHub App with read-only permissions. It cannot write to, merge into, or modify your repositories.
Row-level security on every org table
Multi-tenancy is enforced at the Postgres layer, not just in application code. Cross-organisation data access is not possible.
European operator, GDPR compliant
Specsight is operated from Poland. We follow GDPR, and a Data Processing Agreement is available on request.
How we handle your source code
This is the most common question we get, so we are explicit about every step.
During analysis. When you trigger a full scan, a background job clones your repository with a shallow Git clone (--depth 1 --single-branch) to a temporary directory created with the operating system's mkdtemp primitive. The clone uses a short-lived GitHub App installation token, not a long-lived credential.
After analysis. The temporary directory is deleted in a finally block — so even if the analysis fails partway through, the code is removed. The cleanup runs whether the scan succeeded, failed, or was cancelled.
What persists. Only the extracted specification: features, scenarios, annotations, connections, and metadata about the scan itself (token usage, duration, status). The raw source code, file contents, and commit messages are not stored anywhere in Specsight.
During merge syncs. When you merge to your watched branch, Specsight receives a webhook and analyses only the diff for the changed files. The diff is sent to the AI for analysis and is not persisted after the sync completes.
GitHub App permissions
Specsight integrates with GitHub via a fine-grained GitHub App — not a personal access token, not an OAuth app with broad scopes.
- Read-only access to repository contents. Specsight can read files, branches, commits, and diffs. It cannot write, push, merge, open pull requests, or modify your repositories in any way.
- Webhook events. The app subscribes to three events:
push(to trigger merge syncs),installation(app install/uninstall), andinstallation_repositories(repo added to or removed from the installation). - Webhook signature verification. Every incoming webhook is verified using HMAC-SHA256 with a timing-safe comparison against a secret known only to Specsight and GitHub. Unsigned or mismatched deliveries are rejected.
- Replay protection. Webhook delivery IDs are tracked in memory with a 10-minute TTL to prevent replay attacks.
- Installation-scoped tokens. When Specsight needs to clone your repository, it generates a short-lived installation token at the moment of the scan. The token is never stored.
AI processing
All code analysis and text generation is handled by Anthropic's Claude.
Specsight uses the Claude Agent SDK for codebase analysis (full scans and merge syncs) and the Claude API for text generation tasks like feature descriptions, change reports, and merge triage. Both run against Anthropic's hosted API.
Anthropic data policy
Per Anthropic's API policy, inputs sent to their API are not used to train their models. Your code is processed for the sole purpose of generating the specification and is not retained by Anthropic for training.
Every AI call logs input and output token counts, cost, duration, and metadata to an internal ai_usage_log table. The logs contain token counts and scan metadata — they do not contain raw prompts or AI outputs.
Data storage and access control
Organisation data is stored in Supabase Postgres. Every table is protected by Row-Level Security.
Row-Level Security (RLS). Every table holding org-scoped data has RLS policies enforced at the Postgres layer. A user authenticated to one organisation cannot read or modify data belonging to another — even if a bug in application code tried to request it. Multi-tenancy is enforced in the database, not only in the application.
What is stored. Features, scenarios, annotations, changelogs, feature connections, feature summaries, projects, organisations, members, profiles, API key hashes, and encrypted BYOK keys.
What is not stored. Raw source code, repository file contents, full commit history, or plaintext API keys.
Encryption
All data in transit is encrypted, and sensitive secrets have an additional layer of protection at rest.
- In transit. All connections use TLS/HTTPS. This includes API requests, webhook deliveries, database connections, and any calls to third-party services.
- At rest (database). The Supabase-managed Postgres database encrypts stored data using Supabase's platform defaults.
- BYOK API keys (Bring Your Own Key). When you add a BYOK Anthropic key for your organisation, it is encrypted and stored in Supabase Vault — a dedicated secrets manager, not a regular database column. It is only decrypted at the moment of use and is never logged. The underlying RPC functions that read BYOK keys are
SECURITY DEFINERand restricted to the database service role. - Webhook signatures. GitHub webhooks are verified using HMAC-SHA256 with a timing-safe comparison, not a simple string equality check.
Authentication
Specsight uses Supabase Auth for all authentication.
- Supported methods. Email and password, Google OAuth, and magic link (used for invitation acceptance).
- Password storage. Password hashing is handled by Supabase Auth using industry-standard algorithms. Specsight never sees or stores plaintext passwords.
- Sessions. JWT-based sessions are delivered as HttpOnly, Secure, SameSite=Lax cookies.
MCP API keys
API keys for the Specsight MCP server are designed so a database breach would not expose usable credentials.
- Hash-only storage. The full API key is shown to you exactly once, at creation. Only a SHA-256 hash is stored in the database. If the database were ever exposed, existing keys would not be usable.
- Prefix for identification. All keys start with
sk_sp_. The first 8 characters are stored separately so you can identify which key is which in the UI without the hash being exposed. - Org-scoped. Each key is scoped to a single organisation. Members can see and revoke their own keys; admins can see and revoke any key in the organisation.
- Soft revocation. Revoked keys are marked with a timestamp rather than deleted, so the audit trail is preserved.
Subprocessors
The third-party services Specsight relies on to operate. Each one is listed below with its purpose and the data it may handle.
Data transfers outside the European Economic Area rely on the EU–US Data Privacy Framework or Standard Contractual Clauses as appropriate. See the privacy policy for the full legal basis.
Compliance and your data rights
Specsight is operated from Poland by Ola Piętka, a registered sole proprietorship. Personal data is handled under GDPR.
- GDPR. Specsight follows the General Data Protection Regulation. The privacy policy details lawful bases for processing, data retention, and your rights as a data subject.
- Data subject rights. You can request access to, correction of, or deletion of your personal data. Account deletions are processed within 30 days.
- International transfers. Where subprocessors are based outside the EEA, transfers rely on the EU–US Data Privacy Framework or Standard Contractual Clauses.
- Data Processing Agreement (DPA). A DPA is available on request. Email us at the address at the bottom of this page.
- Breach notification. In the event of a personal data breach, Specsight will notify the Polish supervisory authority (UODO) within 72 hours of becoming aware, and affected users directly if the risk is high.
What we do not claim
Specsight is an early-stage product. We think being specific about what is and is not in place matters more than marketing language.
We have not yet pursued external compliance certifications such as SOC 2 or ISO 27001. Security reviews and penetration testing are on the roadmap but have not been commissioned at the time of writing. If your procurement process requires any of these, let us know — we can discuss where we are and what is realistic to commit to.
The practices on this page are what the product does today. As the product matures and we add subprocessors or capabilities, this page will be updated and the privacy policy will be versioned accordingly.
Reporting a security issue
If you believe you have found a security vulnerability in Specsight, we want to hear about it.
Email ola@specsight.app with SECURITY in the subject line. Please include:
- A clear description of the issue
- Steps to reproduce, if possible
- Any related URLs, logs, or proof of concept
- Your assessment of the impact
We take reports seriously and respond as quickly as we can. We ask that you give us a reasonable window to investigate and fix the issue before any public disclosure, and that you avoid accessing data that is not your own while testing.
Frequently asked questions
Does Specsight store my source code?+
What AI provider does Specsight use, and is my code used to train models?+
What GitHub permissions does Specsight need?+
How do you isolate one organisation from another?+
How are API keys protected?+
What happens if I delete my account or organisation?+
Can I request a Data Processing Agreement (DPA)?+
How do I report a security issue?+
Still have questions?
For anything not covered here, check the privacy policy and terms of service — or get in touch and we will answer directly.