Your AWS and Cloudflare logs land in the same tables as every Vulnetix decision

Every Vulnetix decision is already a row

Before you send a log line, Guardian holds the decisions the rest of Vulnetix Resolve made about your estate.

Internal producers (the sandboxes, the firewalls, the sensor and the Vulnetix API) are not counted against the pack.

• Pix Sandbox: Every sandbox's egress decisions are already a Guardian source, in net_events with source pix. The Guardian investigators run on a Pix Sandbox, behind its controlled egress and the AI Firewall and Package Firewall gates.
• Package Firewall: Package Firewall decisions arrive as product_events. A firewall review ticket and a Guardian alert can start the same kind of workflow.
• AI Firewall: AI Firewall decisions arrive as product_events, so a held capability and a sandbox egress refusal sit in the same table and the same rules read both.
• Runtime sensors: The sensor runs in EC2, EMR, EKS, ECS and Lambda workloads, applies your virtual patches and countermeasures, and holds a match in guard mode until a person decides. Its decisions reach Guardian with vulnetix-sensor --forward siem.

Your AWS and Cloudflare logs land beside them

One CloudFormation stack and a set of Logpush jobs, both launched from the console. Guardian holds no AWS credentials for ingest and forgets your Cloudflare token once the jobs exist. Start Guardian under Log sources

AWS

Cloudflare

Seven tables

• net_events: flow records and connection decisions
• dns_events: DNS queries
• waf_events: WAF matches
• http_events: HTTP requests
• cloud_audit: control-plane changes
• product_events: product decisions and audit
• ioc_indicators: the daily indicator snapshot from Vulnetix VDB

Every row carries the tenant, the event time, the ingest time, a minted event id, the source, the host and the raw fields, and IPv4 columns carry integer companions so a CIDR match is a BETWEEN.

• Cloud scanning: The compute pass finds what is running in a connected AWS account, grouped by resource family. Guardian's AWS stack is a second, separate stack you launch.

Search in one editor, then let rules run about every two minutes

The search language and Sigma share one editor and translate both ways, so the search you refine becomes the rule that watches for it.

dns_events
| where qname endswith ('.duckdns.org', '.no-ip.org') and src_ip in 10.0.0.0/8
| stats count() as hits, dc(src_ip) as sources by qname, host
| where hits >= 5
| sort -hits

Show SQL prints the statement Guardian runs, with your tenant's scope already in it.

The search language

Where rules come from

Each rule is a scheduled query over your tenant's rows, run about every two minutes and deduplicated per row and per group, so the next sweep repeats nothing. The levers are a threshold (count, window, group by), suppressions written into the rule, a quiet period, a per-run cap and the interval.

Where an alert goes

To any messaging connection, or by email: Slack, Microsoft Teams, Google Chat, Discord, Jira, GitHub Issues, Signed webhooks, Email.

A scheduled send delivers a saved search as a table and chart, a link to the search and, on email, a CSV, hourly to monthly, skipped when empty or sent as an all-clear.

• Countermeasures: Countermeasures builds Sigma, YARA, STIX 2.1 and OpenIOC from real exploits for your vulnerabilities. A Countermeasure Sigma rule is enabled in Guardian by reference and recompiled when its body changes.
• Vulnerability database: ioc_indicators is a daily snapshot of Vulnetix VDB's indicators, so any log joins against them.

A fired trigger starts a Software Factory workflow

The Guardian templates ship in Software Factory: investigate on a Pix Sandbox with read-only cloud access, ask a person, write the fix.

A trigger's levers

• At least N rows. In a window, counted per field.
• A cooldown per group. The same group does not fire again until it ends.
• At most N fires per hour. For the trigger as a whole.
• Business hours. In a time zone, or outside them.
• Rows as context. Capped, with the columns you choose.
• A dry run. Over the last 24 hours, shows how often it would have fired.
• No rows, no fire. A query that returns no rows never fires.

A trigger fires into a Software Factory workflow (a FactorySourceEvent with source siem), a messaging connection, or email.

17 templates

AWS

• Egress to a new or flagged destination
• Lateral movement inside a VPC
• Admin or database port open to the internet
• DNS query for an indicator
• NXDOMAIN burst or generated names
• Logging or detection turned off
• Resource made public
• Risky identity activity
• WAF block spike

Cloudflare

• WAF block spike
• Managed rule names a CVE
• Credential stuffing on a login path
• DNS query for an indicator
• New external destination
• Risky account change

Vulnetix and any source

• Pix Sandbox egress: Hands the rows to belai:egress-reviewer, which files a ticket for an allow or deny rule a person confirms in the console. No investigator, no remediator.
• Indicator seen anywhere

The investigator writes what happened, the evidence and a verdict of benign, needs_change or incident. A person approves before belai:guardian-remediator writes anything; a benign fire still notifies and files the card.

• Software Factory: The Guardian templates are Software Factory templates and the agents are built-in Belai profiles. People approve, and the output is a draft pull request with its run trace and evidence.
• Agents and crews: The investigators and the remediator are built-in Belai agents, listed with the rest of the fleet.
• Virtual Patching: Blocking rules for Snort, Suricata, ModSecurity, nginx, AWS WAF, Cloudflare WAF and layer 7. When a Cloudflare managed rule names a CVE, the template proposes the matching Cloudflare WAF virtual patch as a custom rule and the upgrade to the fixed version Vulnetix names.

Agents only read, and a person approves every change

The parts of Guardian that touch your accounts only read, and the part that writes waits for you.

People approve in Software Factory, where the run trace and the evidence are the record.

Three ingest packs, bought where the logs are connected

Guardian is an add-on to the Business or Enterprise plan, sold as a monthly ingest pack. Rows from Vulnetix's own producers do not count against it.

Enterprise is by quote. You are told at 80% and 100% of the day's cap, and past 150% ingest is refused with a 429 so the sender keeps the batch.

Against vendor list prices in October 2026, Sumo Logic Cloud SIEM charges 40 Flex credits per GB ingested (about $6 per GB at $0.15 a credit) and Datadog Cloud SIEM $5 per GB analyzed plus $0.10 per GB of log ingest. Guardian 5 works out to about $4.00 per GB and Guardian 100 to about $2.97, over a 30-day month at the full cap.

• Pricing: Pack prices and the plans Guardian attaches to are on the pricing page.
• Start Guardian under Log sources: You buy a pack and connect Cloudflare on the Integrations page under Log sources; the AWS stack's launch link and your ingest tokens are on Guardian Sources.

Questions teams ask before they connect a log

Do I need to send logs before Guardian shows anything?

No. For an organisation with Guardian, Pix Sandbox egress, Package Firewall and AI Firewall decisions, the runtime sensor's DNS guard and egress proxy, and the Vulnetix API access log are already rows, and they are not counted against the ingest pack.

How long does a record take to become an alert?

Firehose buffers 0 s and 1 MB, so a record leaves your account within seconds. Rules run about every two minutes and read up to two minutes behind now, so a record is read a few minutes after it lands, and a row alerts once.

What does Guardian need in my AWS or Cloudflare account?

For AWS, one CloudFormation stack from the launch link: Firehose streams with your ingest token as the access key, flow logs, Resolver query logging and an EventBridge rule for CloudTrail management write events. Guardian holds no AWS credentials. For Cloudflare, Logpush jobs the integrations page creates with a token it checks and then forgets, or jobs you create with the destination string the page shows. The read-only investigation role is a second, optional stack.

Which Cloudflare datasets can I send?

Per zone: firewall_events, dns_logs and http_requests (sampled on request). Per account: gateway_dns, gateway_network, dns_firewall_logs, network_analytics_logs, audit_logs_v2 and workers_trace_events. Cloudflare allows four jobs per zone, and which datasets an account can push depends on its Cloudflare plan, and the integrations page names each dataset Cloudflare refused for your account.

Can I keep using my own Sigma rules?

Yes. Upload your files, pick from the SigmaHQ import for the mapped logsources, refreshed weekly, or enable a Vulnetix Countermeasure by reference. The editor shows the same detection in the search language and in Sigma, and a suppression is written into the rule, so a Countermeasure keeps your suppressions when its body changes.

Can an agent change my cloud account?

No. The investigators read through an AWS read-only role you deploy or a Cloudflare API token you chose to keep in the vault, and nothing is applied to a cloud account by an agent. After a person approves, the remediator writes the change as a draft pull request when the resource is managed in a connected repository; otherwise the exact commands, with their blast radius, go in the ticket.

What happens when I send more than my pack allows?

You are told at 80% and at 100% of the day's cap. Past 150%, ingest is refused with a 429 until the day ends, so the sender keeps the batch: Firehose parks it in the error bucket in your account for 14 days, and Logpush retries and then marks the job failing in your Cloudflare dashboard. Nothing is dropped without you knowing.

Start with the rows Vulnetix already holds for you

A demo opens Guardian on the sandbox egress and firewall rows your organisation already has, connects one AWS region or one Cloudflare zone, and runs a trigger's dry run over the last 24 hours. Nothing is applied to your account by an agent.

Get a Demo Pricing