Product showcase: GitGuardian Honeytoken catches credential theft as it happens

Product showcase: GitGuardian Honeytoken catches credential theft as it happens Credential harvesting on developer machines has widened. Earlier infostealers worked from a short list of known targets, mostly browser stores and a few cloud credential paths. The families active now cast a much wider net. Shai-Hulud, for instance, ran a secret scanner across the entire filesystem and validated whatever it turned up, rather than checking a handful of expected locations. That breadth is what makes deception practical, and the speed is what makes it urgent. A harvester that validates what it collects tests a stolen credential in seconds, not hours. Initial compromise is no longer a window you get to investigate. By the time anyone would normally think to look, the credential has already been taken, checked, and used. An attacker sweeping a whole disk for anything credential-shaped will pick up a decoy wherever it happens to sit, and will test it along with everything else. That first validation attempt is the alert, and it is the only moment early enough to matter. Why deception has underperformed its promise Behavioral detection works from hints. It watches process activity, file operations, and network calls, weighs them against known patterns, and estimates how likely it is that something malicious is happening. Good products estimate well, but the estimate is still the product. A honeytoken removes the inference. The credential exists for no reason other than to be stolen, so nothing in normal engineering work has any cause to touch it. Its use is not evidence of an intrusion; it is the intrusion. Because there is nothing to weigh, there is nothing to get wrong, which is where the near-zero false-positive rate comes from. Given all that, the obvious question is why deception is not already everywhere. The answer is operational rather than conceptual. Planting decoys by hand does not scale past a handful of high-value systems. Someone has to decide what to plant, where to put it, and keep it there as machines are reimaged and developers come and go. A decoy that quietly disappears after three months is worse than no decoy at all, because the team believes it is covered. GitGuardian introduced fleet-wide deployment through mobile device management (MDM), which removed the manual planting problem: an agent already running on every machine can place a decoy and put it back if someone deletes it. Research into how credential stealers actually behave solved the other half, since we no longer have to guess what a stealer will find attractive when we can study what it collects and match it. What runs today Honeytokens have been part of the GitGuardian platform for several years, and what teams can do with them today is broader than the term “decoy credential” suggests. Teams create honeytokens through the dashboard, the API, or the command line. They then place them wherever an attacker is likely to go looking: source code repositories, configuration files, internal documentation, deployment scripts, and continuous integration pipelines. A planted honeytoken resolved to the machine it sits on and the credential file it was written to. The events table is empty, which is what an untouched decoy looks like. Since June 2026, that placement extends to developer laptops. Honeytokens deploy across the fleet through existing MDM tooling, which means a security team can cover several thousand machines without touching any of them individually, and the dashboard reports which endpoints actually carry a decoy rather than leaving anyone to assume coverage. Decoys that get deleted are replaced on the next sync. Honeytoken protection on a single endpoint, showing the last sync, how many decoys are deployed, and how long the machine has been covered. The token is active and has never been triggered. Operationally, the alerting is what matters. When someone attempts to use a honeytoken, GitGuardian raises an incident naming the machine and the file the credential came from, then routes it through whatever the team already runs, whether that is email, Slack, Teams, ServiceNow, or a webhook of their own. Nobody has to watch a new console, which is less trivial than it sounds when most detection tooling asks a team to absorb more alerts than it did the week before. This one asks them to absorb an alert that is always worth acting on. Extending the bait beyond cloud keys Today’s GitGuardian honeytokens are AWS credentials, and the decoy is a real key issued from an AWS account that GitGuardian controls. Every API call made against that key is logged in the account it belongs to, so when an attacker tests the credential, we see the attempt, along with when it happened and where it came from. Most credentials on a developer machine offer nothing comparable. Kubernetes cluster access, package registry logins, and other service credentials follow different formats and route to different places, and several are among the first things the package registry worms go looking for. Covering them takes more than writing a convincing-looking file to disk, because something has to be waiting at the other end when the attacker tries it, ready to recognize the attempt and trace it back to a specific customer and machine. That is the work underway now, and it is deliberately built once rather than rebuilt for every credential type. Because nothing after the alert has to change, each new kind of decoy arrives inside the setup a customer already has: the same incident, the same notification routes, and the same workflow. Designing decoys that hold up A decoy is only useful while an attacker cannot tell it apart from a real credential, and that constraint shapes the design more than anything else. The credential formats we are adding carry no internal structure that could give a decoy away. The identifier inside the file is random, with no encoded owner or account for an attacker to work out, so a stolen decoy tells them nothing even under close inspection. The infrastructure behind those decoys is kept separate from anything that would identify it as ours, on the assumption that a motivated attacker will eventually go looking. Beyond that baseline, though, effective deception turns out to depend far less on elaborate camouflage than most threat models would suggest, because the malware doing the collecting is nowhere near as discerning as the adversary those models are built around. What matters is matching how credentials are actually harvested in the wild, which is a lower bar than designing against a hypothetical attacker and a considerably more useful one. An honest limit Deception detects use, not theft. A decoy that is stolen and never touched again will stay quiet, and no implementation can change that, because the control only fires when someone acts on what they took. This is the reason deception belongs alongside credential discovery rather than in place of it. Discovery tells you which valid credentials are exposed on a machine and hands you a list to revoke, while deception tells you the moment someone reaches for one. A team running only the first has an inventory of risk with nothing watching it, and a team running only the second is waiting on an alert about exposure it never measured. Where this goes next The work runs in two directions: more places to plant, and more kinds of honeytoken to plant. On placement, continuous integration runners and Kubernetes clusters are both in scope, since recent worm variants were built to land in build environments. On coverage, Kubernetes configuration files and package registry logins are the credential types we are building toward. Google Cloud and Azure credentials sit further down the list, because our review of infostealer samples shows they are barely touched today. We would rather add coverage where the harvesting is actually happening. Where honeytokens sit in the GitGuardian platform Honeytokens are the deception layer of the GitGuardian secrets and non-human identity security platform. Developer Endpoint Protection is what plants and maintains them across a developer fleet. Together with credential discovery, they answer the two questions a security team has about any machine: what is exposed on it, and has anyone reached for it. The credential surface on a developer machine keeps growing, and AI coding tools are adding new paths to it every quarter. The teams that will catch a harvest early are the ones with something waiting in those paths before the harvest happens. See it running end to end in a live GitGuardian platform demo, from developer endpoints to identity visibility.