How it works

What Vibe Check actually does.

Vibe Check is the security product inside Chat, the platform that lets one person run a company.

The security workflow uses a multi-model ensemble approach plus a 26-specialist operating system. Repository evidence is reviewed, disputed, narrowed, and packaged into a report a founder or engineer can actually use.

The stack

A multi-model ensemble with explicit roles.

1

Primary AI reviewer

primary AI provider

Primary semantic review and exploitability framing in the ensemble.

2

Second AI reviewer

independent AI compute

Independent adversarial review and remediation challenge pass.

3

Third AI reviewer

independent AI compute

Adjudication support and discrepancy resolution inside the review approach.

What we scan for

Six categories. Narrow claims. Useful output.

Injection

Input-to-sink paths where user-controlled data can reach databases, shells, or templating engines.

Example: Example finding: a request parameter reaches a SQL query builder without parameterization.

  • CWE-89
  • CWE-77
  • CWE-94

Authentication & access control

Broken ownership checks, session handling gaps, CSRF exposure, and authentication bypass behavior.

Example: Example finding: a user can access another tenant’s resource by changing an object identifier.

  • CWE-639
  • CWE-352
  • CWE-613

Data exposure

Hardcoded secrets, sensitive data leaks, SSRF, XXE, and repository evidence that points to accidental exposure.

Example: Example finding: a production API key is committed in a server config file.

  • CWE-798
  • CWE-611
  • CWE-918

Infrastructure risk

Database policy mistakes, dependency drift, and destructive configuration that can expand blast radius.

Example: Example finding: a Supabase table is writable without row-level restrictions.

  • CWE-284
  • CWE-1104
  • CWE-16

Shadow AI & abuse vectors

Unauthenticated model endpoints, debug leftovers, mass assignment, and hidden system surfaces.

Example: Example finding: an internal model endpoint is exposed without authorization guards.

  • CWE-306
  • CWE-915
  • CWE-489

Code quality & defensive gaps

Path traversal, insecure deserialization, IDOR, and other defensive failures that become exploitable.

Example: Example finding: file download routes allow attacker-controlled relative path traversal.

  • CWE-22
  • CWE-502
  • CWE-639

Cross-check architecture

Five-stage review pipeline.

01

Fetch

Repository contents are fetched from GitHub, normalized, and chunked into analyzable slices.

The pipeline starts from repository evidence, not prompts or guesses.

02

Analyze

Three independent AI reviewers inspect the same code slice and tag likely vulnerabilities.

The point is disagreement visibility, not a single model sounding confident.

03

Cross-check

Candidate findings are compared, deduplicated, and normalized into issues worth founder attention.

A single loud model is not enough to make the report.

04

PoC gate

Candidate findings must identify a concrete sink, attacker-controlled input path, and impact statement before they move forward.

Claims that depend on missing runtime evidence stay descriptive instead of overstated.

05

Report

Verified findings are assembled into the final customer-facing report with remediation guidance.

Output is designed for use, not just documentation.

Verification rates

Accuracy disclosure

Verification rates publish here after legal review.

Candidate findings are challenged, narrowed, and promoted only when the repository evidence supports the claim. Public verification percentages publish here only after legal review.

Read the trust posture

Operational transparency

What you can inspect.

Public commit log

Review the build story behind Chat and Vibe Check and see how the system moved from idea to working product.

Build velocity dashboard

Inspect the operating rhythm behind a 26-specialist workforce.

Model uptime and trust posture

Review the current trust framing before you rely on the product.