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 while a pull request comment or an agent result shows them. The rest are deleted automatically after 30 days.

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
  • Three things read existing files on your default branch, up to 50 UI files each time: the first review when you install, an audit when you ask for one, and a monthly drift check of one repository on paid plans. They are reviewed and discarded like any other review
  • Nothing else in the repository is read. Rams reads only UI files, and only in repositories you enable
  • 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
  • When a pull request closes, we record what happened to each Rams suggestion on it (committed, changed, resolved, or left open) with its rule and severity. No code, file names or comment text, and it is deleted after 13 months
  • 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
  • Screenshots shown in a pull request comment or an agent result are kept so that comment keeps working. Every other screenshot and patch is deleted automatically after 30 days
  • Deleting your account deletes all of them

Page reviews

The Rams MCP can review a public web page by its address. That page is someone else's code, so the browser that opens it is fenced in.

  • Only public http and https addresses on the standard ports. Private, local and internal addresses are refused, and so is every redirect, image, script or connection the page tries to open to one. Each connection is checked, then pinned to the address that was checked
  • A fresh browser profile for every page: no cookies, no stored sign-ins, downloads off, WebRTC off
  • A hard time limit and a size limit on every page
  • The page's HTML and the screenshots are never stored. We keep the host name, the score and the findings

Rams Gate

Gate checks pull requests against a brand kit you give us. It is turned on per workspace during early access.

  • Brand kits are stored in the same database as your reviews, with the same encryption at rest and the same access controls: Row Level Security scoped to your workspace, and writes only from our servers. The files you import are read to build the kit and not kept. We store the kit, the name and type of each source, and any import warnings
  • Tokens you paste for an import, such as a Figma personal access token, are sent over TLS and used in one request. They are never written to disk, to the database, or to a log
  • On a pull request, Gate reads the same changed files a review reads, with the same short-lived installation token. Files are checked in memory and discarded. A run keeps each finding's file, line, and the value found, never your full code
  • Gate posts one check run, named Rams Gate, and suggested fixes on the lines the pull request changed. It never commits to your repository

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
  • Customers sign in with GitHub or Google. A password sign-in exists only for a small allowlist of review accounts used by app directories
  • Row Level Security on all database tables
  • Rate limiting on the public API endpoints

Service providers

  • Vercel: website hosting (SOC 2 Type II)
  • Supabase: database (SOC 2 Type II)
  • Google Cloud: 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 and is deleted within 30 days, longer only if flagged for a usage-policy violation)
  • GitHub: app integration (SOC 2 Type II)
  • Stripe: payments (PCI Level 1)
  • Resend: email delivery
  • Google: sign-in, site analytics, and our email (Google Workspace)
  • Sentry: error tracking (SOC 2 Type II), sent without cookies, IP addresses or user identifiers
  • Telegram: operational alerts to a private channel we own; an alert never carries a name, an email address (at most its domain), or your code
  • Figma: read only when you import a Gate brand kit from it, with the token you paste for that one request

Where your data lives

  • The database and file storage run on Supabase in the United States (AWS us-east-1, Virginia)
  • The review worker runs on Google Cloud in the United States (us-east1, South Carolina)
  • The web app runs on Vercel, served from its global edge network
  • AI analysis runs on Anthropic, a United States company, under its commercial API terms

Breach notification and DPA

  • Production access is limited to the founder, and every admin account (GitHub, Vercel, Google Cloud, Supabase, Stripe, Google Workspace) requires two-factor authentication
  • If a breach affects your data, we tell you without undue delay and within 72 hours of learning about it
  • We sign a data processing addendum on request. It covers the EU GDPR and the UK GDPR, with the EU standard contractual clauses and the UK Addendum for transfers to the United States. Email security@rams.ai
  • Rams holds no independent security certification yet. Every provider above that hosts or processes your code holds a SOC 2 Type II report

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.