arrow_backBack to docs
TRUST & SAFETY

The authorization model

We only scan what you've explicitly authorized. Every scan requires domain ownership verification or repo-level authorization, signed and logged before we run a single check. Nothing is scanned silently.

How authorization works

Every scan target goes through the same two-step gate, regardless of whether the scan is later triggered from the dashboard, the REST API, or an MCP-connected agent:

  1. Prove you control the target. For a website, that means placing a DNS TXT record on the domain before any scanning begins. For a repository, that means authorizing VibeScan's GitHub OAuth app for read access to that specific repo.
  2. Sign a per-target authorization. A separate consent form, specific to that domain or repo, listing exactly which check categories you're allowing, captured with an e-signature and an explicit confirmation that you have the legal authority to authorize testing on that asset.

This isn't a one-time global opt-in — each domain and each repository gets its own signed record. Adding a second domain later means signing a second authorization.

What's explicitly authorized

The authorization form lists every check category by name before you sign — nothing runs that wasn't on that list.

"Passive scanning, header checks, dependency/CVE checks, and light active checks only."

Website scans

HDRSecurity headers (incl. CORS, version fingerprinting)
TLSTLS/SSL config
CVEDependency/CVE checks
SECExposed secrets/paths (incl. admin panels, GraphQL introspection)
CKYCookie security flags

Repository scans

SASTStatic code analysis (injection, unsafe eval, SSRF, path traversal, missing auth)
PYPython-specific security scan
CVEDependency vulnerability scan
SECSecret detection in files and git history
CFGInfrastructure & config audit (Dockerfiles, Kubernetes, Terraform)

Strict prohibitions

block

Never authorized

No destructive testing, no data exfiltration, and no automated exploitation beyond confirming a vulnerability exists. Stress testing, DDoS, and social engineering are not authorized under this model, regardless of what check categories were signed off.

What gets recorded

Each signed authorization creates a record containing:

  • Which check categories were authorized
  • Confirmation that you attested to having the legal authority to authorize testing
  • That an e-signature was captured
  • Timestamp and IP address at the moment of signing

These records are append-only — signing again for the same target adds a new record rather than overwriting the old one — and are retained as evidence of authorization even after you delete your account, since they exist to prove what was and wasn't authorized. See Privacy Policy §7.

What we do — and don't — capture during a scan

  • Secrets: detection runs with redaction enabled — we record that a credential-like pattern was matched and where (file and line), never the value itself.
  • Exposed paths: if a website check finds a sensitive path (e.g. an exposed .env) publicly reachable, we record the fact and the path — never its contents.
  • Repository source: a temporary clone is made to run the analysis and deleted immediately after the scan completes or fails. Source code is never retained.
  • Report generation: only redacted finding data (what was found, why it matters, file/line or path) is sent to our report-translation provider — never your account identity or raw source.

Revoking access

  • Disconnect GitHub from Settings to delete the stored OAuth token immediately — this doesn't undo an already-completed scan, but prevents future ones.
  • Delete your account from Settings to permanently remove your scans, findings, connections, and subscription — everything except the append-only authorization records described above.

Related reading