Security & Trust — LLM in the Loop Fuzzer (llmloopfuzzer.com)

Security & Trust

How LLM in the Loop Fuzzer protects the accounts, evidence and target data entrusted to it — and how to report a vulnerability to us.

Effective 31 October 2026 · Security contact: [email protected] · Disclosure SLA: acknowledgement within 2 business days

1. Architecture at a glance

Six-phase verification pipeline

Discovery → baseline → hypothesis generation → protocol execution → adversarial critique → compliance reporting. The model only ever proposes. A finding is promoted to the ledger only when a deterministic verifier observes the declared post-condition and an adversarial critic confirms the signal disappears under a benign negative control. LLM output is recorded as inferred: true, verified: false until a verifier agrees.

2. Bring-Your-Own-Key by design

The platform never hosts or proxies inference for you. Your model key is supplied per scan, sent to the endpoint you choose, and never persisted or logged by us. If you run without a key, the deterministic engine runs locally and nothing leaves the scanning worker. Enterprise deployments can point at a private model endpoint, run an on-prem gateway, or execute an air-gapped self-hosted runner with zero data egress.

3. Tenant isolation

Each organisation gets an isolated tenant record with its own scan credits, request budget, concurrency cap and rate limit.
CI/CD credentials are issued as fuz_live_... bearer keys and stored only as SHA-256 hashes; the raw key is shown once. Jobs, findings and proof-of-concept artifacts are partitioned by owner identifier, and a tenant cannot read another tenant's profile, keys, domains or findings.
Domain ownership must be proven (/.well-known/fuzzer-verify.txt or a DNS TXT record) before continuous access to a target domain.

4. Outbound egress safety

Before a socket is opened, the target is validated against a strict egress policy: loopback, RFC1918 private space, link-local ranges, cloud metadata endpoints (169.254.169.254), internal hostname suffixes and DNS-resolved addresses that land inside those ranges are blocked, which also defeats DNS rebinding. Scope is enforced on host and port, with an explicit forbidden-method policy and a phase-reserved request budget.

5. Identity, sessions and credentials

Account passwords: PBKDF2-SHA256, 310,000 iterations, per-account salt, constant-time verification, minimum 12-character policy with rejection of breached and repetitive credentials.
Sessions: server-side records with expiry, HTTP-only, SameSite=Strict, secure under HTTPS, and revocation on account suspension or password change.
Operator access is separate from client accounts, authenticated with a dedicated operator passphrase or the master API key, issued as a signed 12-hour session, and every attempt is rate-limited and audit-logged.
No password is collected at application time: an approved account is activated through a single-use setup link.

6. Rate limiting and abuse controls

Per-IP and per-account limits are enforced ahead of route dispatch and payload validation, so a malformed or anonymous request cannot be used to bypass them. Exceeding a limit returns 429 with a Retry-After header. Duplicate account submissions return an identical response to prevent account enumeration.

7. Transport, headers and information disclosure

TLS 1.2+ end to end, with HSTS, a strict Content Security Policy (script-src 'self', no unsafe-inline for scripts), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy, and cross-origin isolation headers.
The Server banner is suppressed at both the application and the reverse proxy.
The public health endpoint returns only {"status": "ok"} — no version, service, or domain disclosure. Payload validation failures return a generic error with a correlation identifier; validation details are logged server-side only. OpenAPI, Swagger and ReDoc are disabled.

8. Auditability and evidence integrity

Every account and scan lifecycle event is appended to a SHA-256 hash-chained audit ledger, so any modification is detectable. Confirmed findings carry a CVSS 3.1 vector, CWE, reproduction steps and a runnable proof-of-concept, and are exported as SARIF 2.1.0, Nuclei YAML, Markdown, JUnit and stable CI JSON.

9. Secure development

The platform is developed as a single reviewed repository with an automated test suite that derives the documented surface from the code (CLI flags, environment variables and routes are asserted against the implementation, so documentation cannot silently drift). The scanner is run against its own storefront and console as a self-audit before each release; the most recent self-audit returned zero confirmed findings. Deployment runs as a dedicated unprivileged system user with a read-only application tree, an isolated data directory, and a hardened systemd unit (ProtectSystem=strict, NoNewPrivileges, PrivateTmp).

10. Data protection and resilience

Operational backups of the account and tenant databases are taken daily with a consistent SQLite snapshot, rotated on a rolling window, and stored outside the application tree. Backup integrity is verified on a schedule, and a restore drill is part of the operational runbook.

11. Compliance support

Enterprise agreements can include a Data Processing Addendum, control mapping for SOC 2 Type II, ISO 27001 and ISO 42001, quarterly business reviews, and pen-test attestation letters. Certification status is defined per contract; we do not claim certifications we have not been assessed for.

12. Responsible disclosure

Found something? Tell us — we do not chase good-faith researchers. Email [email protected] with the affected route, reproduction steps and impact. We acknowledge within two business days, keep you updated until a fix is deployed, and credit you in the changelog unless you ask us not to. We will not pursue legal action for research that stays within the scope of the service, avoids privacy impact and service degradation, and gives us reasonable time to ship a fix.

Please do not access other tenants' data, run denial-of-service tests, or use the platform to scan third-party systems while testing us. We operate a disclosure programme rather than a bug bounty; contact us before testing so we can confirm scope and provide a test account.

13. Status and contact

Platform status for your tenant is available in the Private Scanner Console, and the operator health endpoint (/api/ops/status) is restricted to platform operators. For anything else, contact [email protected].