Security at Specsight

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 Specsight for analysis and is not persisted after the sync completes.

• 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), and installation_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.

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.

Whose Anthropic account analyses your code. By default, code is analysed using Specsight’s own Anthropic account. If you provide your own Anthropic API key (BYOK), your code goes to your Anthropic account instead. The encrypted storage of BYOK keys is described in Encryption.

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.

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.

Edit history. Every change to a scenario or feature — whether by Specsight or a teammate — is recorded in a changelog table (scenario_changelog, feature_changelog) with the change type, the source (AI vs human), the timestamp, and the author for human edits. Members can see this history in the activity feed.

• 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 DEFINER and 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.

• 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.
• Multi-factor authentication. MFA is not currently enabled in production. TOTP support and SSO (SAML/OIDC) are on the roadmap — if your procurement process requires either, let us know.

• 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.

• Production access. Ola Piętka, the founder, is the sole operator with access to production infrastructure (Supabase, Vercel, Trigger.dev, Stripe, Resend). New team members will not get production access without a documented review.
• Backups. Daily backups are handled by Supabase as part of the managed Postgres service. We have not yet rehearsed a full restore from backup — this is on the roadmap.
• Security headers. All responses set HSTS (2-year, preload), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a locked-down Permissions-Policy. A formal Content Security Policy is not yet deployed and is on the roadmap.
• Rate limiting. Public-facing endpoints (contact forms, OAuth, the MCP server) have per-IP rate limits. The implementation is in-memory per serverless instance — defence in depth rather than a hard guarantee.
• Vulnerability management. Dependencies are pinned in package-lock.json and updated on a regular cadence. We watch npm audit and GitHub’s built-in vulnerability alerts on the repository. Critical vulnerabilities are patched promptly after disclosure.

• 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 deletion is processed immediately on request — your user account, organisation data, scenarios, and connected projects are removed from the active database via cascading foreign-key constraints. Backups held by Supabase rotate out within 30 days.
• Data residency. The Supabase Postgres database — where organisation data, scenarios, and annotations are stored — is hosted in the EU (London, eu-west-2). Application requests and serverless functions run on Vercel in iad1 (Washington DC, USA). Background jobs run on Trigger.dev’s managed cloud (Trigger.dev Ltd. is UK-incorporated; their infrastructure regions are documented on their platform).
• International transfers. Where data is processed outside the EEA — including by application functions on Vercel and AI calls to Anthropic — 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 in the next section.
• 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.

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.

Email ola@specsight.app with SECURITY in the subject line. Include a clear description of the issue, steps to reproduce if possible, any related URLs or proof of concept, and 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 before public disclosure, and that you avoid accessing data that is not your own while testing.