What does Wardloom check before deployment?

Wardloom covers twelve security check families: secrets, CORS, security headers, dependency CVEs, config exposure, auth and session flaws, IDOR and ownerless endpoints, debug artifacts, deployment readiness, LLM and agent security, plus advisory traffic-readiness and legal/privacy signals. On live URLs it also runs deterministic SEO and GEO/AEO audits, Core Web Vitals, and a light crawl. Verify control of your domain and eight read-only live deployment checks unlock on top.

Is Wardloom safe? Does it store my code?

Yes. Wardloom is a strictly benign, read-only tool for reviewing code and deployments you own. It never executes your code, never runs exploits, and never fuzzes your application. Submitted code goes to the analyzer transiently and is never written to a database, and secret values are redacted before anything is stored or displayed.

What is the Ship-Readiness score?

Ship-Readiness is the headline of every Wardloom report: one number that answers whether an app is finished and safe to launch. On repository scans it combines the deterministic Vibe-Check Security Score (0 to 100, weighted 65%) with a Completion Score (35%), and it can never read higher than the security score while a critical or high finding is open, coverage was truncated, or the authorization surface went untested. Alongside it sits a pass, warn, or block gate and Launch Confidence, which weights security, SEO, health, and GEO.

What are verified-deployment checks?

Verified-deployment checks are eight live checks that run only after you prove you control the domain, using a DNS TXT record or a file at a /.well-known path. They cover dangling DNS records, exposed administration routes, directory listings, GraphQL introspection, public API documentation, HTTPS enforcement, TLS certificate health, and verbose error pages. All of them are read-only GET requests and DNS lookups against a fixed path list — never fuzzing, never an exploit attempt.

Can Wardloom run inside Claude Code, Cursor, or another AI coding agent?

Yes. Wardloom ships an MCP server — npx -y wardloom-mcp — that connects to Claude Code, Cursor, and any MCP client. It exposes seven tools: local_precheck for a fast scan that stays on your machine, start_scan and get_scan_status, check_deploy_ready for the ship gate, get_findings, get_remediation_roadmap, and get_handoff_prompt. Create an API key from your dashboard, paste one config block, and tell your agent to check the app before it ships. API access is available on every plan.

Can Wardloom gate my CI pipeline?

Yes. The Wardloom Ship-Readiness Gate is a GitHub Action that scans a repository or a deployed URL on every pipeline run and fails the build when the result falls below your score threshold. The same endpoints are available directly as an authenticated HTTP API, with idempotency keys, stable error codes, and a scan-to-scan delta so you can see what changed since the last run.

How do I fix the issues Wardloom finds?

Every report includes a phased remediation roadmap ordered by severity and effort, plus a copy-pasteable Dev/AI handoff prompt — a benign, defensive refactoring request you can paste into Cursor or Claude, or hand to a teammate. On Pro, Guided Fixing proposes validated diffs and rescans afterwards to confirm the issue is actually gone. Reports export to PDF and HTML, and every one states plainly what was not tested.

Does Wardloom keep checking after I launch?

Yes. Turn on monitoring for a project and Wardloom re-scans it daily or weekly, emails you when something regresses, and sends a monthly summary. Scan-to-scan comparison shows what was fixed, what is new, and what is still open, and Pro and Team can publish a shareable Ship-Readiness certificate that carries scores and coverage honesty without exposing any finding detail.

Field notes

Lessons for builders who ship at the speed of thought.

Practical writing on vibe-coded security, launch readiness, and discoverability, edited for founders who want calm, useful guidance.

Classical scholar at a desk, studying what the machine wrote

2026-07-10 · 7 min read

What is a vibe-coded app, and why does it fail security review?

A clear definition of vibe coding, the security mistakes AI-built apps commonly ship with, and the review habits that make them ready for launch.

Read note

Classical figure at a table, preparing deliberately for launch

2026-07-11 · 8 min read

The launch checklist AI tools skip

A practical pre-deploy checklist for AI-built apps, covering secrets, CORS, headers, auth, debug artifacts, dependencies, and discoverability.

Read note

Classical engraved helmet, used as a metaphor for credential protection

2026-07-12 · 6 min read

Hardcoded API keys in client bundles: how they leak, and how to fix them

Why AI-generated frontends leave API keys in JavaScript bundles, how people find them, and how to remediate the issue without slowing the team down.

Read note

Classical pastoral landscape, suggesting calm clarity for discoverability

2026-07-13 · 9 min read

SEO vs GEO vs AEO for indie apps

A 2026 primer on search engine optimization, generative engine optimization, and answer engine optimization, with a practical order of operations for indie apps.

Read note

Classical armor and shield, showing layered defense before launch

2026-07-14 · 6 min read

Launch Confidence: why a security score is only part of the picture

Why Wardloom combines security, SEO, health, and GEO into Launch Confidence, and how to read the Vibe-Check gate with more nuance.

Read note

Classical group of careful builders, handing work forward safely

2026-07-15 · 7 min read

Safe handoff prompts: fixing vibe-coded apps with Cursor and Claude

How to send remediation prompts into AI coding tools without slipping into exploit language or vague, low-quality fix requests.

Read note