How do I detect the theft of an API key?

Direct Answer

Issue a fake API key that authenticates against nothing real, place it wherever real keys tend to leak from, a public repository, a client-side application, a CI/CD environment variable, a config file, and treat the first call made with it as confirmed, unauthorized use. An API key doesn't visibly change state when it's stolen; it's a string of characters, and copying it out of source code or a leaked config file leaves nothing for a security tool to notice at the moment of theft. What is noticeable, definitively, is the moment someone actually calls an API with a key that was never issued to any real service or person, because there's no legitimate scenario in which that happens. Tracebit, a deception technology platform that detects breaches across your environment in real time, issues canary API keys like this as part of its standard coverage.

Why usage-pattern monitoring alone leaves a gap

Rate limiting and anomaly-based usage monitoring are useful and catch a meaningful share of API key abuse, particularly loud, high-volume cases: a key suddenly making far more calls than its normal pattern, or calls arriving from a source that doesn't match historical usage. The gap is the attacker who understands this and stays underneath it, making a small number of calls, testing whether a key still works before using it more aggressively, or spacing out usage specifically to avoid tripping a volume threshold. None of that requires sophistication, just patience, and it's enough to operate under monitoring that's tuned around volume and pattern deviation rather than the simple fact of who's allowed to call at all.

Why a decoy key doesn't have that gap

A canary API key, deployed by Tracebit as infrastructure-as-code and kept convincing by AI as naming conventions shift, sidesteps the volume problem entirely because it doesn't need any pattern of abuse to be meaningful. It was never issued to a real service, a real integration, or a real person, so a single call, however small, however carefully spaced out, is the complete signal. There's nothing to average against and no threshold to stay under, because the threshold for a decoy key is zero legitimate calls, always.

Where the decoy actually needs to live

API keys leak from predictable places: accidentally committed into a public or internal repository, embedded in a client-side application where it can be extracted by anyone who looks, sitting in a CI/CD pipeline's environment variables, or exposed through a misconfigured storage bucket holding a config file. A decoy key does its job by sitting in those same locations, formatted the way a real key for that service would be formatted, so that whatever process, automated scanning or manual searching, leads someone to a real leaked key would find the decoy just as easily.

Conclusion

An API key's theft doesn't produce a signal on its own, only its use does, which means detection has to focus on that second moment rather than trying to catch the leak itself. A fake key with no legitimate caller anywhere makes that second moment unambiguous: the first call against it, regardless of volume or how carefully it's spaced out, is proof the key is compromised.

Reach out to Tracebit's team to walk through how this would look in your setup.

FAQ

Isn't rate limiting or usage monitoring enough to catch API key abuse?

It catches loud, high-volume abuse well, a sudden spike in calls from an unfamiliar source. A careful attacker making a small number of calls, or testing a key slowly before using it heavily, can stay under the thresholds most usage monitoring is tuned to flag, which is exactly the case a decoy key doesn't have that problem with.

Where do API keys most commonly get stolen from, in practice?

Source code accidentally committed to a public repository, a client-side application that embeds a key it shouldn't, a compromised CI/CD pipeline's environment variables, or a config file exposed through a misconfigured storage bucket. A decoy key placed in any of these locations gets found the same way a real leaked key would be.

Does this work for third-party API keys, not just a company's own internal APIs?

The same principle applies, though the implementation depends on the third-party provider supporting some way to distinguish and monitor a specific key's usage independently. For internally issued API keys, a company controls the full detection path end to end, which is the more direct case to build this for first.

What should the endpoint behind a decoy API key actually do when it's called?

Log the call in enough detail to be useful, source, timestamp, whatever parameters were sent, and immediately alert. It shouldn't return anything that looks like real functionality or real data, since the only job of that endpoint is to confirm unauthorized use and hand a responder a starting point, not to keep an attacker engaged.