Security

How we protect your code and data.

There are three ways to use Rams, and three security postures. The skill runs entirely in your editor and never reaches our servers. The MCP and the GitHub App send only the files being reviewed, over TLS. We never store your files. Source is analyzed in memory and discarded when the review returns. What persists is the review itself: the score, and each finding with the few flagged lines and the suggested fix, the same excerpts you see on the pull request. Visual reviews keep their before/after screenshots for 30 days, then they are deleted automatically.

The Skill (/rams)

The most private option. Nothing leaves your machine:

  • rams.md is a static text file with no code execution
  • All processing happens in your local AI tool
  • We never see your code, files, or the AI's responses
  • No network requests, telemetry, or analytics during use

The MCP

When your coding agent calls the hosted engine through the MCP:

  • Connections from the Claude connector directory use OAuth 2.1 with PKCE: you approve access on a Rams consent screen and can revoke the connection at any time
  • Direct setups can instead use an API key generated in Settings: shown once, scoped to your workspace, revocable at any time
  • Only the files you or your agent pass to the review tool are sent, over TLS, to the Rams worker
  • Files are analyzed in memory and discarded when the review returns. The stored review keeps each finding's flagged lines and suggested fix, nothing more of your source
  • Each review is metered against your workspace's monthly quota
  • API keys are stored as a hash, never in plain text: we can check a key, we cannot read one back
  • File contents are never used to train models

The GitHub App

When you install the GitHub App for automated reviews on every pull request:

  • Minimal permissions: it reads the contents of the repositories you enable, writes reviews and comments on their pull requests, and writes the check run that shows the review status. It never reads a repository you have not enabled, and it makes no changes to your code, your settings, or your organization
  • We read the files changed in the pull request. For visual reviews we also read up to six files those changed files import directly — your theme or token file, typically — so the render uses your real values instead of stubs. Those imports are rendered only: never reviewed, never quoted in a finding, never patched
  • Nothing else in the repository is read. There is no crawl of your codebase, and no access to branches the pull request does not touch
  • The app is subscribed to pull request, installation, and pull request comment events. Comments are only checked for the @rams review trigger and are never stored
  • Code is analyzed in memory and discarded immediately after the review
  • We store the review, not your files: score, duration, and each finding's flagged lines with the suggested fix — the same excerpts posted on the pull request
  • You choose which repositories to enable. We never review a repo you have not opted in

Visual reviews

Reviews can include before/after screenshots: Rams renders the component in a sandboxed headless browser on our worker, applies its own suggested fix, and re-renders.

  • Only the files already passed to the review are rendered, in an isolated browser that exists just long enough to take the screenshot
  • The screenshots and the applied patch are stored in a private bucket, scoped to your workspace, and served only through short-lived signed URLs
  • Everything visual is deleted automatically after 30 days

How a review works

  1. You open or update a pull request on an enabled repository (or your agent calls the MCP)
  2. Rams fetches only the changed UI files, using a short-lived installation token or your API key
  3. Those files are sent to the review engine over TLS and analyzed by Anthropic Claude
  4. A scored review with inline fix suggestions comes back, posted on the PR or returned to your agent
  5. Your files are discarded immediately. The review that remains holds the score and the findings, with their excerpts and fixes

A review may be cached against a hash of the files that produced it, so the same code re-reviewed on the same engine version gets the same verdict instantly instead of a new model run. The cache holds the review, not your files, and every engine deploy retires it.

One deliberate exception: the free scorer at /scores creates a public score page for a public GitHub repository — the score, the findings and their code excerpts are visible to anyone with the link, by design. It takes no account, so we store the requesting IP address to rate limit it, and the email address you give (if you give one) to send the link. Neither appears on the page. Email us and we take a score page down.

Infrastructure

  • All communication encrypted with TLS
  • GitHub App tokens are short-lived and scoped to a single installation
  • API keys are workspace-scoped and revocable
  • Row Level Security on all database tables
  • Rate limiting on all API endpoints

Service providers

  • Vercel: website hosting (SOC 2 Type II)
  • Supabase: database (SOC 2 Type II)
  • Railway: worker API (SOC 2 Type II)
  • Anthropic: AI analysis (SOC 2 Type II; under Anthropic's commercial API terms, customer content is not used to train models)
  • GitHub: app integration (SOC 2 Type II)
  • Stripe: payments (PCI Level 1)
  • Resend: email delivery
  • Google: sign-in and site analytics
  • Sentry: error tracking (SOC 2 Type II)
  • Telegram: operational alerts to a private channel we own; an alert can carry an email address, never your code

Maximum privacy

Local only: use the /rams skill. It runs entirely in your AI editor, with nothing sent to us.

Enterprise: ask us about self-hosted deployment for teams with strict compliance requirements.

Report a vulnerability

Found a security issue? Email security@rams.ai. We respond within 24 hours.

HSLA0001 Inc.