How we operate, ethically and securely.
BleedWatch is built for teams that need more than a generic ASM dashboard. We combine public-surface monitoring, build-artifact deep scanning, EU-first infrastructure, and founder-led expert review under one documented trust line.
The large platforms are excellent at broad coverage. Our differentiation is depth where production exposure actually happens: published NPM and PyPI contents, Docker layers, sourcemaps, mobile binaries, GitHub Actions workflows, AI agent posture, and sandboxed active validation through the SaintScan MCP gateway.
Boundaries first, evidence second.
Security monitoring loses trust when it blurs authorization. These principles are how we keep every scan, validation, and disclosure bounded.
Authorization & scope
We scan only the public surface a customer authorizes: domains, repositories, registries, packages, workflows, and artifacts tied to that tenant. Scope is recorded before execution so review, billing, and security all reference the same boundary.
OSINT-only by default
Default scans observe public artifacts and metadata. Active validation is opt-in, separately authorized, and routed through SaintScan so every tool invocation has policy, scope, rate, image, and audit controls before execution.
No plaintext secrets
Secrets are never persisted in plaintext. Evidence stores deterministic hashes such as sha256:abc12345..., truncated previews, source context, and remediation metadata. Full values stay out of logs, queues, emails, and dashboards.
Hard limits
No infrastructure access, no exploitation, no credential testing, no destructive checks, and no unbounded probing. When a finding requires deeper validation, we ask for written authorization and record the approved method.
What leaves the platform, and what does not.
A security vendor should practice what it preaches. The first DPA question is always the same: what data crosses our boundary, where does it go, can it be turned off, and who else handles it. Below is the exact answer.
DETECTION PIPELINE - DATA FLOW
Six stages. Five run on our EU infrastructure. Only one - semantic LLM validation - uses an external API, and only on truncated, redacted material.
- 01
Regex matching
200+ regex patterns, ReDoS-audited bounds, line-truncated input.
Local - 02
False-positive filter
Heuristic + context filter eliminates known sample/test/docs strings.
Local - 03
Entropy scoring
Shannon entropy + structural checks classify high-confidence candidates.
Local - 04
ONNX classification
On-device neural classifier ranks survivors before any external call.
Local - 05
Semantic AI (LLM)
Sanitized payloads sent to Anthropic API: sensitive identifiers replaced with HMAC tokens, per-tenant salt, sanitizer_version + audit trail per call.
External API - 06
Dedup & persist
Hash-based dedup, evidence stored as sha256 + truncated preview only.
Local
What we send to the LLM
Sensitive identifiers (IPs, hostnames, secrets, paths, emails, CPEs, service names) are replaced with deterministic HMAC tokens before any call leaves the platform. Tokens are salted per tenant, so cross-tenant correlation by the LLM provider is mathematically impossible. Full secret values, dependency graphs, and client metadata are never sent.
Sanitization envelope (M20b)
Every LLM call carries a sanitizer_version, a per-tenant HMAC salt, and a sanitization audit record (tokens emitted, bypass reason if any). Five per-cluster killswitch flags (CVE / SaintScan / EASM / Sentinel / Misc) let operations pause LLM traffic per call site in seconds without redeploying. Token rehydration happens on our side after the response, so downstream dashboards and DB persistence keep the real values - the LLM provider only ever sees tokens.
No training on your data
Under Anthropic commercial terms / DPA, API inputs and outputs are not used to train generative models unless an organization explicitly opts in to a model-improvement program. BleedWatch operates without that opt-in. Retention and zero-data-retention configuration follows Anthropic's commercial controls and is reflected in our DPA.
On-device ML first
The first four pipeline stages run entirely on our infrastructure: regex matching, false-positive filtering, entropy scoring, and ONNX classification. The LLM is invoked only for semantic validation of uncertain findings.
AI-Off mode
Customers in regulated sectors (defense, banking, sovereign) can disable LLM-based semantic validation entirely. The trade-off is a higher false-positive rate, but zero data leaves the platform. Configurable per-organization in settings.
Controls that survive procurement scrutiny.
We document the concrete enforcement point for each claim: key boundary, query boundary, execution boundary, residency boundary, or incident boundary.
KMS proxy
Envelope encryption uses AES-256-GCM with per-tenant data encryption keys. The master key never leaves the Cloudflare Worker boundary, and application services receive only mediated encrypt/decrypt operations.
PostgreSQL RLS
Tenant isolation is enforced at the query layer. Phase 1 tables such as findings, scans, assets, and saintscan_* routes go through row-level security policies instead of relying only on application checks.
MCP Gateway (SaintScan)
Sandboxed active validation passes through allowlisted binaries, scope validation, argv sanitization, digest-pinned container images, policy gates, circuit breakers, and immutable audit inserts.
Read the architectureAI-Alliance Challenging
BleedWatch detection patterns, high-impact rules, and architectural decisions go through internal multi-model peer review during development - Claude, Gemini, Codex, and Mimo are used as steel-man reviewers against our own engineering work. This is an internal methodology that improves detection quality before release; customer scan data only crosses our boundary to Anthropic for semantic validation at runtime, as documented in section 02.
EU residency
Primary infrastructure runs in the EU with AES-256-GCM at rest. There is no US fallback for customer data unless a customer explicitly opts into a provider path requiring transfer safeguards.
Bot/scanner protections
The platform is protected with WAF rules, scanner user-agent blocks, honeypot paths, per-route rate limits, and security headers across the marketing site, app, and API surfaces.
Cookieless analytics
Marketing analytics run on Umami self-hosted at analytics.bleedwatch.com - no cookies, no PII, no cross-site tracking, no third-party processor. We do not deploy Google Analytics, Hotjar, FullStory, Microsoft Clarity, or any tool that fingerprints visitors across sites. Aggregate page views and custom events stay on our own EU infrastructure.
Defense layers beyond the architecture pillars.
KMS proxy, PostgreSQL RLS, MCP gateway, and bot/scanner protections are documented above in Architecture Pillars. The controls below are additional defense-in-depth layers enforced in production today.
Anti-SSRF & DNS rebinding
All user-provided URLs (webhooks, SIEM endpoints, callbacks) pass through SSRF validation with DNS anti-rebinding. Private IPs (RFC 1918), loopback, IMDS (169.254/16), and IPv6 link-local ranges are blocked before any request leaves the platform.
Ephemeral secret store
Secrets never appear in plaintext on the job queue. We use an ephemeral secret store with UUID references - the actual value is consumed once and deleted. Cache and queue introspection tools show only opaque IDs, never the value.
ReDoS protection
All detection patterns are audited with safe-regex2. Input is truncated to 10 KB per line and 2 MB per file. Quantifiers are bounded; nested quantifiers are forbidden. CI fails any pattern that introduces unbounded backtracking risk.
Security headers
HSTS, Content-Security-Policy, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, and Permissions-Policy are enforced at three levels: Caddy reverse proxy, Next.js frontend, and Fastify API.
RBAC & audit trail
Three-tier role model (admin / client / viewer) with granular permissions per resource. Sensitive actions are logged asynchronously to an immutable audit table with multiple event types and a 90-day retention default. RLS policies prevent tenant cross-reads at the database layer.
Rate limiting (per-route, distributed)
Per-route distributed rate limits applied across the API surface - AI endpoints, standard read/write, Shield verify, and unauthenticated public routes each have their own bucket. The marketing /scan proxy adds an additional per-IP limit (5/hour, 10/day, GitHub orgs 1/hour) before forwarding to the API. Trusted edges authenticate to the API via X-Proxy-Secret to gate forwarded-IP trust against rate-limit bypass via header forgery.
Where customer data lives, by service.
Primary storage and processing happens in the EU. The full breakdown by service is below - when in doubt, ask procurement to map this against your tenancy and tier.
| Region | Services |
|---|---|
| EU edge | KMS proxy at the edge boundary - encryption key mediation. The master KEK never leaves the edge runtime and is not extractable by application services. |
| EU (Hetzner, Germany) | Primary application tier - encrypted relational database, in-memory cache, job queue workers, scanner engine, API server, and marketing site. |
| Anthropic API | Semantic AI validation only - HMAC-tokenized payloads, per-tenant salt, sanitizer_version audited per call. Processing location per Anthropic configuration; commercial terms / DPA apply. No full secrets, no client metadata; incidental PII inside scanned code snippets is tokenized or redacted at the sanitization envelope. |
| Edge CDN | Static assets and documentation cache. No customer data is cached at the edge. |
Mapped controls, with honest status labels.
Target dates are aspirational planning markers, not contractual promises. Enterprise customers can request the current evidence pack and control inventory during procurement.
| Framework | Status | Target | Evidence chain |
|---|---|---|---|
| SOC 2 | In progress | Target Q3 2026 | Change management, audit trails, encryption controls, incident response, access review. |
| ISO 27001 | Mapped | Target 2027 | Annex A control mapping, supplier review, risk register, secure development lifecycle. |
| PCI-DSS | Controls mapped | Evidence pack on request | Secure software controls, vulnerability management, logging, least privilege, segmentation assumptions. |
| NIS2 | Evidence chain | Operational mapping | Supply-chain management, incident handling, business continuity, access controls, vulnerability disclosure. |
| DORA | Mapped | Financial-sector pack | ICT third-party tracking, incident classification, operational resilience, auditability. |
| GDPR / RGPD | DPA + RoPA | Available on request | EU residency, sub-processor register, data subject rights, retention, breach notification. |
Built for the surfaces broad platforms skip.
Wiz, Snyk, GitGuardian, Censys, and Mandiant ASM are excellent at what they do. They are also large, US-based, and built for the F500 procurement cycle. We built BleedWatch differently: founder-led, EU-first, transparent pricing, AI-augmented methodology, and depth on the surfaces those tools skip.
Docker layers, NPM published files, PyPI packages, sourcemaps, mobile binaries, GitHub Actions injection, and AI agent posture are first-class surfaces here. When continuous monitoring is not enough, our sister practice at labs.bleedwatch.com runs founder-led expert audits with the same AI-Alliance Challenging methodology.
ONE TRUST LINE
Platform plus expert audit.
Two products, one founder, one methodology. Public benchmark data is available for teams comparing breadth, depth, false-positive handling, and artifact coverage.
Read the benchmarkBreach notification is a process, not a slogan.
If BleedWatch determines that a personal-data breach affects customer data, we notify affected customers without undue delay and support the 72-hour GDPR notification window. Channels include email to configured admins, a status-page update when public disclosure is appropriate, and an in-app banner for authenticated users.
Report issues to us directly.
Security researchers should use the responsible disclosure policy, including scope, SLA, safe harbor, reward tiers, and hall of fame handling.
PGP: BLDW 2026 FPR 8E2A 91B4 7D13 C0DE 138A 4F62 9C10 7BEERead disclosure policyCritical processors are listed publicly.
The table below is abbreviated. The full list includes infrastructure, LLM compute, transactional email, billing, analytics, scheduling, and optional integrations.
| Processor | Purpose | Data | Region |
|---|---|---|---|
| Anthropic | LLM compute | HMAC-tokenized payloads, per-tenant salt, sanitizer_version audited, no plaintext secrets | Per Anthropic configuration |
| Cloudflare | KMS proxy + DDoS | Encrypted key mediation, DNS, edge telemetry | EU edge |
| Hetzner | Primary infrastructure | Customer data, scans, findings, assets | EU (Germany) |
| Stripe | Billing | Billing details only | EU |
Available on request for enterprise review.
We share security materials under appropriate evaluation terms. The goal is to give procurement, security, and legal teams evidence instead of vague claims.
Request artifactsSECURITY CONTACT
Direct line to security.
For security questions, vulnerability reports, DPA reviews, or enterprise procurement evaluations, email [email protected]. We commit to acknowledging reports within 24 hours and provide PGP-encrypted communication on request.
DATA PROCESSING AGREEMENT
DPA available for Enterprise plans.
A signed DPA is available for all Enterprise plans, aligned with GDPR Art. 28 controller/processor obligations. Contact us to request a copy aligned with your jurisdiction, supplemented with the current sub-processor register and EU residency confirmation.
Need a security review package?
Send the team, due date, regulatory context, and whether active validation or AI review is in scope.