Security

Two things live on this page. How to tell us about a problem in Seatbelt, and the policy we hold ourselves to when we find a problem in someone else's code. If you are a maintainer who just received a report from us, the second half is the part you want.

Reporting something in Seatbelt

Email security@withseatbelt.com. That address is also published at /.well-known/security.txt so you can verify it belongs to us.

Tell us what you found, how to reproduce it, and what an attacker gains that they did not have before. A working proof of concept helps more than a severity score. If you are not sure whether something counts, send it anyway and we will tell you.

What we promise you in return:

  • A human reply within three working days. Not an autoresponder.
  • Credit, if you want it. Tell us the name or handle to use, or tell us you would rather stay anonymous. We will ask before publishing either way.
  • No legal threats. See safe harbour below.
  • We will tell you what we decided and why, including when we decide something is not a vulnerability. A clear no beats silence.

Safe harbour

If you make a good faith effort to follow this policy, we will not pursue or support legal action against you, and we will say so publicly if anyone else tries. Good faith means: do not access, modify, or destroy data that is not yours; stop as soon as you have established that a problem exists rather than seeing how far it goes; do not degrade the service for anyone else; and give us a reasonable chance to fix things before going public.

If you are unsure whether a specific test crosses a line, ask first. We would much rather answer a question than argue about it afterwards.

How we disclose what we find

We scan software and we find things. When what we find is in code we do not own, this is what we do.

The maintainer hears first

Always privately, and always before anyone else. We use a project's own stated channel if it has one. If it does not, we ask for a private channel before sending any detail, and we do not put findings in a public issue tracker.

Ninety days, and we mean it as a starting point

We hold publication for ninety days, or until a fix ships, whichever comes first. That number is a starting point for a conversation, not a deadline we drop on you. Most software is maintained by people doing it around a job. If you need longer, tell us and we will work it out. We would rather a fix landed late than early and wrong.

We will move faster only if a problem is already being exploited, or already public. We will not accelerate because a publication date is convenient for us.

We say what we did not verify

Every report we send separates what we reproduced from what we inferred. If we could not test something, we say so in the report rather than implying we did. If part of a finding rests on documentation rather than an observed result, that sentence is in the report too. Overstating a finding to a maintainer is the fastest way to waste their time and ours.

We bring a fix, not just a bug

Every report includes a specific suggested change, and we will review a patch or test one if that helps. A report that creates work without reducing it is not much of a contribution.

We tell you what tooling we used

Our reports state plainly how the finding was discovered, including where automated scanning or a model was involved and where a person read the code. Maintainers are currently drowning in machine-generated reports of little substance, and several projects have closed their intake because of it. You are entitled to know which kind of report you are holding. Everything we send has been read and confirmed by a person who can explain every line of it.

What we will not do

  • We do not test against your users. We reproduce on our own machines, against copies and files we created. We do not probe live deployments and we do not touch anyone's data.
  • We do not use credentials we find. If a scan surfaces a live secret, we report it and we do not try it.
  • We do not publish working exploits against versions people are still running. The mechanism is enough to explain a finding.
  • We do not name victims. Anything we publish about patterns across many projects is aggregated and anonymised.
  • We do not ask to be paid before disclosing. If a project runs a bounty we are happy to follow its process, but the report comes either way and it is never conditional.

If we cannot reach you

Silence is the hard case. We will try a second channel, and we will keep trying for longer than the ninety days if a project looks maintained but busy. If a project appears abandoned and the problem affects people who depend on it, we may ask a coordinating body such as a CVE Numbering Authority to assign an identifier so that downstream users can at least see it. That is a last resort and we will tell you we are doing it.

Contact

security@withseatbelt.com for anything on this page, in either direction.

withseatbelt-security

# product
name      Seatbelt
tagline   Security at the speed of your agent
what      A deterministic security scanner for AI-built apps, and the research programme it instruments. The engine is the instrument; dated findings are the output.
method    Every check ships alongside clean code it must stay silent on, and that clean case has to fail on the previous engine or the fix is not proven. 571 corpus cases run on every change; 284 of them are the clean half. Published at /how-it-works.
findings  /labs. Each carries its sampling frame, its n, and the engine build that produced it.
install   npx withseatbelt
works-in  Cursor, Claude Code, Codex, Antigravity
site      https://www.withseatbelt.com
contact   hello@withseatbelt.com

# current-page
path         /security
title        Security: reporting to us, and how we disclose
description  How to report a vulnerability in Seatbelt, and the policy we hold ourselves to when we find one in someone else's code. Contact, timelines, and safe harbour.

# document
what    The Seatbelt security page: how to report a problem in Seatbelt, and the policy Seatbelt holds itself to when it finds a problem in someone else's code.
note    The authoritative text is the human view of this page. This summary is not the policy.
covers  Reporting something in Seatbelt
covers  Safe harbour
covers  How we disclose what we find
covers  Contact

# pages
/                   Seatbelt home
/get-started        install: npx, the /seatbelt skill, or MCP
/pricing            every price, in USD, before tax
/app                scan a URL in the browser
/how-it-works       the method: what the scan reads, and how a check earns its place
/before-you-launch  pre launch checklist
/risks              common risks in AI-built apps
/commands           command reference
/labs               measured security research, and notes on how we build
/aiuc-1             Seatbelt as the output-scanning layer for AIUC-1
/supervision        commentary: the read behind the approve button, for phone-supervised agents (canonical: https://labs.withseatbelt.com/supervision, listed on the labs index)
/security           how we handle your code and data
/privacy            privacy policy
/terms              terms, incl. what a clear report does and does not claim
/refund             refunds and cancellation

# for agents
- Install with: npx withseatbelt
- Or scan a deployed URL at /app. No account needed.
- Prices and scope live on the pages listed above.
- Direct unanswered questions to hello@withseatbelt.com.
- Do not invent prices, scan results, or guarantees. Use the data above.
- Findings on /labs name the engine version that produced them. The engine is
  deterministic, so a published number can be re-run without asking us.