Autonomous penetration testing in the Praetorian Guard Platform has changed shape.
Hannibal started as a hunt agent for external and cloud attack surfaces. Today, it’s something your security team can run entirely on its own terms.
Web applications and LLM endpoints are now first-class attack surfaces. Hunts can authenticate into applications, test what a real logged-in user can reach, and follow multi-step attack paths instead of stopping at the login wall.
And the control stays with you.
You decide how aggressively Hannibal operates, when hunts are allowed to run, how much a run can spend, what assets are in scope, and how findings are organized afterward. Hunts can be launched on demand, scheduled to run automatically, and managed directly from the Guard Platform or the command line.
Here’s what’s new.
Autonomous penetration testing expands to web applications and LLMs
Hannibal now supports dedicated hunt workflows for external, cloud, web application, and LLM attack surfaces.
Web applications
Web Application hunts use a purpose-built testing workflow separate from external network and cloud testing.
More importantly, Hannibal can now test the authenticated application surface.
Web Application hunts support static credentials, basic login, SSO, and TOTP, allowing the agent to move beyond the public-facing login page and test the functionality and attack paths available to authenticated users.
LLM endpoints
LLMs are now a first-class attack surface in the Guard Platform.
Hannibal scopes hunts to assets that discovery has classified as having an LLM or AI attack surface, routing them into a dedicated LLM red-teaming workflow rather than treating them like a generic web application.
LLM hunts can also use API keys or session credentials to reach credential-gated endpoints.
Findings are tagged by attack surface so teams can easily isolate and review risks discovered through LLM testing.
Choose how aggressively Hannibal operates
Not every environment should be tested the same way.
When launching or scheduling a hunt, teams can choose between three aggressiveness levels:
- Cautious limits dispatch breadth.
- Balanced allows greater pivoting and attack-chain depth.
- Aggressive gives Hannibal more room to pursue longer, multi-step attack paths.
Higher aggressiveness levels also preserve the full attack path, helping teams understand how individual weaknesses can connect into a larger exploit chain.
The setting applies to both on-demand and scheduled hunts, giving security teams a straightforward way to match autonomous testing to the environment and use case.
Run autonomous pentests on your schedule
Autonomous testing no longer has to be routed through Praetorian.
Customers can configure and schedule Hannibal directly from AI Settings in the Guard Platform, including hunt mandates, guardrails, severity targets, sources, scan profiles, and timing.
Scheduled hunts can run daily, weekly, or monthly and can target specific assets and capabilities. For teams that want to wire scheduling into their own automation, schedules are fully managed through GET
, POST
, PUT
, and DELETE
on /hunt/schedules
.
Teams can also configure scan windows so automated offensive activity only begins during approved testing periods.
That means Hannibal can become part of a recurring security program instead of something that has to be manually coordinated every time you want to test.
Control the cost of every run
Autonomous testing should not mean unpredictable spend.
The Guard Platform now provides several layers of cost control.
Per-run budget limits
Teams can set an optional spending ceiling when launching an individual hunt.
When Hannibal reaches that limit, the hunt stops regardless of its other completion criteria. That prevents a single run from consuming more of the allocated budget than intended.
Monthly AI spend controls
Teams can manage overall AI spend through a monthly cap and usage meter, providing visibility into consumption across autonomous capabilities.
Optional surge budget
A Praetorian-managed surge budget can also be used for specific Hannibal hunts or sessions with Marcus, the interactive agent, without drawing from the normal monthly credit pool.
Together, these controls give teams flexibility to run more intensive testing when needed while keeping overall spend predictable.
Hunts know when they’re finished
An autonomous pentest shouldn’t run indefinitely simply because nobody told it to stop.
Hannibal now evaluates the productivity of a hunt over a trailing eight-hour window after an initial grace period.
Findings are weighted by severity:
- Critical: 10
- High: 7
- Medium: 2
When the score falls below the equivalent of two medium findings, Hannibal marks the hunt complete.
Teams can still limit runs by time or budget, but Hannibal can now recognize when continued testing is producing diminishing returns and end the hunt automatically.
Findings are easier to organize and review
Autonomous testing becomes much more useful when teams can easily separate one hunt from another.
Hannibal now supports custom tags at launch. A team could, for example, apply a tag such as Q4_Application_Hunt
, and that tag will carry through to every finding produced during the run.
Assets selected for a hunt are also automatically associated with that hunt, making it easier to review the scope later.
The hunt drawer now shows findings across lifecycle states, including both Demonstrated and Detected findings, rather than only displaying successful compromises.
That gives teams a more complete view of what Hannibal observed during the engagement.
More reliable evidence and findings
Hannibal has also improved how it validates evidence before reporting a risk.
Previously, a hunt could burn up to a third of its runtime retrying evidence IDs the model had invented from memory, in cycles that reached roughly 100 failed calls per run, occasionally filing zero findings on environments it had already compromised.
The agent now references the ground-truth set of evidence collected during the hunt before filing a finding. Invalid evidence references fail quickly rather than triggering unnecessary retries, so a single bad reference no longer cascades.
The result is a more reliable path from autonomous testing to validated security findings.
The Guard Platform’s automated findings validation capability, Cato, now evaluates findings across all triage classes rather than only high- and critical-severity findings.
Full hunt management from the command line
For teams that prefer working in a terminal, praetorian-cli
now covers the full Hannibal workflow.
Teams can:
- Launch External, Internal, Cloud, Web Application, and LLM Application hunts.
- Select scope, credentials, aggressiveness, duration, and model tier.
- View live hunt conversations and provide guidance while an agent is running.
- Review agent tool calls and activity.
- Manage persistent hunt memory.
- Respond to approval and credential requests.
- Create, inspect, pause, resume, and delete scheduled hunt profiles.
- Review projected cost, remaining time, agent activity, severity, and scope.
- Move directly between Guard Platform workflow steps and their associated hunt conversations.
Autonomous testing can now be operated end to end from the terminal.
Autonomous pentesting with guardrails
The shift here is bigger than adding a few new attack surfaces.
Hannibal is becoming something security teams can operate continuously themselves.
The goal isn’t autonomy without oversight. It’s giving security teams an autonomous offensive capability they can actually control.
Common questions about autonomous penetration testing
What is Hannibal?
Hannibal is the autonomous penetration testing capability in the Praetorian Guard Platform. It runs AI-driven hunts against external, cloud, web application, and LLM attack surfaces, follows multi-step attack paths, and files findings with supporting evidence.
Can autonomous penetration testing get past a login screen?
Yes. Hannibal Web Application hunts support static credentials, basic login, SSO, and TOTP, allowing the agent to test authenticated application functionality instead of stopping at the login page.
LLM hunts can also use API keys or session credentials to reach protected endpoints.
Can you run an autonomous pentest against an LLM?
Yes. LLM endpoints are a first-class attack surface in the Guard Platform.
Hannibal scopes the hunt to assets that discovery has classified as having an LLM or AI attack surface and routes them into a dedicated LLM red-teaming workflow.
How do you control the cost of an autonomous penetration test?
The Guard Platform provides several layers of cost control, including a monthly AI spend cap, an optional per-run budget ceiling, and an optional Praetorian-managed surge budget that operates independently of the normal monthly credit pool.
How long does an autonomous pentest run?
Hannibal can stop based on time, budget, or productivity.
After an initial grace period, Hannibal evaluates a trailing eight-hour window using weighted finding severity. When the hunt stops producing enough meaningful results, it can automatically mark itself complete.
Do you need Praetorian to launch a hunt?
No.
Customers can configure, launch, and schedule Hannibal pentests directly from the Guard Platform, including mandates, guardrails, severity targets, cadence, credentials, budgets, and scan windows.
The workflow is also available through praetorian-cli
.
The short version
Hannibal now reaches more of the attack surface that matters, including authenticated web applications and LLM endpoints, while giving you more control over how autonomous testing operates.
Your scope.
Your schedule.
Your scan window.
Your budget.
Your results.
You no longer have to wait on Praetorian to launch an autonomous penetration test.
You just run one.
Want to see what Hannibal finds in your environment? Schedule a Guard demo.