gsecure — administrator guide

Reference for the gsecure console. Each section covers one screen.

Roles and permissions

Every console user holds exactly one role. Roles are cumulative — each includes everything the role below it can do.

Role	Adds	Typically assigned to
Read Only	View dashboards, devices, logs, reports and policy. No save, approve or override control is shown.	Auditors, compliance reviewers, service-desk staff checking whether a device is compliant before escalating.
Security Analyst	Triage and resolve alerts, approve or reject access requests, re-check device posture.	SOC analysts and IT security staff working the queue — able to act on events without being able to weaken the policy that generates them.
Security Engineer	Change security policy, block-page settings and the access request link; manage console users, directory group mappings and API tokens.	The security or IT lead accountable for this organization’s policy. Usually two to four people.
Global Administrator	Create, approve and suspend organizations; platform-wide defaults; cross-organization visibility.	The service provider or platform team running gsecure. Not granted to customer staff.

Assigning roles

You can only assign roles at or below your own level, so no administrator can grant more access than they hold. Adding a user does not create a credential: the new user sets their own password from the sign-in screen using a one-time code sent to their email address.

Permissions are enforced on the server for every request. Hiding a console section is a convenience, not a security control — a user whose role lacks a permission is refused even if they call the API directly.

Directory groups

Map a Microsoft Entra ID or Active Directory security group to a role so console access follows your existing joiner-mover-leaver process instead of being maintained by hand.

Everyone in the group receives that role automatically.
Removing someone from the group in your directory revokes it — no change is needed in the console.
A user who belongs to several mapped groups receives the highest role among them.
Enter the group name or its object ID, whichever your sign-in tokens carry.

Example

Map SG-Security-Engineering to Security Engineer and SG-SOC-Analysts to Security Analyst, then manage membership entirely in Entra ID.

A group mapping cannot grant a platform-wide role. Group mappings are scoped to your own organization.

Access request link

Sets where the “Raise a Request for Access” button on the block page sends a user who has hit a blocked site. Point it at your own service desk — ServiceNow, Jira Service Management, Freshservice or an internal form — so requests land in the queue your team already works.

Placeholders

Two values are substituted into the URL before the link opens:

Placeholder	Meaning
`{host}`	The blocked site, as-is.
`{host_enc}`	The same value URL-encoded. Use this when the site name is a query-string parameter, so the ticket is raised against the right destination without the user having to type it.

Examples

ServiceNow — https://acme.service-now.com/sp?id=sc_cat_item&site={host_enc}
Jira Service Management — https://acme.atlassian.net/servicedesk/customer/portal/3/create/12?summary=Access%20to%20{host_enc}
Internal form — https://intranet.acme.com/security/access-request?site={host_enc}

Rules

Only https:// links are accepted. This address is opened from the block page on every managed endpoint, so plain http://, mailto:, javascript: and file:// are rejected.
The URL must not contain a username or password.
Leave the field empty to hide the button entirely.
If your organization has not set a URL, the platform default applies. Saving your own value overrides it for your organization only.

Changes reach endpoints on the agent’s next policy poll.

Blocked sites

Sites blocked in addition to the category feeds — use this for anything the feeds do not cover yet. One entry per line:

a domain — example.com
an IP address — 10.0.0.5
a range in CIDR notation — 192.168.1.0/24

Pasted URLs are trimmed to the hostname automatically. Entries added by the platform administrator are inherited by your organization and cannot be removed here.

Temporary site access

Grant one person, on any machine they sign in to, access to a specific site that is normally blocked by category filtering — without changing the category rule for everyone else. Found on the Categories tab.

Grants are matched by the authenticated user ID, not the device — the same person keeps access wherever they sign in.
An explicit grant always wins over a category block for that one person, at any priority.
Leave the expiry date empty for a permanent grant, or set one for automatic removal — no need to remember to revoke it.
The endpoint picks up a new or changed grant on its next policy sync, no restart needed.

Sites that need more than one domain

Some services span more than one domain — a page loading from one, and the actual application data (chat, media, sync) flowing through another that is not a subdomain of the first. Granting only the domain the page loads from can leave the site looking blocked even though it is not, because the second domain is still blocked. If a granted site still does not fully work, check what other domains it depends on and grant those too.

An explicit grant is not just a block-list exception — the endpoint also stops fully inspecting that connection, which is what lets the site’s own live/real-time features (a WebSocket-based chat, for example) actually complete their connection rather than merely stop showing a block page. Content passing through a granted site is not scanned by Data Loss Prevention while the grant is active — the same trade-off already applied to any platform-level inspection exemption.

USB device control

Sets the default disposition for removable drives, with exceptions where needed.

How exceptions work

An exception is granted to a person or to a machine — never to an individual USB device:

Person — matched on their authenticated user ID, so the exception follows them to any machine they sign in to.
Machine — matched on its asset serial, so any USB device used on that machine is covered.

Individual USB devices are never listed, which avoids having to catalogue every flash drive in the estate.

On allowed and read-only devices, file writes are still inspected by Data Loss Prevention. A USB exception is not a DLP exemption.

Sign-out code

By default, anyone can sign the gsecure agent out from the tray icon — the same one-click logout as any other endpoint agent. If that is too easy for your organization (a user disabling protection simply by signing out), require a shared code before logout succeeds.

Off by default. Your organization keeps today’s free logout until you turn this on.
The code is shared across your whole organization, not per-user — rotating it invalidates the old code immediately, for everyone.
Shown once, at creation or rotation. If it is lost, rotate again — there is no way to reveal a previously-generated code.
A logout rejected for a missing or wrong code leaves the session, and enforcement, fully intact. Nothing is torn down until the correct code is entered.

API tokens

Programmatic access for bulk operations and reporting, where the console is one-at-a-time. API access is off until you create a token.

Tokens are scoped to your own organization automatically.
read — GET only. read_write — may also make bulk changes.
Disable or delete a token to revoke it immediately.
Send it as Authorization: Bearer gsk_… or X-API-Key: gsk_….

Endpoint reference: gateway/server/API.md.

Organizations

Agents can only sign in if their email domain belongs to an approved organization.

Public self-service registrations arrive as pending and need approval.
Use New organization to create an internal or trusted organization, which is auto-approved.
An email domain can belong to only one organization.
An organization with several domains is still ONE organization — every domain shares the same policy, the same devices and the same users. There is no way to set different rules per domain within one organization.

Standard policy on approval

The moment an organization is approved, it receives its own copy of the platform’s current standard policy (categories, DLP, USB, threat intel) — not a link to a shared default that could silently change later. Every organization enforces something real from the moment its first user signs in, with nothing extra to configure.

Keeping policy in sync

Because each organization holds its own copy, a later platform-wide improvement (a new DLP detector, a newly-blocked category) does not reach an already-approved organization by itself. Use Sync standard policy — per organization, or for every organization at once — to push what is newly added.

Strictly additive: only adds an item an organization does not already have, by name. It never removes, replaces or overwrites anything already configured — including a rule an organization customized under the same name as a standard one.
An organization with nothing new to receive is left untouched.
Each sync reports exactly what changed, per organization, so it is never a black box.

Agent builds

Upload a new Windows agent installer directly from the browser, then publish it as the update every already-installed agent’s silent updater will pick up — no shell access to the server needed. Platform administrators only.

Two separate steps, on purpose

Upload puts the file on the server and reports its measured size and hash. Nothing changes for any endpoint yet.
Publish is the deliberate second step that actually points every agent’s updater at it. Review the upload first — publishing is what goes live.

Only the latest build is kept

Publishing a build automatically removes any other installer sitting in the downloads area — there is only ever one available at a time, so there is never a question of which one a customer should use. The public download link on the product page always points at whichever build is currently published.

A build’s version must be genuinely newer than the one already published, or the server refuses to publish it. An already-updated agent compares versions as plain numbers — two builds sharing the same version string are indistinguishable to it, even if the underlying code differs, so a real version bump on every build that should reach the fleet is not optional.

Local admin account lockdown

Most organizations using gsecure have no Active Directory or GPO to manage local administrator rights, so whoever set a laptop up before gsecure was installed is often still a local administrator on it — able to disable or even uninstall the agent itself. This closes that gap. Off by default; endpoint security setting, found on the Users & Roles tab.

How it works

gsecure provisions two managed accounts: one you name (the day-to-day managed account) and the built-in Administrator as a recovery account.
Both are verified with a REAL Windows sign-in — not just "the account was created successfully" — before anything else happens.
Only once both are freshly verified does the demotion clock start (configurable, default 2 days), long enough for a provisioning problem to be caught and fixed without needing to reinstall the machine.
When the clock expires, both accounts are RE-verified right then, and only on success does every other account on the machine lose local-admin rights.

Passwords

Rotate the managed or recovery account’s password independently, at any time.
Passwords are hidden by default; revealing one is written to the audit log, so there is always a record of who looked.

Demotion only ever changes group membership — it never deletes an account, its profile or its files. Signing in with either managed account always reverses it.

Data Loss Prevention

Rules that decide what happens when sensitive content (card numbers, secrets, personal data, ...) is about to leave the company - by channel, user, application, destination and what was found.

Detectors find sensitive patterns; each match is grouped into a classification (e.g. PCI, SECRETS).
Each policy matches a channel and one or more classifications, and applies an action: BLOCK, QUARANTINE, LOG, or ALLOW.
When more than one policy matches, the strictest action wins (BLOCK > QUARANTINE > LOG > ALLOW).