From Research to Product: How Cremit Built Argus to Solve the NHI Security Gap

We spent six months documenting why non-human identity (NHI) security fails in real organizations. Argus is what we built with what we learned.

Act 1. The problem we kept finding

The first post that made us commit to this direction was about two keys, two bug bounty programs, and zero accountability. A Slack Bot Token had been sitting in a public GitHub repository for three years. An Asana Admin API key, tied to an actively used workspace, had been exposed for two years. Both were reported through official bug bounty programs. Both came back with the same classification: "Out of scope." We wrote about it in The "Out of Scope" Loophole.

What made those two cases worth writing about was not their rarity. It was the opposite. They were representative examples from dozens of similar findings we had seen across our research. The same pattern kept repeating: a valid, high-privilege credential in a public place, known to the organization, and still somehow nobody's responsibility.

So we pulled back and asked a different question. If "Out of scope" is how the industry classifies the symptom, what does the disease actually look like? That question turned into the NHI Kill Chain series, nine episodes covering nine distinct failure modes we kept running into: orphaned keys, shadow service accounts, aged keys, over-privileged keys, zombie keys, drifted keys, publicly exposed keys, unattributed keys, and the structural summary that ties them together.

Six months of writing later, we had a map. The patterns were not isolated bugs in isolated companies. They were predictable, structural, and present almost everywhere we looked. A key would be created for a one-off integration, outlive its owner, accumulate privileges through reuse, drift into a production environment nobody remembered configuring, and eventually leak, often to a place a bug bounty program would refuse to acknowledge. The same sequence appeared in the AI tooling context we documented in AI Supply Chain Attack: Clinejection, and it appeared in mature financial and retail infrastructure we examined during the same period.

The honest conclusion from the research was uncomfortable. The NHI security gap is not caused by organizations being careless. It is caused by the absence of a system designed for the way non-human identities actually behave in modern infrastructure. Humans get offboarded. Credentials don't.

We kept finding the same problem because the problem is the default state.

Act 2. What we learned from the research

Four observations shaped the way we thought about what to build next. We did not start with a product spec. We started with the things our own writing kept circling back to.

Ownership is the first thing that breaks. In almost every case we investigated, the organization could not answer a single question: who owns this credential? Our working estimate across the research is that 40 to 60 percent of active NHIs in a given organization have no clear owner. This was true for mature engineering teams with documented policies. Once an engineer who created a key leaves, or a team reorganizes, or a service is renamed, the ownership trail disappears. Everything downstream of "who owns this" depends on being able to answer it, including rotation, revocation, and audit. So the first Argus design principle became: ownership attestation is not optional, and it has to be continuous.

Detection without response is worse than no detection. This one surprised us. We had assumed the gap was discovery. It wasn't. Many organizations we looked at already knew about specific exposed credentials. What they did not have was a path from "we found it" to "it is rotated and revoked." The gap between finding and fixing is where the attacker lives. We decided early that Argus would not be a scanner that stops at the alert. Response belongs in the product, not in a ticket someone promises to get to.

SaaS credentials are systematically excluded from security programs. The Slack and Asana cases were not outliers. Every security framework we reviewed still treats the perimeter as infrastructure. SaaS tokens, OAuth integrations, CI/CD bots, and vendor API keys live in a category most programs do not cover. The "Out of scope" classification is a symptom of a scope definition problem, not a rule problem. The design principle here was direct: scope expansion. Argus has to treat a Slack Bot Token with the same seriousness as an AWS access key.

Rotation policies exist on paper and fail at scale without automation. Every organization we worked with had a rotation policy. Almost none of them executed it consistently. The reason was always the same. Rotating a credential manually requires finding it, knowing who owns it, coordinating downtime, updating every dependent system, and verifying nothing broke. That is a workflow, not a checkbox. Our Aged Keys post documented how this fails in practice. So the fourth principle became: rotation has to be workflow-integrated, not policy-integrated.

Those four observations are the ones that stayed on the wall. They were the frame we used when we started describing Argus internally.

Act 3. How Argus is built

Argus has four workflows. They map directly to the observations in Act 2. For each one we want to explain what it does, and also where it does not reach yet.

Detection. Argus continuously scans public and private repositories for exposed credentials. The question we get asked most often here is: isn't GitHub Secret Scanning enough? Our honest answer is no, for three reasons. First, GitHub Secret Scanning notifies the vendor who issued the credential, not the organization that owns the code. Slack gets the alert; the engineering team that leaked the token often does not. Second, coverage is partial. Vendor-provider partnerships decide which credential formats are detected, and custom tokens fall through. Third, there is no ownership layer. An alert that nobody owns is just noise. Honest limitation: detection across private repositories requires installation, and organizations with extensive self-hosted Git infrastructure need additional configuration work we are still streamlining.

Ownership mapping. This is the workflow that addresses the "40 to 60 percent have no owner" problem. Argus attempts automatic inference first, using the last committer of the line that introduced the credential, the branch ownership history, and the CI/CD origin of the pipeline that referenced the key. When inference is confident, we attribute. When it is not, we trigger a manual attestation flow that pushes the question to the most likely candidates and records the response. Honest limitation: inference is weaker on credentials introduced through squashed merges or inherited from acquisitions, and we rely on manual attestation more often in those cases than we would like.

Continuous monitoring. Most scanning products are first-discovery products. They alert once, when a credential appears, and go quiet after that. That is not how credential risk actually behaves. A key that was safe yesterday becomes dangerous the moment its scope changes, its usage pattern shifts, or it starts appearing in environments it was not provisioned for. Argus tracks credential behavior over time and alerts on change, not just on first appearance. Honest limitation: behavioral baselines need roughly two weeks of observation before alerts are useful, and during onboarding the signal-to-noise ratio is higher than we want.

Rotation automation. The last workflow ties detection to action. When a credential is confirmed exposed, Argus provides integrations with the issuing services to rotate and revoke, and it coordinates the downstream work: updating secret stores, opening PRs against dependent repositories, and confirming the new credential is live before the old one is killed. This is the workflow that closes the gap we kept writing about. In practice it also gives security and platform teams a defensible artifact for audit, because every rotation has a timestamped trail from exposure detection to verified replacement. Honest limitation: integration coverage is tiered. AWS, GCP, Slack, GitHub, and a handful of widely used SaaS platforms are fully automated. For less common services, Argus currently generates a rotation runbook and tracks completion, rather than executing the rotation itself. We are adding integrations based on customer demand, not vendor partnership convenience, which is slower but keeps the priority list honest.

None of these workflows are magic. Each of them is the implementation of something we already wrote about at length. The research came first.

Act 4. What the research proved about product design

This is the part we find most useful to look at directly. Every episode of the NHI Kill Chain series we published corresponds to a workflow we built into Argus. Reading the table as a single view makes the alignment obvious.

We are not claiming the product solves every instance of every pattern. We are claiming that the workflows in Argus exist because the research told us they had to. When the design pressure came from outside the research, we pushed back. When the design pressure came from a specific failure mode we had documented, we built it in. That is the honest version of how Argus got to where it is.

Act 5. Try it on your own repositories

If what you read here matches what you are seeing in your own organization, the fastest way to find out is to point Argus at a repository you control. We offer a 14-day free trial with no integration commitment at argus.cremit.io. The initial public-repo scan for a single organization typically finishes in under ten minutes, and the results are yours to keep whether you continue past the trial or not.

We wrote all nine episodes of the NHI Kill Chain series before we published a single marketing page about the product. That order matters to us. The research is still where this argument starts. The product is where it lands. If you want to read more of the research side first, the series overview is the shortest path. If you want to see what the problem looks like when it meets a bug bounty program, the "Out of Scope" Loophole is the one we would start with. If your concern is specifically credentials that quietly age out of rotation, the Aged Keys episode is the most direct mirror of what Argus automates today.

Either way, we would rather you see the problem clearly than take our word for it. The product is an argument about how to respond. The research is the case for why the response has to look this way. Read them in either order.