Skip to main content

Trust center

A plain trust overview without borrowed compliance claims.

Use this page for a vendor security review: what Skylos Cloud receives on each path, which providers process it, whose AI key is used, how long data is kept, and which controls exist. Skylos is early and does not claim SOC 2, ISO 27001, or CSA STAR certification today; where a control is missing, this page says so.

Live trust overview ยท not a frozen evidence packet or third-party audit report

What leaves your machine

The CLI sends no code or findings to Skylos unless you run a command that uploads (--upload, skylos upload, --verify or skylos ingest claude-security) or a CI workflow that does, or you connect the GitHub App. Here is exactly what each path sends. The CLI is open source, so you can read the code behind every request.

  • Local CLI scan

    Trigger

    skylos . and other local commands, without --upload

    What Skylos receives

    Nothing from your code or findings goes to Skylos. If a Skylos token is present, a scan downloads your project's custom rules from Skylos Cloud, sending only the token. Dependency checks (--sca, -a) send package names and versions to OSV, package-existence checks send package names to public registries (PyPI, npm, the Go proxy), and skylos agent commands send code to the model provider you configure. None of these pass through Skylos.

    Kept out, and caveats

    CLI 4.49 and earlier: skylos agent scan, agent verify and agent remediate also send Skylos Cloud a run summary whenever a token is present, even without --upload: counts, the model name, commit, branch and the CI or commit author name. No code, file paths or findings. To avoid it, run agent commands without a saved login or SKYLOS_TOKEN.

  • Scan upload

    Trigger

    skylos cloud, skylos . --upload, skylos upload, or the CI workflow skylos cicd init writes (its upload job runs on pushes to the default branch)

    What Skylos receives

    The scan report: for each finding the rule ID, severity, message (up to 500 characters), file path, line number, a code snippet of up to 240 characters and the git-blame author email of that line; plus commit, branch, the CI actor or commit author name, CI run details, the Skylos version and summary counts. Optional sections: AI provenance, defense, technical debt and a symbol index (names and locations) for dead-code review.

    Kept out, and caveats

    Your source files. Findings for secrets are sent without a snippet. skylos ingest claude-security also uploads by default (--no-upload keeps it local), and --verify sends the scan's findings to Skylos Cloud for checking.

  • Cloud scan (GitHub App)

    Trigger

    A member picks a repository with Scan this repo, or installs the GitHub App from Scan a repository (which scans straight away if the installation covers exactly one repository). Each push to the default branch then re-scans it until an owner or admin turns it off

    What Skylos receives

    Skylos mints a read-only token for that one repository, clones one commit into a fresh, non-persistent Vercel Sandbox that can reach only github.com, revokes the token, limits the network to api.osv.dev, runs the pinned open-source scanner without running your code (its dependency check sends package names, ecosystems and versions to OSV), and keeps the findings report. The sandbox is stopped after the scan (at most 215 seconds).

    Kept out, and caveats

    Commit author emails and CI details (Cloud scans read no git history). The repository copy is not kept.

  • Other GitHub App use

    Trigger

    A repository with the App installed

    What Skylos receives

    Repository metadata; the one file involved when someone opens a finding's code view or clicks Fix in PR (read on demand, not saved to the database); and the pull request comments, check runs and pull requests you ask for (workflow setup, fixes, cleanups).

  • Public scanner

    Trigger

    Pasting a public GitHub repository address into skylos.dev/scan

    What Skylos receives

    The same throwaway sandbox clones the public repository and scans it. The result is returned to your browser and not saved to any workspace; Skylos keeps only a rate-limit counter keyed by repository name.

  • Fix in PR

    Trigger

    An owner or admin clicks Fix in PR (it charges credits)

    What Skylos receives

    Skylos sends OpenAI, on Skylos's own key, the whole source file (up to 64 KiB) and the finding. The fix is pushed to a new branch and opened as a pull request for you to review.

  • Deep scan (VulnHunter)

    Trigger

    An owner or admin saves the workspace's own Anthropic API key, then someone starts a deep scan with a spending limit

    What Skylos receives

    The commit is cloned into a non-persistent Vercel Sandbox whose network then reaches only api.anthropic.com, where the sandbox firewall adds your key, and Skylos's results address. Code from the repository goes to Anthropic under your account. Skylos stores the findings, with snippets of up to 2,000 characters.

    Kept out, and caveats

    Your key never enters the sandbox: it is not in its environment, command line or files. Skylos shows only its last four characters.

Subprocessors

Every provider that receives customer data. The full list gives each one's data categories, location and when it is involved.

  • Vercel: Hosting for the web app, API and scheduled jobs; runtime error logs
  • Vercel Sandbox (Vercel): Temporary, isolated virtual machines for hosted scans: Cloud scans of connected repositories, the public /scan page and deep scans
  • Supabase: Postgres database, sign-in (Auth) and file storage
  • GitHub: Sign-in, the Skylos GitHub App and tokenless CI uploads (GitHub Actions OIDC)
  • Lemon Squeezy: Merchant of record: checkout, payments, invoices and sales tax
  • OpenAI: Fix in PR, on Skylos's own OpenAI API key
  • Anthropic: Deep scans (VulnHunter), on your workspace's own Anthropic API key
  • Resend: Transactional email: invitations, workspace deletion notices, weekly digest, reminders, onboarding and plan notices
  • Sentry: Server error reports for the maintainer
  • Cloudflare: DNS for skylos.dev and forwarding of email sent to founder@skylos.dev
  • Google (Gmail): The maintainer's mailbox, which receives forwarded founder@skylos.dev email
See data and locations for each

Data Processing Agreement

Skylos does not offer a Data Processing Agreement yet. Skylos is run by its founder as an individual, and is not registered as a company. If your review needs a DPA, email us before you buy.

No date is set for one. The button opens your email app with a message to founder@skylos.dev.

Ask about the DPA

AI features and whose key they use

Nothing is sent to an AI provider until a person starts one of these. Skylos does not train AI models. The CLI's own AI commands use the provider you configure and never pass through Skylos.

Fix in PR

Skylos's OpenAI key

Runs only when an owner or admin clicks it, and charges credits. Skylos reads the one source file (up to 64 KiB) from GitHub and sends it with the finding to OpenAI. The change is pushed to a new branch and opened as a pull request for you to review.

Deep scans (VulnHunter)

Your workspace's Anthropic key

An owner or admin saves the key; it is checked with Anthropic once, encrypted, and only its last four characters are shown. A scan sends code from the commit to Anthropic under your account, which Anthropic bills. The sandbox firewall adds the key to requests, so it never enters the sandbox. Owners and admins can delete the key at any time.

Skylos keeps AI results as findings or issue notes under the retention settings below. What OpenAI keeps follows OpenAI's API data terms for Skylos's account; what Anthropic keeps follows your Anthropic account's terms.

Retention and deletion

Workspace owners change these in Settings, under Data retention and the Danger zone.

Scan retentionIn place

Owners choose how long scan results are kept: 30, 90, 180 or 365 days on every plan, 730 or 1,095 days on paid plans, or no age limit. 30 days is the floor. A daily job deletes older scans and their findings, except each project's latest scan. Separately, each project keeps at most its newest 10 (Free), 500 (Workspace) or 10,000 (Enterprise) scans.

Workspace deletionIn place

An owner can delete a workspace from Settings by retyping its name after a recent sign-in. After a 7-day grace period, in which any owner can cancel, keys, tokens and integration credentials are revoked first, then all workspace data is deleted. A receipt with only a hashed workspace ID and counts is kept as proof.

People's own Skylos accounts, Lemon Squeezy's invoices and the provider's database backups (until they roll off) are not removed by workspace deletion.

Hosted-scan codeIn place

Repository copies exist only inside a non-persistent sandbox for the length of one scan. Staged upload files are removed from storage when the upload completes.

Code-vetted security checklist

These are statements we can tie back to repository code, config, or migrations. They are not a third-party audit opinion.

Authenticated workspace access

Dashboard routes use Supabase SSR sessions and organization membership checks before loading workspace data.

Code-vetted route and session controls

Single sign-on on request, and two-factor enforcement

SAML single sign-on is built but no workspace uses it yet. It is set up on request: email the Skylos team your identity provider's metadata URL and email domains, the team registers the provider with Supabase Auth, and a workspace owner then turns it on in Settings. Owners can require SSO or two-factor for a workspace, enforced for dashboard pages, browser-session API routes, and database row-level security on core workspace tables. Workspace owners stay exempt from the SSO requirement so they cannot be locked out. CLI, CI, and workspace API tokens are machine credentials and are not subject to these sign-in rules.

Code-vetted session policy and RLS

Role-based permissions

The app separates viewer, member, admin, and owner roles across 29 permissions. Credit-spending actions require a dedicated spend:credits permission.

Code-vetted permission matrix

Audit log and access review

Workspace changes are written to an audit log on every plan. On the Workspace, Growth and Enterprise plans, members can view and export it, read it through the /api/v1/audit-events API, and review members, invitations, admin-managed keys and uploads not tied to a member on an access review page.

Code-vetted audit events and API

Project token hashing

Project tokens are generated with the sk_live_ prefix and stored as SHA-256 hashes. Secondary tokens can be issued and revoked for rotation.

Code-vetted credential lifecycle

Encrypted third-party credentials

Deep-scan Anthropic keys, Jira, GitLab, Bitbucket and Azure DevOps tokens, and webhook signing secrets are encrypted with AES-256-GCM before they are stored. Slack and Discord webhook URLs are not encrypted this way.

Code-vetted credential stores

Throwaway sandboxes for hosted scans

Cloud scans, the public scanner and deep scans clone one commit into a new, non-persistent Vercel Sandbox that can reach only github.com. For private repositories the clone credential is read-only, limited to one repository and revoked after the clone. The network is then cut (for Cloud scans, limited to OSV for the dependency check; for deep scans, to Anthropic and Skylos), and the sandbox is stopped when the scan ends.

Code-vetted sandbox lifecycle

Restricted GitHub OIDC uploads

Tokenless CI accepts GitHub OIDC tokens only after issuer, audience, repository owner, push event, branch ref, and subject checks pass.

Code-vetted identity checks

Bounded report ingestion

Cloud report uploads cap request size, finding count, snippets, messages, and file paths before storing scan evidence.

Code-vetted upload limits

Security headers and CSP

App pages set a nonce-based Content Security Policy; static public pages use a stricter-origin policy that allows inline scripts. Every page sends HSTS, frame protection, no-sniff, referrer, and permissions-policy headers.

Code-vetted response headers

Retention controls and workspace deletion

Owners set how long scan results are kept, with a 30-day floor, and can delete a workspace after a 7-day grace period. Credentials are revoked before any data is removed, and a receipt without names or content records the deletion.

Code-vetted retention and deletion jobs

Safer CSV exports

CSV output goes through a shared encoder that quotes cells and neutralizes spreadsheet formula prefixes.

Code-vetted export encoder

Data Skylos Cloud may store

  • Workspace, organization, project, member, role, and billing metadata
  • Scan metadata such as project, commit, branch, tool version, upload method, and CI context
  • Finding records, rule identifiers, severity, file paths, line numbers, remediation state, and short code snippets
  • The git-blame author email of each uploaded finding's line
  • Optional AI provenance, defense, debt, and compliance evidence when those scan modes are uploaded
  • Team workflow records such as assignments, comments, suppressions, overrides, exception requests, and audit entries
  • Encrypted credentials for integrations a workspace connects, including a deep-scan Anthropic key

What we do not claim today

  • Skylos is not SOC 2 certified today.
  • Skylos does not claim ISO/IEC 27001 certification today.
  • Skylos does not claim CSA STAR certification or a paid third-party badge today.
  • Skylos does not offer SCIM provisioning, self-serve identity provider setup, dedicated tenancy, private networking, or formal data residency guarantees today.
  • Skylos does not publish a completed third-party penetration test report today.

Available now

  • Security overview page and Markdown download
  • Subprocessor list with data categories and locations
  • Data-flow statement for every path into Skylos Cloud
  • Retention settings and self-serve workspace deletion
  • Vulnerability disclosure contact and security.txt
  • Known compliance gap statement for SOC 2, ISO 27001, and CSA STAR

Roadmap

  • CAIQ-Lite answer file based on the current code-vetted checklist
  • Hosted status provider with incident history
  • Third-party penetration test summary
  • SOC 2 Security criteria control map before any auditor engagement
  • SCIM provisioning and enterprise OIDC SSO

Security review contact

Report vulnerabilities privately through GitHub private vulnerability reporting. For security questions, the DPA or report requests, email founder@skylos.dev or use the feedback form. This overview was last checked against the code on 9 November 2026.