What you are setting up
Gladius runs a closed loop. It discovers what you actually have, validates which weaknesses are genuinely exploitable rather than theoretical, remediates through a pull request or an approved connector action, and writes every step to a tamper-evident audit ledger.
This lesson covers the first half of that loop. By the end you will have a live connector, a discovered inventory, and real findings in a triage queue.
Before you start
An invited account
Your Gladius contact sends an invitation to your work email. There is no password to choose — see step 1.
One host to run the connector
A Linux, macOS or Windows machine, a Docker host, or a Kubernetes cluster inside the network you want discovered. Two cores and 2 GB of RAM is plenty to start.
Outbound HTTPS on 443
The connector dials out to connect.gladiussec.co. No inbound rule, no port forward, no VPN.
The ranges you own
One or more CIDR blocks you are authorised to inventory, for example 10.0.0.0/24.
Sign in — there is no password
Open the invitation and you land on Sign in to Gladius with a single Work email field. Gladius deliberately has no password to choose, reuse or leak. Type your email and one of three things happens, in this order:
- A passkey, if you have one. Your browser offers a saved passkey inside the email field before you finish typing. Accept it and you are in.
- Your company SSO, if your domain federates. Gladius checks whether your email domain is wired to an identity provider and sends you straight there. If your organisation enforces SSO, this is the path you get.
- A one-time link otherwise. You will see Check your email; the link signs you in and invites you to register a passkey so the next sign-in is one tap.
We never ask for a password. If your domain federates, you will be redirected to your identity provider.
A representation of the sign-in screen, not a live screenshot.
Set your persona
Once inside, set your persona from the user menu. Gladius has five — executive, security engineer, auditor, IT ops and risk / finance — and each one changes which surface you land on by default. This lesson assumes the security engineer view. If your screens look different from the ones below, check your persona first.
You will know it worked when
You reach a Gladius surface with your name in the top-right — usually the Onboarding page, since a fresh tenant is redirected there until its first findings land.
CheckWhy does Gladius refuse to issue you a password?
Because a password is a shared secret that can be phished, reused across sites, or dumped from a breach somewhere else entirely. Passkeys are bound to the origin and cannot be replayed against Gladius, and SSO keeps the decision about who may sign in inside your own identity provider, where your joiner-mover-leaver process already lives.
The practical consequence: when someone leaves your company, disabling them in your identity provider removes their Gladius access. There is no separate password to go and revoke.
Wait for account validation
This is the one step in the lesson you cannot complete yourself, and the reason it has its own beat: nothing below can start until it is done. A person reviews the account before it is granted access — the Gladius team, or your service provider if one manages your tenant.
The clock is not running yet
The thirty-minute contract starts when validation completes, not when you sign up. Your Onboarding page shows this step as awaiting validation and holds the countdown until a human clears it. If you are watching the clock and it has not started, this is why.
The onboarding steps, as the page presents them. The same state appears as a compact ribbon across the top of your dashboard.
You will know it worked when
Account validated flips to done, the thirty-minute countdown begins, and Authorize scope becomes the active step. The page polls on its own — you do not need to refresh.
CheckYour countdown has not started and discovery will not run. What do you check first?
Whether Account validated has actually cleared. It is a manual review, it gates everything downstream, and the clock is deliberately paused while it is open — so a stalled countdown is the expected appearance of an un-validated account, not a fault.
Your Onboarding page names the stuck step and how long it has been stuck, which makes it the right first stop for any stall, not just this one.
Authorize the scope you own
Before Gladius touches anything, you record consent for the assets you own. This is a deliberate hard gate, not a formality: Gladius will never act outside an authorized scope, and the consent record is what makes the activity that follows defensible to your own auditors.
You can satisfy this step two ways — accept the consent clickwrap on the Onboarding page, or deploy a connector, which carries its own scope. Either one advances it. If you are going straight to step 4, the connector covers you.
You will know it worked when
Authorize scope shows as done and Run discovery becomes the active step.
CheckWhy gate a read-only inventory behind a consent record at all?
Because the inventory is the first move in a loop that ends in active validation against those same assets. Scope authorized once, early and on the record is what lets later steps escalate safely — and the consent entry lands on the same tamper-evident audit log as everything else, so there is a durable answer to “who authorised this, and when?”
Deploy your first connector
The connector is the piece of Gladius that runs inside your environment. Everything that touches your network happens here, never in the control plane. Before you install it, understand the one property that matters to your network team.
Generate the install
On /connectors, click Deploy connector. Pick the deployment target that matches your host, give it a name you will recognise later — the placeholder prod-edge-1 is a good shape, name it for where it lives — and click Generate install.
Copy one command, paste it on the host. The bootstrap downloads the binary, registers a service and attaches automatically.
Run one command on the host
Gladius hands you a single command with the enrollment token already embedded. Copy it from the screen rather than retyping it from here. Both the <TOKEN> and the hostname below are placeholders — your real command carries whichever Gladius address you signed in to. Pick your target:
Run on the target host
curl -fsSL 'https://app.gladiussec.co/api/v1/connector/install/sh?token=<TOKEN>' | sudo shInstalls gladius-connector as a service and starts it. Detects operating system and architecture for you.
Run in an elevated PowerShell
iwr -UseBasicParsing 'https://app.gladiussec.co/api/v1/connector/install/ps1?token=<TOKEN>' | iexDownloads the Windows build and registers it as a service.
Run on the Docker host
curl -fsSL 'https://app.gladiussec.co/api/v1/connector/install/compose.yml?token=<TOKEN>' \
| docker compose -f - up -dGenerates a compose file with the token embedded. The container restarts unless you stop it.
Run against your cluster
kubectl apply -f 'https://app.gladiussec.co/api/v1/connector/install/k8s.yaml?token=<TOKEN>'Creates a namespace, a Secret holding the token and API URL, and a Deployment.
Paste into your VM userdata
# Paste under runcmd, or pass as userdata: curl -fsSL 'https://app.gladiussec.co/api/v1/connector/install/sh?token=<TOKEN>' | sudo sh
Works as AWS userdata, an Azure custom-script extension, or a GCP startup script.
The token is one-time and expires in 30 minutes
Gladius never stores the plaintext enrollment token, so the install command cannot be shown to you twice. Copy it when you generate it.
If you lose it, or need to move the connector to a different host, click the connector's row and generate a fresh install token. Doing so invalidates the previous one — a connector already running on the old token stops authenticating until it re-enrolls. That is the intended way to retire a host, but it will take a working connector offline if you do it by accident.
Watch it attach
Back on /connectors, the row updates on its own every few seconds. It moves from enrolled — token issued, nothing has called home yet — to active once the connector completes its first mutual-TLS handshake and heartbeat.
| Name | Type | Status | Last heartbeat |
|---|---|---|---|
| prod-edge-1 | local | ✓ active | 4s ago |
| lab-dc-01 | docker | ⏳ enrolled | — |
lab-dc-01 has a token but has not called home yet. prod-edge-1 is attached and heartbeating.
Two other states you may see
unreachable is set automatically when a connector's heartbeat goes stale — usually a stopped service, a rebooted host, or lost egress. It heals itself the instant a heartbeat arrives, so no action is needed if the host is simply rebooting. revoked only ever happens because an administrator did it, and it is final: that connector's credentials stop authenticating immediately.
You will know it worked when
- Your connector shows active with a heartbeat measured in seconds.
- You made no firewall change to get there.
CheckYour connector has sat at “enrolled” for ten minutes. What are the two likely causes?
The bootstrap never ran, or the token expired before it did. The token is good for thirty minutes and one use only. Generate a fresh install from the connector's row and re-run it on the host.
The host cannot reach the control plane outbound on 443. enrolled means a token was issued but nothing has completed a handshake, which is exactly what blocked egress looks like. Test it from the host, not from your laptop — the question is whether that machine has a route out.
What it is not: a missing inbound firewall rule, or an IP allowlist entry. Neither exists in this design — the client certificate is the gate.
Discover your environment
Go to /discover — Discover your environment. It is a four-step wizard that turns your freshly attached connector into a populated inventory.
1 · Connector
The wizard confirms you have an active connector and lets you choose which one to scan from. If none is active it links you back to step 4 — this is the dependency made visible.
2 · Scope
Type a CIDR block and press Enter or , to add it; repeat for each range. Invalid entries are rejected inline, so 10.0.0.0/33 will not slip through. Give the source a name, then click Create passive scan.
Passive by design — and why that matters today
This first scan is passive only: no port scanning, no active probing. That is what lets it start immediately, with no ownership attestation and no change-control conversation. You get an inventory on day one.
Active scanning is available later from the source's own settings, and it requires a verified network attestation — proof you own what you are about to probe. Do not plan your first run around active scanning; it is a deliberate second gate, not an oversight.
3 · Discover
Click Run scan. The page shows the live scan phase and the host count climbing. Within roughly thirty seconds you should see assets appear.
Discovered hosts appear below as they are found. Counts are illustrative.
4 · Go deeper
The last wizard step surfaces what it found and points you at credentialed sources — AWS, Azure, VMware, Active Directory, Kubernetes — which see far more than a passive sweep can. Leave that for after this lesson.
Read your inventory
Open /assets. The top of the page breaks your estate down by type, cloud, location and criticality; click any chart segment to filter the table below it, or search by external ID, type, source or location. Click any asset to deep-dive. Non-human identities — service accounts, roles, API principals, AI agents — have their own surface at /nhi, and they are usually where the interesting findings come from.
You will know it worked when
- /assets is no longer empty and the breakdown charts render.
- Clicking a chart segment filters the table.
- Run discovery shows as done on your onboarding page.
CheckYour passive scan returned far fewer hosts than you expected. Is something broken?
Probably not. A passive sweep only sees what is observable without probing, and it only looks at the ranges you entered. Check the obvious scope questions first: did you add every CIDR that matters, and is the connector's host on a segment that can observe them? A connector in a management VLAN will not see a user subnet it has no path to.
The real fix is usually depth rather than breadth — a credentialed source for AWS, Active Directory or VMware will return far more than any network sweep, because it asks the authoritative system instead of inferring from traffic.
Read and triage your first findings
This is the step the thirty-minute contract is measured against. As discovery populates, Gladius validates your assets against signed recipes and promotes what it confirms into the triage queue at /findings.
Each finding carries a kind such as aws.iam.passrole_privesc, a severity, the asset it belongs to, and a link to the evidence that produced it. The evidence link is the part worth your attention — it is what separates a validated finding from a scanner's guess.
| Severity | Kind | Asset | State |
|---|---|---|---|
| critical | aws.iam.passrole_privesc | role/deploy-ci | open |
| critical | aws.s3.bucket_public | s3/customer-exports | open |
| high | linux.sshd.root_login | 10.0.0.41 | triaged |
Illustrative rows. Severity, state and asset-type filters sit above the table and apply to the summary counts too.
The triage states
Findings move through a small state machine. Three states are terminal, and the two you choose deliberately — false positive and accepted risk — both ask you to record why.
Triage with the keyboard
The queue is built to be worked at speed, in the shape of an issue tracker. Learn these and you will not reach for the mouse:
Select several rows with x and an action key applies to all of them at once. Bulk transitions are recorded as a single batch entry in the audit log while still writing a per-finding record underneath, so the trail stays exact.
One exception worth knowing
CIS compliance findings appear in this view but cannot be triaged from it — they have no triage state of their own. Manage those under Compliance → CIS. Gladius tells you rather than failing silently if you try.
See it on the board
Finally, open the dashboard at /. The Continuous Validation Status Board is a grid of attack technique against asset class, and your new finding has just flipped a cell. That grid, not the queue, is the view your executives will ask for — it answers “what can actually be done to us, and where” on one screen.
You have finished the lesson when
- At least one finding sits in /findings.
- You have opened it and seen its evidence.
- You have moved one finding to triaged with t.
- Your onboarding page shows First findings as done.
CheckA finding is real but you cannot fix it this quarter. Which state, and why does it ask for more than a click?
Accepted risk — and it asks for a justification, a named reviewer and an expiry date on purpose. A risk accepted without those three details is indistinguishable from a risk forgotten.
The expiry is the important one: it brings the finding back for review rather than letting it sit closed forever. Choosing false positive here instead would be wrong, and worse than wrong — it tells Gladius the validation itself was inaccurate, which degrades the signal you are paying for.
Where to go next
You now have the Discover and Validate halves of the loop running. The natural follow-ons, roughly in the order most teams take them: