Shugoi
Safer decisions, without friction
We won’t make you money;we’ll help you avoid losing it.
Shugoi links visits from the same device across browsers using a pseudonymous Machine ID. IP addresses and cookies are not used as that identity. This cross-browser signal feeds your access, quota and abuse-prevention rules through the middleware. Matching remains probabilistic and depends on the available signals.
Server middleware · site-level decisions · correlated server-side analysis
Modern browser compatible · low friction · decisions stay in your application
New to the topic? Read our browser fingerprinting guide.
Until 2028
Join while the door is open.
Shugoi's open beta welcomes its first teams through 2028. Sign up, test protection on your product and help shape what comes next.
The problem
One account does not always describe a visitor.
A browser can remove a session cookie, and an IP address can change. A server-side quota does not reset as a result. When an action uses compute, storage or a place in your service, an account identifier alone may not be enough to decide.
Case #1
Fictional exampleMeedjurnay
Meedjurnay sells 20-credit image packs. One HD generation costs about €0.18. After repeated signups claiming free credits from the same environment, the app can refuse the new pack.
Case #2
Fictional exampleCowpeelot
Cowpeelot offers a 14-day trial with 5 seats per team. One seat costs €12 per month. If the same person opens several workspaces to extend the trial, the product can restrict the new signup.
Case #3
Fictional exampleOnzeLabs
OnzeLabs charges €0.42 per video generation. A script retrying 2,000 jobs can commit €840 before a customer sees a result. The API can authorise known usage and restrict unauthorised calls.
The difference
An account tells you who signed in. The network describes part of the journey. Neither always tells you which environment made the request.
A session cookie stores an identifier that the browser sends back to the server. Shugoi's environment signals add to your server-side rules, which determine whether the request is allowed.
When available signals agree, your application can better connect contexts it has seen before. The decision remains pseudonymised and configurable.
Signals are processed server-side according to the site's configuration. Shugoi does not replace your CDN or WAF: it adds context when a decision is needed.
Shugoi
Illustrative scenarios. The companies named are fictional parodies: any resemblance to real brands is satirical and unintentional.
JWT and Machine ID
Make a stolen JWT harder to reuse.
At sign-in, your server can associate the JWT's jti with the observed Machine ID. On later requests, it compares the signal received with that binding and can reject the token if the environment differs.
This check must be integrated into your site's authentication. Shugoi SDK does not automatically bind JWTs to the Machine ID. Recognition remains probabilistic and does not prevent the token's initial theft.
Compared approaches
Each approach sees part of the journey.
An account, an IP address or a CAPTCHA can be useful. They do not always describe the environment consuming a quota or creating a cost. Shugoi adds that context to your application's decision.
| Approach | What it can do | What it often lacks |
|---|---|---|
| Compte et cookie | Recognize a session | Connect repeated journeys |
| Adresse IP | Observe a network | Distinguish legitimate users reliably |
| CAPTCHA | Add friction | Does not directly reduce the cost of a quota or API |
| CDN / WAF | Filter and protect traffic | Understand certain application contexts |
| Shugoi | Provide signals to the application | Let the site decide the response |
Shugoi complements these layers: it does not replace your CDN, WAF or business rules.
Recognising the machine is just the start
The machine behind the screen, and everything else around it.
A few server-side lines are enough to integrate Shugoi. You configure each site, keep the decision in your application and can correlate contexts using the available signals. Identifiers are pseudonymised; the Node/Express integration is tested, with additional adapter examples available.
For your customers, the journey remains your product's journey. The response follows the policy you chose.
The limits
What Shugoi doesn't do.
Good protection knows where it stops.
Signals need a browser.
A page that cannot run the check does not provide the same context. Configure the paths that matter for your site and users.
Environments do not always look alike.
A virtual machine, hardened browser or headless profile can serve legitimate purposes. In some journeys, these tools can also multiply access or automate actions. Shugoi lets your site choose the response.
Your site stays in control.
Tor, Mullvad, virtual machines and headless browsers are not fraud verdicts. They can still be part of a context your rule chooses to allow or restrict.
Shugoi correlates signals server-side so your application receives the context and applies the rule that fits its journey. It complements your application without replacing your CDN, DDoS protection, signature WAF or business rules.
Same device. Different browser.
Shugoi links visits from the same device across browsers using a pseudonymous Machine ID, without using IP addresses or cookies as identity. Matching depends on the available signals.
See the integration
How it works
The context arrives. Your site decides.
The context arrives
Shugoi middleware fits into your site's journey and checks the request server-side.
Signals are correlated
Shugoi compares the available elements from the environment, session and request. No single signal decides on its own.
The site applies its rule
Your configuration chooses what happens next: allow the request or restrict access.
A decision you can read