Security

This page describes how Warpway is built to protect your code, your organization and the integrity of its reviews. For a summary, see the security overview.

Infrastructure

Warpway runs on Vercel, with its data in Neon Postgres in AWS us-east-1. Background work, such as reviews, routing and Slack delivery, runs as durable jobs stored in the database, so a restarted worker resumes where it left off instead of losing work. All traffic uses TLS, and browsers are told to use HTTPS only (HSTS for two years, including subdomains). Responses carry headers that block framing and MIME sniffing.

Authentication

• Sign-in is GitHub only. There are no Warpway passwords to leak or reuse.
• Sessions use an opaque random token in an HTTP-only cookie. The database stores only the token's SHA-256 hash.
• OAuth state for GitHub sign-in, GitHub App installation and Slack connection is single use, expires after 10 minutes and is bound to the browser that started the flow, which blocks cross-site request forgery and replayed callbacks.
• Membership in an organization is verified against GitHub: you see an organization only if GitHub confirms you are a member of the GitHub organization that installed Warpway (or you are the personal account that installed it). Being able to see the installation is not enough, so outside collaborators and people with access to a single repository do not get organization-wide access; they see Warpway's results on GitHub and can answer questions sent to them. Membership is re-checked when you sign in and every hour; someone who leaves the GitHub organization loses access, whatever their role. An organization left without an Owner is reclaimed by the next GitHub organization owner who signs in, and every change is recorded in the audit log.

Authorization

Every action checks the signed-in person's role in the organization:

Tenant isolation

Every query for customer data is scoped to one organization. In the dashboard and API, the organization comes from your verified membership; in background jobs, from the stored records the job refers to. Identifiers sent by a browser are never trusted on their own: Warpway checks that the record belongs to your organization before reading or changing it. Object storage keys are prefixed with the organization's id.

Secrets and encryption

• Credentials such as the GitHub App private key, Slack signing secret, Stripe keys and model API keys are held in encrypted environment configuration, never in code or the database.
• Slack bot tokens are encrypted with AES-256-GCM before storage, with the Slack installation's id as additional authenticated data, so a ciphertext cannot be moved to another installation.
• GitHub user tokens from sign-in are stored encrypted with the session.
• Encryption keys are versioned, so they can be rotated while existing data stays readable.
• The database encrypts all data at rest.

GitHub access

Warpway uses a GitHub App with minimal permissions (see GitHub permissions). It acts on repositories with installation tokens that GitHub issues for one hour; Warpway keeps them in memory only and never stores them. Uninstalling or suspending the app ends access immediately.

Webhooks and replay protection

• GitHub deliveries are verified with the X-Hub-Signature-256 HMAC; Slack requests with the X-Slack-Signature v0 signature and a five-minute timestamp window; Stripe events with Stripe's signature. Verification uses the raw request body, before anything is parsed.
• Each delivery or event id is recorded once per provider. A repeated delivery is acknowledged and ignored.
• Background jobs carry idempotency keys, so a retried job cannot send a second message or publish twice.
• Public endpoints are rate limited.

Stale results cannot overwrite current ones

Before any visible change for a review (the check, the summary comment, a reviewer request, a Slack message or an approval), Warpway locks the pull request's record and confirms that the review is still the current one for the pull request's head commit. If it is not, the change is skipped. A slow review of an older commit can finish, but cannot publish.

Prompt-injection defenses

Repository files, pull request text, comments, tickets and Slack messages are untrusted. Warpway's defenses do not depend on a model noticing an attack:

• Untrusted content is delimited. Content reaches the model inside marked blocks, and any block delimiter inside the content is neutralized first, so the content cannot close its block or open a new one. Every prompt states that such blocks are data that cannot change instructions, tools, output format or access.
• Tools have a fixed scope. Lens tools read one repository at one commit for one organization. They take no repository or organization parameters from the model, so text cannot point them elsewhere.
• Allowlists come from configuration. Which tools a lens may use is set by your configuration, never by the model or by repository text.
• No shell. No tool executes commands. Commands run only through runtime verification profiles you approve.
• Decisions are deterministic. Policy satisfaction, check conclusions and auto-approval eligibility are computed by code from stored results.
• Attempts are reported, not followed. Prompts tell the model that text addressed to reviewers or AI is evidence about the change, not an instruction, and the Security lens is told to report an attempt to steer the review, for example to approve the change or reveal its prompts, as a finding.

Policy integrity

The configuration used to review a pull request is read from the base branch, so a pull request cannot relax its own review. Organization locks stop repositories from overriding settings an Owner fixed. Raising a repository's trust level to Clear or above, and enabling auto-approval, require an Owner and an explicit confirmation.

Failure behavior

Warpway fails closed. A failed model call, tool, repository fetch, runtime verification or Slack delivery never turns a lens Cleared: the affected lens stays Incomplete, or its question stays open, and the review shows the reason. Transient errors are retried with bounded backoff; jobs that keep failing are set aside for investigation rather than retried forever, and the review stays blocked meanwhile.

Logging and monitoring

Logs record identifiers, counts, durations and statuses. A redacting logger drops fields that carry source code, diffs, file contents, prompts, model output, questions, answers and secrets, shortens other long text, and masks token formats such as GitHub, Slack, Stripe and model API keys wherever they appear. Errors are grouped and stored in redacted form.

Audit log

Warpway records an audit trail of routing decisions, answers and their sources, configuration and trust changes, knowledge approvals, admin and staff actions, and every automatic approval. Audit events never contain source code.

Data retention and deletion

Review content, such as pull request snapshots, evidence excerpts and task conversations, is deleted after your organization's retention period. Review records are kept until the organization is deleted, which an Owner can do at any time. See Data handling and Uninstall and deletion.

Reporting a vulnerability

Email marcus@cmglabs.ai with what you found and how to reproduce it. Please do not access data that is not yours or degrade the service, and give us a reasonable chance to fix the issue before disclosing it.