Changelog

Hannibal, Guard's autonomous penetration testing capability, has gone from an External-and-Cloud hunt agent to something a security team runs on its own terms. Web applications and LLM endpoints are first-class attack surfaces now, and hunts against them can authenticate, so the agent tests what a logged-in user actually reaches rather than the login wall. You set how aggressively a hunt pivots, what it may spend, when it is allowed to run, and what tag its findings carry — all self-service, without routing through Praetorian. Hunts also know when to stop: a quality backstop scores finding severity over a trailing window and completes the run when the bar is no longer met. And the whole workflow is now drivable from the terminal.

What's New

New: web application and LLM attack surfaces

• Web Applications — the Launch Hannibal dialog offers Web Applications alongside External and Cloud, scoping the run to the webapplication asset class and executing a purpose-built web hunt pipeline that is separate from the external-network and cloud hunt logic.
• LLM endpoints — LLMs are a first-class surface option, scoping the hunt to assets that prior discovery classified as carrying an LLM or AI attack surface and routing to a dedicated LLM red-teaming workflow rather than the generic web or cloud path. Risks found during an LLM hunt are correctly tagged with the LLM attack surface and appear under surface-filtered views.

Credentialed hunts: past the login wall

• Authenticated web application hunts — an unauthenticated scan only ever sees the login wall, and that is not where web application risk lives. Web Application hunts accept static credentials, basic login, SSO, and TOTP, threading them into the hunt so the agent tests the authenticated attack surface.
• Credentialed LLM hunts — API keys or session credentials can be supplied for LLM surfaces, so credential-gated endpoints are tested rather than skipped.
• Credentials that stay available mid-hunt — recorded application credentials are resolved from the HAS_CREDENTIAL graph relationship rather than from the credential pin alone. Agents previously fell back to the Guard tenant email even when a valid recorded credential existed, which made webauth_replay silently disappear from the toolset partway through a hunt; the tool now stays available whenever credentials are present and valid.

You decide how hard the agent pushes

• Aggressiveness dial — choose Cautious, Balanced, or Aggressive when launching or scheduling a hunt. Cautious caps dispatch breadth; Balanced and Aggressive differ in pivoting depth and attack-chain length. It is a dedicated, explained step in the Launch Hannibal wizard, each level presented as a card with a description, and it applies equally to on-demand and scheduled hunts.
• Attack-path recording — the higher aggressiveness tiers record the full attack path taken, so results surface multi-step exploit chains rather than isolated single findings.

Self-service scheduling for autonomous penetration tests

• No Praetorian in the loop — launching or scheduling an autonomous penetration test previously meant routing through Praetorian, and the workflow sat behind super-admin budget steps. Customers now configure and schedule Hannibal pentests directly from AI Settings — hunt mandates, guardrails, severity targets, sources, and scan profiles — on their own timeline.
• Purpose-built settings cards — hunt scheduling and AI budget configuration are separate cards. The Schedule Autonomous Penetration Test card carries the scheduling toggle and hunt profiles with deep-link support via URL parameters and expands in place rather than opening a modal; Category Allocation is its own card with its own edit modal, available to manage-settings users independently of the budget cap; the AI Spend card is slimmed to the monthly cap and usage meter, with a budget-only, super-admin-gated edit modal. The Automatic Findings Validation (Cato) card received the same accordion treatment, so both AI-driven capabilities configure consistently.
• Schedules with a full API — per-tenant schedules associate an asset target with a capability (Hannibal or Constantine), a cadence of daily, weekly, or monthly, and an optional day and time in UTC. Manage them through GET, POST, PUT, and DELETE on /hunt/schedules. Schedules are stored as a tenant setting, so each team independently controls scope, agent type, and the prompt used for auto-created hunts. A "Hunt scheduling" step appears in the AI spend configuration wizard when a hunts budget allocation is set, wiring budget to cadence.
• A reliable off switch — hunt_schedule.enabled set to false previously did not stop the auto-hunt cron from firing and consuming budget. It now gates all automatic pentest activity, both scheduled auto-hunts and emergent-threat kickoffs, while manual hunt creation remains available. It defaults to enabled with no custom profiles required, so existing configurations are unaffected.
• Scan-window compliance — automated hunts could start iterations outside a tenant's configured scan launch window, undermining the control customers use to limit when offensive activity runs. Auto-hunt-created hunts are now marked automated and every iteration is gated to the scan window; ticks falling outside it are dropped rather than parked, so hunts do not stall. Operator- and chat-initiated runs keep their ability to bypass the schedule, and parked jobs no longer appear as in-flight, so the hunt queue reflects actual activity.

Spend controls at the level of a single run

• Surge budget overlay — fund a hunt or a Marcus session from a Praetorian-managed surge budget that runs independently of the customer's monthly credit pool. Select it from the Hannibal launch panel or the Marcus composer budget dropdown; surge spend is COGS-accounted and never drawn from the monthly pool.
• Per-run budget cap — set an optional spending ceiling on an individual hunt at launch. The hunt stops when the cap is reached regardless of findings or other finish criteria, so a single run cannot exhaust an allocation.

Hunts that know when they are done

• Quality-based completion backstop — rather than running indefinitely or stopping only on a time or budget limit, a hunt scores a trailing 8-hour window after an initial grace period using severity weights (critical 10, high 7, medium 2) and marks itself complete when it falls below a two-medium-equivalent threshold. Hunt results stay meaningful and operator attention is freed.
• Distinct completion states and notification — hunts completed by the backstop are distinguished from user-initiated stops, and operators receive a Chariot Slack alert when the backstop fires.
• No finding bypasses triage — all triage classes, not only high and critical, automatically spawn a Cato triage job after filing, so every finding is automatically evaluated regardless of its initial classification.

Finding a hunt's results afterwards

• Per-hunt custom tags — the Finish criteria & duration step of the launch wizard takes an optional Custom Tag (for example Q4_Application_Hunt). It threads from the launch payload through the Hunt model onto every finding the hunt files, alongside the built-in hunt and agent-reported tags, and is filterable in the Assets and Risks views through the existing tag query controls.
• Hunt-tag asset labeling — assets selected for a hunt are tagged automatically, so the scope of any given run is easy to filter and review.
• The hunt drawer shows everything — the drawer defaulted to Demonstrated findings only, so a hunt with no compromises yet looked like it had returned nothing at all. It now lists every finding associated with the hunt across all lifecycle states — Demonstrated, Detected, and the rest — sorted by criticality, with the most recent item ranked highest within each severity tier. The spurious "No Vulnerabilities match your current filter" empty state is gone.

A more reliable agent

• No more fabricated-evidence storms — hunts could silently burn up to a third of their runtime retrying evidence IDs the model had invented from memory, filing zero findings on labs it had already solved. A list_evidence tool now hands the agent the ground-truth set of collected evidence IDs before it calls report_new_risk, eliminating a cycle that reached roughly 100 failed calls per run, and unresolvable evidence references now fail fast instead of amplifying one fabrication into a storm.

New: full Hunt management from the terminal

• Interactive launch wizard — praetorian-cli launches External, Internal, Cloud, Web Application, and LLM Application hunts with surface-specific scope selection, mandate configuration, aggressiveness, duration, model tier, and run-scoped credentials.
• Live hunt chat and steering — a continuously refreshed agent conversation view with an inline guidance composer, full-history pagination, expandable tool-call detail, Markdown rendering, and pending-interaction indicators.
• Memory browser and editor — navigate, open, edit, save, and delete hunt memory items in a persistent keyboard-driven interface; system-owned entries stay read-only.
• Approvals and credential requests — list and watch pending human-in-the-loop interactions across root iterations and nested subagents, render endpoint approval context, and answer credential requests through the secure broker flow.
• Scheduled hunt profiles — list, inspect, create, edit, pause, resume, and delete reusable scheduled hunt profiles, kept clearly separate from generic capability schedules.
• Cost and operational overview — projected cost in USD, remaining time, root agent and iteration counts, highest vulnerability severity, and scope summary are integrated into hunt status output.
• Workflow deep-links — jump from an agent-backed workflow step straight to its hunt conversation and back to the same step, matching the web UI's workflow-to-chat navigation.

Aurelian has widened from AWS configuration auditing into genuine multi-cloud exposure detection. It now sweeps Azure for publicly reachable resources through Resource Graph queries, continues to catch the AWS misconfigurations that lead to credential theft, and scans AWS secrets incrementally so repeat runs no longer re-examine everything that has not changed.

What's New

New: Azure public resource detection

• Publicly reachable resources across the subscription — Aurelian's Azure reconnaissance uses Azure Resource Graph queries to find exposed storage, networking, database, and application-layer resources, and surfaces confirmed exposures as findings. Covered today: Storage containers configured for public blob or container access, standalone public IP resources, load balancers with public frontend configurations, Azure SQL instances reachable from the internet, Network Security Groups with overly permissive inbound rules, and App Service resources without access restrictions.
• Structured output — detections are emitted as CloudResource objects carrying public-access properties, with Risk objects raised for confirmed exposures, so Azure exposure lands in the same model as the rest of Guard's cloud data.

AWS configuration auditing

• EC2 IMDSv1 detection — instances left on IMDSv1 (HttpTokens=optional) are open to SSRF-based IAM credential theft, a well-travelled cloud attack path. Aurelian enumerates EC2 instances across the account and emits a Medium-severity risk for each instance that still permits IMDSv1, surfaced in the Guard vulnerability view alongside other cloud posture issues.

Faster, broader AWS secret scanning

• Checkpoint-based incremental scans — the last successful scan checkpoint is passed to Aurelian and persisted only after a fully successful run (with a one-minute overlap), so unchanged AWS resources are not re-scanned on every pass.
• Full ECS task definition scanning — the complete ECS task definition is now forwarded to the secret scanner, bringing environment variables and configuration embedded in task definitions into scope.
• Resource Access Manager share enumeration — the list-all reconnaissance path now enumerates AWS RAM resource shares, recording principals, shared resources, and whether AllowExternalPrincipals is set, so cross-account sharing is visible rather than assumed.

Augustus, Guard's AI security testing capability, has taken on an entirely new attack surface: Model Context Protocol servers. MCP servers expose tools, resources, and prompt templates to a model, and nothing in conventional web-application testing reaches them. Augustus now discovers, fingerprints, authenticates against, and adversarially probes MCP deployments end to end — covering the OWASP MCP Top 10 — and delivers each result as a self-contained finding with a CVSS v4.0 vector, a CWE tag, and reproduction steps. Its multimodal coverage has grown alongside: image and PDF attack probes now run against more model families, and scan verdicts finally distinguish an injection that was obeyed from one that never landed.

What's New

New: MCP servers are discovered, fingerprinted, and routed automatically

• Endpoint auto-discovery — MCP servers are an emerging and frequently unmonitored surface, so for any public domain asset Guard probes the conventional mcp.<domain> host and, when it resolves, emits it as a discovered asset for identification. MCP servers you did not know you had now appear in your attack surface inventory.
• Julius fingerprinting — an mcp-server probe identifies Model Context Protocol servers (JSON-RPC 2.0 over the Streamable HTTP transport, spec 2025-06-18) and types them as Type = "mcp", distinguishing them from generic LLM inference endpoints.
• Julius → Augustus, with no manual wiring — typed MCP assets are picked up automatically and the MCP probe pattern is applied; the Augustus generator configuration Julius emits is forwarded intact, preserving probe scope. Vespasian's MCP probe likewise emits a ready-to-use generator config on detection.
• Agentic workflows too — an orchestrator agent that discovers an endpoint fingerprinted as an MCP server now hands it to Augustus exactly as the deterministic path does, so agentic hunts no longer leave MCP targets untested. The Augustus agent can also invoke MCP probes directly by passing generator_type: mcp.
• MCP reconnaissance panel — discovered MCP servers surface a dedicated LLM-Recon panel in Guard showing server identity, the tool/resource/prompt catalog, and identity recon results.

A first-class MCP generator and recon layer

• MCP generator — Augustus speaks MCP (JSON-RPC 2.0) to target servers over stdio, streamable HTTP, legacy SSE, and auto-detected transports, so MCP endpoints are tested the same way REST, GraphQL, and gRPC targets are.
• Reconnaissance module family — a class of modules gathers target facts as observations rather than verdicts, feeding downstream probes structured context about the exposed tool surface. Recon modules can consume earlier modules' observations, so chained discovery — identifier enumeration feeding straight into authorization tests — needs no manual wiring.
• Full paginated catalog enumeration — only the first page of a server's tool, resource, resource-template, and prompt catalogs used to be retrieved. All pages are now followed via nextCursor, removing silent under-coverage against servers with large catalogs.
• Full JSON Schema traversal — probe arguments are built by resolving nested properties, $ref, allOf, anyOf, oneOf, and if/then constructs rather than top-level properties alone. Tools that previously looked covered while generating schema-validation errors are now genuinely exercised, so reported attack surface matches tested attack surface.

What the MCP probes actually test

• Injection across all three MCP primitives — tool poisoning and tool-parameter injection, resource-content injection (OWASP MCP06, where adversarial instructions embedded in a resources/read response steer the host model), and prompt-template poisoning (OWASP MCP10, probing prompts/get templates for injected instructions — the indirect-injection class behind real-world GitHub, Supabase, and Atlassian incidents). Resources and prompt templates are model-facing surfaces that went entirely untested before.
• OS command injection (OWASP MCP05) — the most prevalent vulnerability class in deployed MCP servers, at roughly 43% ecosystem prevalence. Shell-metacharacter payloads are injected into tool inputs and detected both in-band and blind, via out-of-band callbacks, catching sinks that return nothing to the client. Directly covers the CVE-2025-6514 and CVE-2025-53355 patterns that the earlier arithmetic-canary probe missed.
• Broken Object-Level Authorization — requests referencing object identifiers belonging to other users or sessions surface servers that trust caller-supplied IDs without re-validating ownership.
• Authentication and authorisation (OWASP MCP07) — probes for unauthenticated access at the HTTP transport layer, weak token validation, missing or bypassable authorisation on tool calls, and privilege-escalation paths across MCP sessions.
• Path traversal and SSRF — OS-file traversal payloads are injected into path-like tool parameters and reads detected by file-content signature, respecting allowed-prefix declarations in tool descriptions; SSRF probes cover server-side request abuse from tool handlers.
• Transport-layer attacks — DNS rebinding (coercing tool handlers into requests to attacker-controlled origins by exploiting TTL expiry), SSE session fixation and cross-session data leakage, and Origin-header validation bypass.
• Credential exposure on every surface — API keys, tokens, database credentials, and cloud-provider secrets are detected in MCP server configurations at rest, in live tool responses, and — newly — in resources, prompt templates, and other non-tool surfaces. A server advertising plaintext credentials in a resource would previously have scored as safe.

Findings you can act on without leaving the page

• Structured security write-ups — each of the eight MCP probes (Tool Injection, SSRF, BOLA, Path Traversal, Response Leak, Origin Validation, SSE Session Hijack, Credential Exposure) carries a curated description of the issue and its consequences, actionable remediation guidance, CWE identifiers and supporting references, and a conservatively-scored CVSS v4.0 vector. No external lookup required to understand what was found or how to fix it.
• Reproduction guidance — all eight probes also emit a dedicated Verification field in their RiskInfo: static, reproduction-oriented prose describing exactly how the probe confirmed the vulnerability and the steps to reproduce it manually, kept separate from the finding description so triage and escalation have a clear path.
• Calibrated language — finding titles, descriptions, and severity justifications were reviewed and corrected to reflect what the evidence actually supports, consistent with pentest report standards, rather than overstating impact.
• Aggregated Origin findings — Origin-header bypass variants are reported as one consolidated finding per server instead of ten separate rows, removing noise that used to dominate output on benign servers.

Accuracy: fewer missed findings, fewer false ones

• Tool-surface false negatives resolved — four measured false negatives in the path-traversal, injection, SSRF, and response-leak probes are fixed; the probes were reaching their targets and discarding valid evidence.
• Measured benchmark gain — coverage on the DVMCP challenge benchmark advanced from 1 of 10 to 4 of 10 solved challenges, before counting further gains from the authentication and credential probes.
• Cross-probe contamination fixed — detectors are scoped per probe in multi-probe runs, so verdicts from unrelated detectors no longer contaminate results.
• Authenticated tests that actually authenticate — credentials attached to the asset or integration in Guard are looked up and forwarded to MCP and HTTP probes, with per-asset credential scoping and a model-availability pre-flight check before probes execute, hardening runs against silent misconfiguration.

Broader multimodal attack coverage

• Image-based attack probes — three paper-faithful probes, including FigStep, each reproducing the original peer-reviewed attack methodology against vision-capable models, reaching attack paths text-only probes cannot.
• PDF probes on Google models — multimodal document probes previously ran only against Anthropic models. Native document content blocks are now wired through both Google generators, so pdf.* probes execute against Gemini and Vertex AI instead of silently dropping the document payload.
• A four-way scan verdict — results now distinguish no injection, injection attempted but resisted, injection obeyed with a benign canary, and injection obeyed with harmful effect. A visible-channel injection the model obeys scores 0.5 and renders as its own intermediate verdict rather than 0.1/SAFE, so "injection obeyed" is no longer indistinguishable from "nothing happened."
• Errors reported as errors — probes that fail before reaching the model (auth failure, timeout, transport error) are surfaced as errors instead of silent passes, so a broken scan cannot look like a clean result.
• Newest Claude model support — the Anthropic generator no longer sends a hardcoded temperature parameter, enabling scans against claude-sonnet-5 and claude-opus-4 class models that rejected the field.