You're an attacker. You've got a set of stolen credentials lifted from an employee's laptop by an infostealer. You know once you're inside the company environment you'll have to be careful not to set off any alarms, but first you have to simply log in. You load the credential into a company login portal. It looks like every other portal you've ever hit… So you sign in. The portal looked legitimate, but immediately an alert fires in a SOC you can't see: your IP, your browser fingerprint, and the exact credential you just used are all recorded and sent to the security team. You touched the wrong door and you had no way of knowing. That wasn't a normal login portal…
Today we're extending detection of an intrusion to the earliest point: the perimeter, the moment stolen access is first used.
Introducing Perimeter Sensors.
You've heard this before: Stolen credentials don't break in. They log in.
Multifactor Authentication (MFA) and Endpoint Detection and Response (EDR) did their job. But attackers moved to a ground neither one owns. On a managed device, a payload dropped for persistence or execution would trip an EDR, a stolen password would hit MFA. So attackers pivoted; malware became a harvesting engine on an employee's laptop. Infostealers scrape saved credentials and live session cookies while adversary-in-the-middle pages proxy logins. In Verizon's 2026 Data Breach Investigations Report, credential abuse features in 39% of breach chains, and stolen credentials remain the most common way attackers get into web applications.
When valid credentials are used by the wrong person, your security stack is left guessing. Identity security tooling looks at the login via probability or deviations from a baseline: an odd location, a new device, a strange IP. These signals are real, but someone still has to triage them. And when the login is genuinely valid, nothing looks wrong. The only thing "off" is the human behind it.
You can fall back on threat intelligence: pay someone to watch the breach forums and stealer logs, rotate whatever surfaces, sometimes buy the dump outright. It's useful, but it only works if your credentials appear somewhere your vendor is watching, and only after they've seen it. You're waiting for the criminal market to show its hand.
That gap, the valid session used by the wrong person, is what Perimeter Sensors are built to close.
What we're launching
Perimeter Sensors have two components.
The first is the sensor: a believable canary service such as a corporate VPN portal, private NPM registry or API endpoint, deployed on your own domain and built to be indistinguishable from the real thing. Tracebit hosts it, but it sits on your subdomain, and looks exactly like one of your real services.
The second is the canary credential: login credentials, session cookies, API tokens and more, pushed organisation-wide to your employee devices and your critical repositories, via Chrome Enterprise and our GitHub Action. These look like live, valuable access credentials to anyone who finds them.
You deploy a few dozen sensors across the apps attackers actually target, turning your environment into a place where every promising credential might be the one that ends the engagement. This gives your team the signal of compromise before the attacker even gets in.
How it works
The canary credential and the sensor are bound. The credential carries the address of the sensor it belongs to, the same way a real saved credential carries the address of the real service. When an infostealer sweeps an endpoint, it takes the canary credential and its destination together with everything else. The attacker can't separate the planted credential from the genuine ones. Nothing distinguishes them.
The sensor runs on your own domain. For example, prodvpn.chicago.acme.com resolves under your domain, serves a valid TLS certificate, and answers exactly like your real portal. There are no Tracebit tells to find.
An attacker validating an infostealer sweep comes to test the credential, by hand or more often through an automated checker. Once they submit a credential we didn't issue, the sensor answers exactly like the real service would: a failed login triggers nothing unusual. But submit a credential we issued, which by definition is in the wrong hands, and an alert fires.
When a sensor fires, you have an unauthorised login and everything you need to act: the exact canary credential and sensor involved, source IP, JA4 fingerprint, user agent, request path, and timestamp. No legitimate user has any reason to log into a sensor, so the answer is never a risk score. It's yes or no, sending the alerts into the SIEM and SOAR you already run. There are no agents on production systems and no servers to patch.
Before you read further
10 login portals, some are real, some are perimeter sensors
Detection at the earliest possible moment
None of this stops a credential from being stolen, but it creates a cost associated with using one. When any credential in a dump might be a canary, validating stolen access stops being free, and an attacker hesitates. When they do try it, Perimeter Sensors detect that first use, fast and with certainty. By the time a credential reaches an attacker, the compromise has already happened. What you control is how long they operate before you know.
Today that window is long. Breaches that start with stolen credentials run a mean of roughly 246 days before they're identified and contained, the longest-lived of any entry vector (IBM, 2025 Cost of a Data Breach). Once an attacker is in, CrowdStrike's 2026 Global Threat Report clocks the average breakout to lateral movement at 29 minutes. The maths doesn't favour you.
Canaries detect attackers the moment they move. When Riot Games ran a red team exercise, our canaries caught the team at the start of the engagement, without any dwell time. Perimeter Sensors push that moment further forward still, to the perimeter, to the first login attempt.
Availability
Perimeter Sensors are currently in Preview. Book a demo - we'll walk through where Perimeter Sensors fit your stack, what the alert looks like the instant one fires, and how fast it goes live.
For a long time, the attacker only had to be right once. Now they have to be wrong once too.
If you haven't yet - see how many portals you get through before one catches you.
