Security at cleap

You grant access on GitHub's own screen, for every repository or only the ones you pick, and you can change or revoke it there at any time without asking us. Reads use a short-lived token scoped to that one grant, so cleap holds no standing access to your account.

Every table carries a rule about who may read or change each row, and those rules run inside Postgres on every query. This matters more than it sounds: the check is not in the page you are looking at, so a bug in our interface, or a request made without one at all, still cannot return another workspace's rows.

Within a workspace, roles decide the rest. Owners and admins manage people and billing, editors can annotate a map, viewers read. The tables holding your parsed code are reachable only by the service itself, never by a browser, whoever is holding it.

An API key, if you make one, is scoped to a single workspace and can be revoked without disturbing anyone else's.

An API key exists in full exactly once, on the screen that creates it. What we keep is a one-way hash, so a copy of our database does not hand anyone a working key. If you lose one, we cannot recover it, which is the point.

If you connect your own database for schema mapping, the connection string is encrypted with a separate key held outside the database, using AES-256-GCM with a fresh nonce each time.

Passwords are hashed by Supabase Auth with bcrypt. We never see them, and neither does our own service, which verifies your session by asking the identity provider rather than by inspecting the token itself.

Every request that changes something is validated against a schema before it reaches the database, so a malformed or oversized field is refused with a reason rather than stored. Size and rate limits sit in the database itself, where they apply to every caller rather than to one code path.

Every week a job connects to the live database and fails if any table has lost its access rules, because that is the single mistake with the worst outcome and the easiest one to make. The rule it applies is tested on every push, alongside the rest of the tests, the types and the linting.

The site sends a content security policy, so the browser refuses to load a script or contact a server that is not on a list we maintain, and reports anything it blocks back to us.

The models have no tools, no database access and no ability to act. They receive a slice of your map and return words. Anthropic's API terms do not permit training on it.

Because cleap reads other people's code, the code itself is treated as untrusted input: it arrives inside a marked boundary with explicit instructions that it is material to describe and never instructions to follow. A repository that contains text shaped like a command, whether by accident or design, does not get to change what cleap tells you about your system.

What was sent and what came back is logged so you can see your own history and so we can investigate a bad answer. Disconnect a repository and that text is erased.

For workspaces that need code to stay within their own account: a workspace owner or admin can set their own Anthropic API key in the workspace settings. When configured, cleap's AI features use that key instead of cleap's, so your code reaches Anthropic directly from your account, and billing goes to you. The key is encrypted at rest and never shown or copied after it is saved.

We name them because you will need this list before you can sign anything, and because the alternative is a security questionnaire and a week of waiting.

We will tell existing customers before adding a company to this list that can see repository-derived data.

Write to hello@cleap.dev with “security” in the subject. Please do not open a public issue for anything exploitable. Machine-readable contact details are at /.well-known/security.txt, in the format researchers' tooling looks for.

What helps. Enough to reproduce it: the address or endpoint, what you sent, what came back, and what you think it lets someone do. A proof of concept is welcome. Video is rarely as useful as the request.

What we ask. Test against your own account and your own repositories. Please do not run automated scanners against the live service, degrade it for other people, or access, change or keep anyone else's data. If you reach someone else's data by accident, stop and tell us what you saw so we can measure it.

In scope. cleap.dev and app.cleap.dev, api.cleap.dev, the cleap-ingest GitHub App, and the public showcase maps.

Out of scope. Anything needing physical access, a stolen device or social engineering. Scanner output with no demonstrated impact. Missing headers or version disclosure with no exploitable consequence. Denial of service through sheer volume. And the companies in section 6, which have their own programmes.

We will not pursue anyone who reports in good faith under these terms. We will credit you by name if you would like that, and tell you what changed and when it shipped. There is no bounty yet, and the reason is in the next section.

No SOC 2 report. We are a small team and an audit covering a period we have barely existed for would certify very little. If a deal depends on it, tell us and we will start the clock.

No independent penetration test yet. Worth commissioning once, and worth it far more after the recent round of internal fixes than before.

No single sign-on. Two-step sign-in with an authenticator app is available on your account page. Requiring it of a whole workspace is not built yet, and that is the version an administrator actually wants.

One region. Everything runs in the United States. We cannot offer a residency commitment today.

No bug bounty. Answering reports quickly has to come before paying for them, and we would rather be good at the first thing before advertising the second.