GATE Documentation

Have Hulud run a structured security test against an app you own — it logs in, maps every endpoint, probes for weaknesses, confirms the real ones, and hands you a findings list with severity and evidence, not a scary summary.

Only ever point Hulud at a target you own or are explicitly authorized to test — your own staging or production environment, never a third party's site or infrastructure. Hulud is instructed to stay inside the target(s) you list and to avoid destructive or brute-force testing, but that boundary holds because the agent follows its instructions, not because of a network firewall around it. Don't hand it a target you don't control.

Who this is for

You've shipped an app on GATE and want a real security pass on it before or after it goes live — not a checklist, an agent that actually tries to break in and tells you what worked. This tool is called Hulud.

Before you start

Hulud has to be turned on for your org first, and only an admin can do that. If you don't see it in your dashboard, ask your admin.
Starting a scan also currently requires admin access. Even with Hulud on, kicking off a scan is an admin-only action today. If you're not an admin, ask yours to start it, or confirm your bot is set up to start one for you.
A target you're authorized to test — a URL, host, or GATE project. Staging or dev is the safer default; only target production if you're sure.

Steps

Scope the test. Decide what's in bounds — a URL, hosts, or a GATE project (which also lets Hulud read the source for deeper checks). Say something like "I want a security test on staging.example.com. I own this and I'm authorized to test it." If part of the app needs a login, decide whether to hand over a test account — a disposable staging login beats a real admin password.
Your admin starts the scan. Hand them the target, your authorization confirmation, and any test credentials. They start the scan from the dashboard; a new entry appears in Hulud's scan list, running.
The test runs its course. Hulud authenticates if given credentials, maps every reachable page and API endpoint, works out which vulnerability classes are worth checking, fires one careful proof per candidate to confirm or rule it out, then checks its work against a fixed list of common vulnerability categories before calling the test done — nothing wraps until every category is checked one way or another.
Watch it work. A real scan takes minutes, not seconds. The scan detail view shows live phase progress and a running severity count.
Review the findings. Each confirmed finding has a severity, a plain-language description, and the evidence Hulud used to confirm it. Well-known categories (SQL injection, auth bypass, remote code execution) are held to a minimum severity floor the scan can't rate below, so a genuinely critical bug can't quietly show up as "medium."
Fix it, then confirm with a retest. Once your team ships a fix, someone with dashboard access clicks "Retest" on that finding. Hulud re-runs a focused check on just that one issue and marks it fixed or still open — a manual click, not something that happens automatically when the fix ships.

What you'll see

In Hulud's dashboard: scans (running, completed, failed) with a live severity count while running, and a severity-trend view across repeated scans on the same target.
In a scan's findings list: each confirmed finding with severity (critical, high, medium, low, info), description, and evidence — grouped by severity, living here in Hulud's own dashboard, not an external tracker.
A diff view: what's new and resolved since the last completed scan.
On a per-project Security tab: the same scan history, scoped to that project.

Troubleshooting

You don't see Hulud anywhere in your dashboard. Not turned on for your org yet — an admin-only toggle. Ask your admin to enable it.
You (or your bot) can't start a scan. Starting a scan requires an admin session today. Ask your admin to start it, or confirm your bot is set up to start scans for you.
A finding's severity looks lower than expected. Well-known vulnerability classes have a minimum severity floor that a scan can't rate below, so a genuine critical can't be talked down — check the evidence before assuming the rating is wrong.
You fixed something but "Retest" never ran. Retest doesn't trigger automatically when code ships — someone with dashboard access has to click it.
The scan seems stuck. A full multi-stage test genuinely takes a while on a real target; check the phase-progress view before assuming it's failed.

Do this with your bot

Help me plan and authorize a security test with Hulud. First confirm exactly what target I'm allowed to test — a URL, host, or GATE project I own or am authorized to test — and whether I want login credentials included for authenticated checks. Then tell me plainly what to hand our admin to get the scan started, since starting it is admin-only. Once results come back, help me read the findings by severity and plan fixes, and remind me that confirming a fix means asking someone with dashboard access to click retest on that finding.

Copy this brief and paste it to your bot in chat — it will ask for anything it needs before doing the work.