When that AWS service account gets compromised, who do you call?
A question that shouldn't be hard.

If you're in security or platform engineering, you already know the answer is usually "I have no idea." Maybe you search through GitHub commit history. Maybe you ping three different Slack channels. Maybe you can check the wiki that hasn't been updated since 2023. And while you're doing all that detective work, the clock is ticking, and the compromised credential is still active.

This isn't a tooling problem or a people problem, it's an accountability problem. Your organization has spent years hardening human identity security. MFA everywhere, least privilege enforcement, and regular access reviews. But machine identities? Those service accounts, API keys, CI/CD tokens, and bot credentials that outnumber your employees by orders of magnitude? Nobody owns them. Nobody's responsible. And when something goes wrong, everyone pays the price.

We provide ownership in GitGuardian NHI Governance to fix this. With automatic owner suggestions pulled from your existing tools and the flexibility to assign accountability however it makes sense for your team.

The problem everyone is finally talking about

When 2 AM incidents expose the accountability gap

Let's walk through what actually happens during a credential leak. Your secrets detection tool catches a GitHub personal access token in a public repo. It has write access to the production infrastructure. It's the middle of the night.

The race starts: Can you find the owner and rotate the credentials before an attacker finds them?

Without ownership metadata, here's what your security engineer does:

• Check the commit that exposed it (the author left the company six months ago)
• Search Slack for the repo name (find twelve threads, none conclusive)
• Look up the org chart (the team was reorganized twice this year)
• Page someone who might know someone who might know

Forty-five minutes later, you've got a "pretty sure" answer. The credential gets rotated. Maybe nothing bad happened. Maybe you got lucky.

This happens all the time. Not because people are careless, but because accountability for machine identities simply doesn't exist in most organizations. They're created during product sprints, inherited through team transitions, and forgotten when projects end.

Why machine identities are the forgotten stepchildren of IAM

Think about how your company handles human identity governance. There are clear owners for every account. Access gets reviewed quarterly. When someone leaves, offboarding workflows kick in automatically. You have audit trails, approval chains, the works.

Now think about your service accounts. How many do you have? (Most teams guess low by at least 50%.) Who created them? Who uses them? Who's responsible for rotating or deprovisioning when needed? The answers usually range from "unclear" to "absolutely no clue."

We built ownership into NHI Governance

Here's how it works: GitGuardian now assigns and tracks owners for every non-human identity in your inventory. You can see who's responsible, filter by ownership status, and update assignments whenever you need to. It starts working automatically and gives you full control.

How it works (and why we made it automatic)

The last thing you need is another system to manually populate. So we built ownership to learn from your existing tools and data.

GitGuardian analyzes your integrated sources(IAM systems, cloud providers, incident history, and even commit data) and suggests owners based on the strongest available signals. The ranking goes like this:

If your IAM or IdP has an explicit owner field, we use that (highest confidence). Next, we check resource tags for owner metadata. Then we look at who configured the integration, who last edited or created the resource, which developers' commits triggered incidents involving this identity, and who detected associated secrets in public scans.

The system picks the best candidates and suggests up to five owners per identity. You'll see them labeled "Set automatically by GitGuardian" in the detail view. You can keep them, remove them, add more, or replace them entirely. Automatic suggestions never overwrite manual assignments.

Owners suggested automatically by GitGuardian can be confirmed, removed, or supplemented with manual assignments—including external users.

You can override everything

We're opinionated about defaults but flexible about exceptions. Every NHI has an Owners section in its detail view where you can:

• Add owners manually (workspace members or external users by email)
• Remove suggested owners you disagree with
• Replace the entire owner list if needed

External owners don't need GitGuardian accounts. Contractors, external partners, people in other divisions—anyone with an email can be assigned accountability.

The inventory view shows up to two owners per identity in an Owner column. Use the filter to narrow your view: identities with no owner, everything owned by you, or a specific person's responsibilities.

Filter the NHI inventory by owner to find unassigned identities or see all credentials you're responsible for.

If you want to automate ownership assignment during provisioning or sync with your CMDB, the public API has you covered. Use the nhi:ownership: read and nhi:ownership: write scopes to list, add, remove, or replace owners programmatically.

What changes when every identity has an owner

Incident response that doesn't require a manhunt

Remember that 2 AM credential leak scenario? With ownership, the process is completely different.

Alert fires. Security engineer opens the NHI detail view. Sees the owner. Pings them in Slack. Credential gets rotated. Done.

That time savings compounds. When your team isn't spending half their day tracking down owners for incidents, they can focus on the actual security work: threat modeling, control improvements, risk reduction.

The orphaned account problem actually gets solved

Orphaned identities (machine credentials that outlive their projects or creators) are some of the easiest targets for attackers. They typically have over-provisioned permissions, no rotation schedule, and zero monitoring. They're just sitting there waiting to be abused.

Ownership doesn't magically delete orphaned accounts, but it creates the conditions for hygiene at scale. Filter the inventory for "No owner" and you instantly see every identity that needs attention. Assign owners so that when projects shut down or people leave, their associated identities get reviewed and deprovisioned.

Auditors stop asking the same question twelve times

If you've been through SOC 2, PCI-DSS, or HIPAA audits, you know the drill. Auditors want proof of accountability for privileged access. They ask questions like:

• "Who is responsible for this service account?"
• "How do you enforce least privilege?"
• "What happens when someone with access leaves the company?"

Without ownership data, you pull together spreadsheets, dig through tickets, and reconstruct timelines from memory. It takes weeks. Findings pile up because you can't definitively prove accountability.

With ownership, you export the data. The audit that used to take three weeks takes three hours. Every identity has a clear owner. You can show assignment history, prove continuous accountability, and demonstrate segregation of duties. Auditors get their evidence, you get back to work.

Try it yourself

Ownership is now live in GitGuardian NHI Governance. Here's how to get started:

Open NHI Governance → Identities, and you'll see the new Owner column. Filter by "No owner" to see which identities need attention. Click into any NHI and use the Owners section to add, edit, or confirm ownership. If you want to automate things, check out the API docs.

Learn more: NHI Ownership documentation

Get started: Sign in to GitGuardian or request a demo

Stop spending your nights hunting down owners for compromised credentials. Make accountability part of your identity model from the start.