Start with what is available today
Mini Hound is live with Free and Plus plans, operating through a verified origin requirement. The Free plan operates at $0 per month with $1 in expiring monthly credits, running exclusively on the v1 Gemini 3.8 Flash model. The Plus plan costs $4.99 per month with $5 in expiring monthly credits, supporting both v1 Gemini 3.8 Flash and Pro Gemini 3.1 Pro preview via Google Cloud. Credits charge at twice the actual provider tokens to account for reasoning overhead. Users can configure low, medium, high, or max hard execution budgets for their tasks. Live capabilities include public source review, bounded isolated browser checks, evidence-backed candidates, owner-configured synthetic retests, and entitled private API and MCP access via the /api/mcp endpoint and account/targets/review/retest paths.
Broader BloodHound assessments, editor extensions, and The customer MCP includes account-scoped browser, search and fetch tools; deployment and service configuration determine availability. They remain strictly in development. Our four development ambitions for these future capabilities are 99.9% platform uptime, 24/7 monitoring, 99.9% finding accuracy, and 5x faster testing. We intend to work toward them through reliability engineering, evidence-based verification, and repeatable evaluation. None is a guarantee. If measurements do not support a figure, we will need to change the target or communicate the shortfall rather than redefine success after the test. Security reviews are evidence-limited, and this service does not automatically change code.
99.9% uptime: define the service before measuring it
The reliability plan starts with user-visible Service Level Indicators (SLIs), as established in Google SRE Chapter 4: Service Level Objectives. The indicator must answer whether an authorized user can submit a supported assessment, obtain its status, and retrieve a completed report. Website availability alone would not establish assessment-service availability. We need separate measures for successful requests, queue delay, job completion, and dependency failures. An SLI is a carefully defined quantitative measure of some aspect of the level of service that is provided, distinct from a Service Level Objective (SLO), which is a target value or range of values for that service level.
A 99.9% time-based availability target allows 0.1% unavailability, which translates to roughly 43.2 minutes in a 30-day measurement window. That is an illustration of the arithmetic used for our error budgets, not a live outage allowance or Service Level Agreement. Request-based availability uses a different denominator. Before launch, we must publish the actual indicator, measurement window, exclusions, and failure definition so results can be accurately interpreted by application engineers relying on the API.
Work toward this target includes durable job state, idempotent operations, bounded retries, health checks, controlled releases, backup restoration tests, and dependency failure handling. A repeated request must not start duplicate assessments, as this exhausts the user's hard execution budget unnecessarily. A worker failure must leave a recoverable state. Implementation tradeoffs here often pit latency against durability; we prioritize strict durability for job state. We plan to validate recovery through deliberate failure exercises before describing resilience as proven.
24/7 monitoring: continuous supervision without uncontrolled testing
Around-the-clock monitoring describes when a future service can supervise authorized targets; it does not mean every target is attacked continuously or every vulnerability is detected immediately. Each assessment still needs an approved scope, rate limits, exclusion rules, test credentials where appropriate, and a mechanism for the verified owner to stop work immediately via the API. The proposed design uses durable schedules, worker heartbeats, expiring job leases, and alerts for missed checks.
Permission changes and target removal must stop future work immediately. A target outage should trigger a bounded backoff sequence, not an uncontrolled retry storm that degrades the target's infrastructure. We will measure missed runs, detection delay for supported changes, and time to recover from worker failure. Failure modes include zombie workers that lose their lease but continue executing network requests; this is mitigated by isolated, ephemeral browser execution contexts with hard-coded time-to-live limits.
Availability of monitoring is also different from staffed 24/7 incident response. We have not announced a round-the-clock response team or a response-time commitment. Those services must not be implied by the automated monitoring target.
Safe test matrix and expected outcomes
To ensure bounded execution and adherence to authorization boundaries, we employ a strict testing matrix to validate allowed and denied operational states during assessment execution. This matrix dictates how the agent handles various network and scope conditions.
Condition: Target resolves to an internal RFC 1918 IP address. Expected outcome: Denied execution, immediately halted. Condition: Target URL matches the verified origin domain exactly. Expected outcome: Allowed execution, subject to execution budget. Condition: Target URL redirects to an unverified third-party domain. Expected outcome: Denied execution on the redirect target, execution halted. Condition: API request exceeds the configured max hard execution budget. Expected outcome: Denied execution, status returned as budget_exceeded. Condition: Authentication required but no test credentials supplied. Expected outcome: Allowed execution for unauthenticated surface area only, flagged as incomplete coverage.
99.9% finding accuracy: evidence quality comes first
Accuracy is too vague to use as a standalone security benchmark. A future evaluation must report at least precision—the share of reported findings confirmed to be valid—and recall—the share of known, in-scope vulnerabilities that were found. High precision with poor coverage is not complete protection, and suppressing uncertain findings cannot be used to hide missed issues. As outlined in the OWASP Web Security Testing Guide, comprehensive security testing requires structured methodologies rather than isolated tool runs.
Our engineering direction separates model-generated hypotheses from confirmed findings. A finding must identify the affected boundary, the permitted scope, a reproducible observation, the security impact, and a way to verify remediation. Unsupported hypotheses should remain clearly marked for human review rather than silently becoming verified reports. Implementation tradeoffs here involve execution budgets: verifying a complex hypothesis consumes more tokens, heavily impacting the user's hard execution budget, particularly when using Pro Gemini 3.1 Pro which charges credits at twice the token count for reasoning.
To investigate the 99.9% ambition, we require a versioned benchmark spanning supported vulnerability classes and representative application patterns, including negative cases. Ground truth, sample size, independent adjudication, confidence intervals, and exclusions all matter. A small hand-picked set with no false positives cannot justify a universal claim. Results must be broken down by supported class and scope.
5x faster: compare equivalent work and include review time
The speed plan focuses on work that can be safely reused or performed concurrently: deduplicating discovered routes, caching public resources within a run, parallelizing independent checks under rate limits, and avoiding repeated model calls when deterministic checks suffice. None of these techniques permits exceeding a target’s authorized request budget or authorized origin boundary.
A fair comparison requires the same application version, scope, credentials, finding standard, and deliverable for both workflows. It must include setup, execution, analyst review, false-positive triage, and report preparation. Saving automated scan time while simultaneously increasing manual verification work would not establish a faster overall assessment. We would report elapsed time and human effort separately, across repeated runs and different application sizes.
Consider a hypothetical synthetic worked example: A test fixture application containing exactly 15 deterministic injection flaws and 5 business logic flaws. A traditional manual review might take 40 hours of setup, execution, and reporting. The proposed 5x speed target requires the entire lifecycle—including the time the user spends reviewing the agent's output via the MCP endpoint—to complete in 8 hours without degrading recall. We have no published benchmark demonstrating that result today.
Explicit limits of evidence
The next credible milestone is a reproducible, limited evaluation, not a larger marketing number. The required artifacts to prove our targets include a supported-capability and limitation matrix, versioned test fixtures with synthetic data, known vulnerable and fixed cases, documented ground truth, and explicit authorization boundaries. These are roadmap commitments to a methodology.
Evidence limits are strict: we will not extrapolate results from a single test fixture to generalize performance across diverse architectures. If a specific framework is excluded from the test matrix, we make no claims about accuracy or speed for that framework. Visible corrections will be published when later evidence changes a previously published result.
- A supported-capability and limitation matrix detailing credential requirements and intentional exclusions.
- Versioned test fixtures with synthetic data and explicit authorization boundaries.
- Reliability measurements with a declared service indicator, sample window, and incident accounting.
- Precision and recall results with sample sizes, review criteria, uncertainty, and per-category breakdowns.
- A timing comparison with equivalent scope, including human review effort.
References and sources
Google SRE Chapter 4 outlines the distinction between Service Level Indicators, Objectives, and Agreements, and the necessity of defining what behaviors actually matter for service reliability. The OWASP Web Security Testing Guide informs our approach to comprehensive vulnerability coverage and the structural requirements for security findings.
Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.
Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.
Prepared with AI assistance and published by WarHound AI. Check the references and evidence limits in each article.
The WarHoundAI journalQuestions or a factual correction? Get in touch with the article URL and supporting evidence.