“In the age of AI, all that matters is exploitability and reachability.”
Nathan Sportsman, Founder and CEO, Praetorian
Module 01Attack Surface Management
Start with a domain. See what an adversary would find.
No integration required to begin. Guard works outward from a single domain the way an operator opens an engagement: WHOIS records, EDGAR filings, acquisitions, favicon hashes, certificate transparency. Connect your cloud accounts and systems of record, and Guard reconciles that outside-in picture against your inventory, then shows you the gap between them.
The gap is usually where the risk lives: a domain that came with an acquisition and never made it into the CMDB, a cloud account nobody remembered. And it moves. An ephemeral Lambda appears, gets scanned, and is queued for testing before a quarterly scan would have seen it at all.
Module 02Vulnerability Management
A finding is a claim until something exploits it.
Everything enters as a claim. Resolved means re-proven.
A single agent handed a broad objective will invent things. Guard's specialists are narrow by design: one discipline, one toolset, so their output is checkable. Then it gets checked anyway, because an LLM can produce a convincing exploit writeup for a vulnerability that never existed. Nothing reaches your team until the exploit has actually run.
Findings arrive as claims, not facts. Guard's own scanners, Tenable, Wiz, Qualys, a threat feed, a bug bounty submission — all of it has to survive proof.
Simple checks settle what's provable outright: a version number, an open port, a response header. Anything that needs interpretation goes to a reasoning agent instead.
Then an agent detonates the exploit against the live asset. Only that step cuts a ticket, and the ticket carries the evidence.
Mark it fixed and Guard re-runs the exploit. Resolved means re-proven. For code, it opens a pull request.
Module 03Continuous Penetration Testing
A target and an objective. Everything else is a dial.
Testing that runs on your cadence, not your auditor's.
Guard runs a fleet of named agents, each built for one discipline. Marcus is the orchestrator.
Marcus, Guard's orchestrator, plans the engagement and delegates to specialists: credential attacks, web application, cloud, secrets and supply chain, LLM interfaces. Each sub-agent receives only the tool calls its specialization needs. That boundary is enforced in code, not in a prompt. Narrow scope is also why the work holds up. A specialist with five tools makes fewer mistakes than a generalist with fifty.
Set the cadence: weekly against the perimeter, authenticated every two weeks, cloud nightly.
The annual assessment still comes with the subscription, time-boxed to the dates you pick. You're not trading it away for continuous coverage. You're getting the other fifty-one weeks.
Module 04Red Team
The path Guard actually walked.
Ask for the graph. Guard draws the chain it actually walked: the exposed portal without SSO, the token it found on the way, the role it assumed, the objective it reached. Some chains are two hops. Some run through half your environment.
Because the asset graph, the technology map, and the Active Directory paths are pre-computed, agents spend their compute on the attack instead of re-learning your environment every run.
You set the objective and the rules of engagement. Aggressive mode takes the host, then the DMZ, then keeps going until it reaches the objective or hits a boundary you defined. Destructive actions are off unless you turn them on, and one control stops the fleet.
Module 05Breach and Attack Simulation
Did anything catch it?
Simulation is only useful against techniques that apply to you.
Guard re-detonates the chains it already proved in your environment, then queries CrowdStrike, Defender, or Splunk to ask what surfaced. What comes back is a MITRE ATT&CK® gap analysis of the TTPs your stack missed.
Not a library of generic adversary behavior. The attacks that actually worked against you, run against the tools you bought to catch them.
Module 06Threat Intelligence
A CVE drops. Guard already knows if it touches you.
Guard already holds the technology map, so the CVE is matched against what you actually run, turned into a check, and detonated against those hosts inside your authorized scope. What you get back is a list of the ones where it worked.
When an exploit is public but unweaponized, an agent pulls the repository, builds it in a sandbox, and makes it work. Then it runs through the same verification pipeline as any other claim.
Offense that runs like a program, not an event.
Guard moves through the year in phases rather than showing up once. Spend most of it overt, so your loop is faster than the attacker's.
Point products are inputs. Guard is the outcome.
Every category below is something an operator needs on the way to an answer. None of them is the answer. Guard runs them as modules, or ingests the ones you already own, and uses them to find where you actually get compromised.
None of it is required to start. Point Guard at one domain and it works on day one. Connect what you already own and it gets sharper. Replace what you want to stop paying for, on your timeline.
Six line items, one budget, one hard stop.
The six line items are the ones in the left column above.
Most of the work runs on cheap, deterministic compute. Reasoning models are layered in only where judgment is actually required, which is why this replaces six subscriptions instead of adding a seventh.
Set a monthly budget and it's a hard stop, not an overage. Allocate it across the modules, surge it when the board starts asking how ready you are, and track spend per session, per agent, per finding.
Talk about consolidationIllustrative allocation.
Talk to our team about Guard
Tell us about your environment. We'll walk you through how Guard's agents would map your attack surface, chain what they find into the paths to compromise, and expose the breach points an attacker would use.