Security intelligence
Know which alerts matter, and why.
NexGuard watches behaviour across your systems, groups related findings into one story, and proposes what to do about it — where a person decides, every time.
From an event to a decision
Six stages, in order. Each one is a service you can see the output of.
Your systems send events
Sign-ins, registrations, verification attempts, API calls. No agent runs on your servers — it sees what you send it and nothing else.
Sensitive values are removed first
Passwords, card numbers, national identifiers and document images are stripped at the boundary — and you are told you were sending them.
Rules look for patterns
Ten built-in detections, each with a written rationale, plus rules you write within bounds you cannot exceed.
Related findings become one incident
Twenty findings about one device are not twenty problems. Presenting them as twenty guarantees the twenty-first goes unread.
A response is proposed
Each proposal states what it does and what it costs if the finding is wrong. Approving does not carry it out, and consent expires.
A person decides
Approved actions go to an endpoint you run. This platform cannot suspend anybody's account. It can only ask.
What it is answerable for
Findings you can argue with
Detection is deterministic rules over a time window. Every alert traces to a rule you can read, tune or switch off — and so does every false positive.
A score, and the sentence beside it
The number is worthless alone. The console shows what moved it and why, so a change is something to act on rather than notice.
It says when it cannot see
A panel that failed to load says so rather than showing an all-clear. A stopped worker is reported, not mistaken for a quiet night.
AI is optional, and off
Detection, correlation, risk and scoring never call a model. With enrichment off the platform is complete, not degraded.
One tenant cannot reach another
Isolation is enforced on every query, and identifiers are hashed per tenant — the same account in two tenants produces two different values.
Erasure is deletion, not a flag
Every erasure states what survives it. Access audit records outlive everything and cannot be shortened by a tenant.
Read it from your own systems
Your incidents, alerts and score, fetched by your own backend with a scoped key. Small on purpose, and read-only.
- Three read-only scopes: incidents, alerts and the security score. There is no scope that changes anything, approves anything, or reaches another organisation.
- A key is bound to one organisation on the server. No request field names a tenant, so a caller cannot ask for anybody else's data however the request is shaped.
- The secret is shown once and stored as a hash. A lost key is rotated rather than recovered — nobody, including us, can read it back.
What it does not do
Here rather than in a footnote. A limitation you find after signing does more damage than the deal was worth.
- It does not watch your network, servers or endpoints. If your integration stops it goes quiet — it will say so, but it cannot detect what was never sent.
- It does not scan for vulnerabilities. The posture assessment reports on your configuration here, and a clean result is not a clean bill of health.
- It does not act on your systems by itself. It asks; your system decides.
- It does not find things nobody has described. There is no anomaly model that spots the unprecedented.