Security & data

1. Architecture overview

Understanding how SiftPulse touches your data starts with understanding the request path it follows.

1. Canonical webhook URLs.
   • GitHub (App + Marketplace + manual webhooks): POST https://siftpulse.polsia.app/github/webhook
   • GitLab: POST https://siftpulse.polsia.app/webhooks/gitlab
   • Render (deploys): POST https://siftpulse.polsia.app/webhooks/render
   • Stripe (billing): POST https://siftpulse.polsia.app/api/webhooks/stripe
   Each URL is HMAC-verified against a platform-issued signing secret; the response is Cache-Control: no-store so CloudFront (or any CDN) cannot cache an upstream auth failure and replay it on the next legitimate event.
2. Inbound webhook. When a pull request opens, updates, or is marked ready, your code-hosting platform (GitHub, GitLab, or Bitbucket) sends a signed webhook to the appropriate route (routes/github.js, routes/gitlab.js, or routes/bitbucket.js). We verify the signature against a platform-issued secret before processing anything.
3. Diff extraction and secret stripping. The webhook handler fetches the unified patch and PR metadata from the platform API, then strips content matching known secret patterns (private keys, .env-style assignments, common credential regexes) before assembling the review prompt.
4. AI inference via POLSIA_AI_BASE_URL proxy. The cleaned prompt is sent through services/pr-review.js to the configured AI provider over the Polsia-managed AI proxy. The provider processes the request and returns structured findings (verdict, blockers, suggestions, nits).
5. Comment posting. Findings are formatted into a PR review comment and posted back to your PR using the installation token on the corresponding platform. We edit our own comment idempotently on re-review; we never touch author-submitted comments.

Throughout this flow, we do not control your infrastructure, operational technology (OT), or industrial control systems (ICS) — SiftPulse analyzes source code in pull requests and issues only.

2. Data we collect and how we use it

SiftPulse collects the following categories of information, all in service of running AI code reviews and powering the customer dashboard:

• GitHub App installation data: GitHub user info (login, display name, avatar URL, numeric account ID), organization or account name, and the repository IDs you select for review. Used to verify authorship and post comments on the right PRs.
• Pull request metadata: PR titles, numbers, authors, branch names, and file paths changed.
• Code diffs (unified patches): The unified patch content of each pull request is sent to our AI provider at review time to generate findings. Raw diffs and full source files are never stored. They are processed in memory during review and discarded after the AI response is posted back to your PR. We only store structured review findings (verdict, severity counts, summary excerpt, comment IDs) and they are purged within 30 days of GitHub App uninstall or a written deletion request.
• Review event data: AI-generated review findings (blocker / suggestion / nit classifications, verdict, summary excerpt) and review timestamps. Stored to power your dashboard, activity feed, DORA metrics, and weekly digest.
• Account and billing information: Email address and Stripe customer ID for subscription management. We do not store payment card details — those are handled entirely by Stripe.
• Dashboard usage data: Pages visited, feature settings configured, and navigation patterns within your SiftPulse dashboard (via Plausible and the Polsia analytics beacon).
• Email address: Used for magic-link authentication, onboarding emails, weekly digest, and Slack notification configuration.

Data we access

For Marketplace reviewers and security teams, here is the enumerated data-access taxonomy SiftPulse is built around. Each category show where the data originates, where it is stored, and which sections below cover sub-processors and retention in detail.

1. Code diffs. Unified patches for the files changed in a PR or issue. Fetched from the GitHub / GitLab / Bitbucket API on each event, processed in memory by the AI provider, and never stored in our database. See Sub-processors for which providers see the diff and Data retention and deletion for why the raw diff leaves no trace.
2. Repository metadata. Repository name, default branch, visibility (public / private), and the selected repo IDs you grant SiftPulse. Stored in github_installations.selected_repo_ids, bitbucket_installations.selected_repos, and the gitlab_installations row so we know which repos to subscribe to webhooks for.
3. Pull request & issue metadata. PR / issue number, title, author login, source / target branch, and labels. Stored in pr_review_events, triage_events, and pr_nudge_events to power the dashboard, activity feed, DORA metrics, and digest.
4. Comments we author. Review comments, TL;DR sticky comments, commit-suggestion blocks, merge-readiness summaries, and triage notes. Posted back to your repository through the corresponding platform API; we keep the comment ID and a short excerpt locally. See pr_review_events, tldr_comment_events, and suggestion_events.
5. Dashboard / billing data. Installer email, Stripe customer ID, plan state and subscription period. Stored in the users, subscriptions, and dashboard_sessions tables; payment cards live only inside Stripe.

We do not sell, rent, or share your personal information with third parties for marketing purposes. This list mirrors our Privacy Policy — if these two lists ever drift, the Privacy Policy is the authoritative source.

What we never send to model providers: environment variables, secret keys, tokens, .env files, database credentials, or any content matching patterns like -----BEGIN RSA PRIVATE KEY-----. The diff parser strips these before constructing the prompt, and we never send the full repository codebase — only the files and lines changed in the PR or issue under review.

3. Encryption

In transit. All traffic between your browser, our application servers, your code-hosting platform, and our AI providers is encrypted with TLS 1.2 or higher. We do not accept connections on plaintext HTTP for any service-to-service or browser-to-app path.

At rest. Customer and review data is stored in Neon PostgreSQL (US-East region) with AES-256 encryption at rest enabled by Neon. Application-layer data processed within Render uses Render's encrypted storage. Review event payloads and billing records inherit the same encryption-at-rest posture.

Webhook signatures. Inbound webhooks from GitHub, GitLab, and Bitbucket are verified using platform-issued signing secrets before any payload is processed. Webhook signing secrets are stored as environment variables and are never logged.

4. Access control

SiftPulse operates on a least-privilege model across both platforms and our own infrastructure.

• GitHub App installation tokens. When the SiftPulse GitHub App is installed on a repository, GitHub issues installation tokens scoped to that single installation. Tokens are auto-refreshed by GitHub, stored encrypted in our database, and never exposed to the browser or logs. The same model applies for GitLab project tokens and Bitbucket workspace tokens.
• GitHub App permissions. SiftPulse requests only the read and write scopes required to post review comments and read your repository diff. The full permission table (including what we explicitly do not request — write to source code, merge, delete, manage members) is in our Terms of Service Appendix on third-party services.
• Dashboard authentication. The customer dashboard at /app uses magic-link authentication only — no passwords. Tokens are stored hashed in the dashboard_sessions table and expire after 7 days of inactivity. The session cookie is HMAC-SHA256 signed, httpOnly, and SameSite=Lax.
• Engineering team access. SiftPulse engineering does not have standing access to customer source code or raw diffs. Emergency access procedures are documented internally and reviewed quarterly. There is no public-facing admin panel.
• No long-term source storage. SiftPulse does not store full repository source code. Raw diffs are processed in memory at review time and discarded; we only retain structured review findings (category, severity, file path, finding text). Full repository contents are never fetched for the AI model — only the specific files and lines changed in the PR being reviewed.

Looking for SAML / SSO? See /security/enterprise for the current auth model (GitHub OAuth + magic link, no separate credential store) and the explicit SAML/SSO + SCIM roadmap.

Permissions SiftPulse requests

Each row below uses the exact scope name GitHub renders in the App install dialog, with one-line justification pulled from the code that actually uses the scope.

Permissions we do NOT request

The App install dialog will not show any of the following — requesting them would expand SiftPulse's blast radius without buying anything we need to run a code-review agent:

• Contents (write) — no commits, pushes, or edits to source files.
• Administration — cannot manage repo settings, branch protection, or visibility.
• Secrets, deploy keys, and environments — no read or write to CI/CD configuration.
• Packages, Pages, Security advisories, Actions, Projects — none of these are touched.
• Email addresses — we use GitHub user logins, not private email addresses.
• Blocking / merge / close / delete PRs — reviews are advisory only.

5. Sub-processors

SiftPulse uses the following third-party sub-processors to deliver the Service. Each is listed with the purpose for which it is engaged and the specific data it receives.

6. Compliance certifications & external reports

A summary of the formal certifications SiftPulse is working toward, has obtained, or is out of scope for, plus where to find the supporting evidence. This section is what Marketplace enterprise reviewers cite when scoring trust content.

• SOC 2 Type II. Our Type II audit is in progress with our assessor. Expected completion is Q4 2026. Interim controls evidence is available under NDA on request — write to security@siftpulse.polsia.app for access.
• GDPR / EU AI Act. EU AI Act Article 50 transparency disclosures are wired into every AI-authored comment via lib/ai-act-disclosure.js. SiftPulse is not classified as high-risk under Annex III — see the full walk-through in section 7 below. A Data Processing Agreement (DPA) is available on request via the contact in section 9.
• ISO 27001. Scoping for FY27 once the SOC 2 Type II report lands. The current information-security program already maps to the ISO 27001 control families (organizational, people, physical, technological).
• HIPAA. Not applicable. SiftPulse does not store, process, or transmit Protected Health Information (PHI). Customers subject to HIPAA should not send PHI to SiftPulse surfaces.
• External audit reports. Our SOC 2 Type II report will be published at https://siftpulse.polsia.app/trust/SOC2-Type-II.pdf once issued. Prior to issuance, an executive summary is available under NDA — write to security@siftpulse.polsia.app.

7. EU AI Act compliance

SiftPulse is subject to the EU AI Act as a general-purpose AI system deployed for code review. This section describes how we meet our transparency obligations and why SiftPulse is not classified as a high-risk system under Annex III.

SiftPulse is not a high-risk system under Annex III — SiftPulse reviews source code, not natural persons.

Every comment SiftPulse posts includes the AI-generated disclosure with link.

SiftPulse does not evaluate, rank, score, or profile individuals, and does not access biometric, identity, or employment data.

Article 50 — transparency for AI-generated content

The EU AI Act's Article 50 requires that AI-generated content disclosed to the public be labeled so users know it was produced by an AI system. SiftPulse posts AI-generated PR review comments, issue triage notes, reviewer suggestions, merge-readiness summaries, TL;DR summaries, stale-PR nudges, weekly digest emails, and dashboard activity feeds. Every one of those surfaces includes a visible footer:

— This comment was generated by SiftPulse AI, an automated code review system. See AI Act disclosure.

The footer is appended by lib/ai-act-disclosure.js from a single source of truth so no surface can silently drop the disclosure. Questions about our AI Act compliance posture or the per-comment footer? Contact security@siftpulse.polsia.app — see also Responsible disclosure below.

Annex III high-risk classification — why SiftPulse is not high-risk

Annex III of the EU AI Act lists eight categories of AI systems that are classified as high-risk and subject to conformity assessment, ongoing monitoring, and registration in an EU database. Walking through each:

1. Biometric identification & categorisation of natural persons. SiftPulse does not process biometrics, faces, voices, fingerprints, or any physical identifiers. Not applicable.
2. Critical infrastructure (water, gas, electricity, digital). SiftPulse reviews source code in pull requests. It does not control infrastructure, OT, ICS, or safety-critical systems. Not applicable.
3. Education and vocational training (admissions, grading, evaluation). SiftPulse reviews code, not students or coursework. Not applicable.
4. Employment and worker management (recruitment, screening, task allocation, evaluation, promotion, termination). SiftPulse does not screen candidates, allocate work, evaluate employees, or make any decisions affecting a person's employment. Not applicable.
5. Access to essential private and public services (credit scoring, insurance pricing, eligibility for public benefits, emergency dispatch). SiftPulse cannot decide who receives credit, insurance, benefits, or emergency services. Not applicable.
6. Law enforcement. SiftPulse is not a law-enforcement tool. Not applicable.
7. Migration, asylum, and border control. SiftPulse does not process migration applications or biometrics for travel. Not applicable.
8. Administration of justice and democratic processes. SiftPulse does not adjudicate cases, generate legal rulings, or influence elections. Not applicable.

SiftPulse reviews source code in pull requests and issues. It does not screen people, grade students, identify individuals biometrically, make decisions about employment, allocate public benefits, or assist law enforcement. None of the Annex III categories apply, so SiftPulse is not classified as a high-risk AI system under the AI Act.

8. Data retention and deletion

SiftPulse does not store code or PR content. Review data is processed in memory per review and discarded after the comment is posted. The resulting review comment lives only in your repository under normal GitHub retention. The retention rules for each data bucket are explicit below.

What we keep, and for how long

Deletion on request. You can request immediate deletion of your account, billing records retention notwithstanding, by emailing privacy@siftpulse.polsia.app. We verify the request and complete deletion within 30 days. See the Privacy Policy for the full process.

App-uninstall behaviour. If you uninstall the SiftPulse GitHub App, GitLab OAuth app, or Bitbucket OAuth consumer from your organization, SiftPulse immediately stops processing new webhooks for that installation. Review event rows already in our database (pr_review_events, tldr_comment_events, suggestion_events, triage_events) are purged within 30 days of uninstall. To request immediate deletion before the 30-day window, email privacy@siftpulse.polsia.app — see GDPR / CCPA rights below.

9. GDPR / CCPA rights

Depending on where you reside, you may have the following rights regarding your personal data:

• Access: Request a copy of all personal data we hold about you.
• Correction: Request correction of inaccurate personal data.
• Deletion: Request deletion of your account and associated data. We will comply within 30 days.
• Portability: Request your data in a machine-readable format.
• Objection: Object to processing for direct marketing purposes.

Full definitions and the exact process for exercising these rights are in our Privacy Policy.

GDPR (EU/EEA): SiftPulse offers a Data Processing Agreement (DPA) for customers subject to GDPR. Request the DPA by emailing hello@siftpulse.polsia.app.

CCPA (California): California residents have the right to know what data we collect, delete it, and opt out of the sale of personal information. We do not sell personal information. To exercise your rights, contact us at the email above.

10. Responsible disclosure

We welcome reports from security researchers and customers who find a vulnerability in SiftPulse.

• Contact: security@siftpulse.polsia.app
• Acknowledgement: We aim to acknowledge reports within 2 business days.
• Status update: We provide a status update within weekly until fix shipped or risk-accepted of acknowledgement.
• Coordinated disclosure window: 90 days. Once a fix is available and tested, we request that the reporter delay public disclosure for up to 90 days to allow for customer deployment. If a fix is not deployed within 90 days, public disclosure is permitted. We credit reporters in our changelog with their permission.

What to include: a clear description of the issue, affected endpoints or repos, and any proof-of-concept or reproduction steps. Please do not include actual customer data in your report.

Encrypted contact (optional). If you need to send sensitive details, use security@siftpulse.polsia.app with a PGP key available on key servers. Our PGP key is also linked from our keybase.io/siftpulse profile.

11. Status & uptime

Live status and historical uptime are published on our status page: https://siftpulse.polsia.app/status.

Until that page goes live, planned maintenance and incidents are announced in our /changelog and via your install email if the impact is customer-visible.

Service uptime: SiftPulse is provided on an "as is" and "as available" basis. We do not guarantee 100% uptime — see our Terms of Service — Disclaimers for the full disclaimer.

12. On-premise & VPC deployment

Run SiftPulse inside your own infrastructure — no data leaves your network.

Current status: On-premise and VPC (AWS, GCP, Azure) deployment is planned but not yet available. This will allow enterprises to run SiftPulse inside their own network, keeping all code and review data within their infrastructure. The AI inference layer will need to be self-hosted or use a BYOK key routed through a private model endpoint.

Customer interest helps us prioritize. If you need on-premise for a compliance requirement, the waitlist below moves the priority up.