If you're an IAM lead, you've probably spent the last five years perfecting your human identity security. MFA everywhere. Privileged management locked down. Just-in-time access is working like a charm. Your employees' identities are pretty well governed overall.
But here's what's keeping us up at night, and I suspect you too: for every employee identity you're managing, roughly hundreds of machine identities are doing who knows what. API keys in places you didn't know existed. Service accounts that three different teams think someone else is managing. Bot tokens with access to production data that were created by an engineer who left the company two years ago.
And the worst part is that when AWS credentials get exposed, attackers are probing them in under 17 minutes (according to research). That's less time than it takes most of us to grab coffee and check Slack.
We've expanded GitGuardian NHI Governance with integrations across your entire infrastructure stack—giving you a single, identity-first view of every machine credential, automatic risk scoring based on OWASP's Top 10 for NHIs, and one-click revocation when secrets are exposed. Instead of logging into a dozen different platforms to piece together which service accounts exist and what they can access, you now get complete visibility and control from one place.
Why your IAM platform isn't cutting it for machine identities
Your IAM platform can be great at what it was designed to do. But it was designed in an era when "identity" meant Bob from accounting logging into Salesforce. It wasn't built for a world where your infrastructure runs on hundreds of service accounts, your data pipelines are orchestrated by API keys, and your AI agents are making autonomous decisions with privileged credentials.
The problem isn’t that these identities don’t matter; they do. The issue is that your organization lacks clear visibility into everywhere they are:
- Scattered across different secrets managers (because different teams picked different tools)
- Living in SaaS platforms your security team doesn't even know about
- Provisioned with way too many permissions because "we'll lock it down later"
- Never rotated because nobody's quite sure what will break if they do
And 70% of the secrets that leaked in 2022 are still active. Not because people don't care, but because they literally don't know those credentials exist.
What we're covering now (and why it matters)
We've expanded our integration coverage across your entire infrastructure. Here's what's available and why each piece matters.
The foundation: Secrets managers
First, we cover everywhere you're supposed to be storing secrets:
Enterprise vaults: HashiCorp Vault, CyberArk (both SaaS and self-hosted), Akeyless, Delinea Secret Server
Cloud-native: AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager
Our ggscout agent pulls metadata without ever touching the actual secret values. We hash everything locally before it leaves your environment, because the last thing you need is another tool that could leak your secrets.
Infrastructure & CI/CD: Where it all runs
Kubernetes: Service accounts and secrets across your clusters, because if you're running containerized workloads, these credentials are everywhere and notoriously hard to track.
GitLab CI: Pipeline credentials and job tokens that your CI/CD workflows depend on. These often have elevated permissions and rarely get rotated.
Cloud IAM: Because context is everything
Knowing a credential exists is step one. Understanding what damage it could do? That's the real question you need answered at 2 AM during an incident.
Microsoft Entra ID: We pull in users, service principals, managed identities, security groups—the whole picture. And we map out what permissions they actually have.
AWS IAM: Same deal. Users, roles, and groups, with full policy analysis.
Both of these use OIDC authentication. Why? Because we're not going to tell you to eliminate long-lived secrets while using them ourselves for integrations.
The platform automatically figures out which credentials are the highest risk, like that leaked API key that has admin access to your entire AWS environment. Those bubble to the top.
The stuff that keeps you up at night: SaaS platforms
This is where it gets interesting, because this is where traditional IAM tools just... stop. But it's also where a ton of your sensitive data actually lives.
AI platforms (Anthropic, OpenAI): With everyone rushing to build AI features, these API keys are multiplying like rabbits. We need to know where they are and who's using them.
Workflow automation (N8n, Airbyte): These tools are the "plumbing" of modern infrastructure. They have credentials that touch everything.
Observability (Datadog): Your monitoring tools have the keys to your entire infrastructure. If those get compromised, attackers know everything about your environment before they even start.
Collaboration (Slack): Bot tokens might seem low-risk until you realize they have access to every private channel where your engineers discuss security issues.
Data platforms (Snowflake): This one's obvious. If you're storing customer data there, you need to know exactly which service accounts can access it.
Identity providers (Okta, Auth0): Even your IdP has service accounts. They just happen to be the most privileged ones in your entire environment.
Artifact management (JFrog): Credentials that can push to or pull from your artifact repositories, critical for supply chain security.
Business intelligence (Metabase): Service accounts accessing your BI tools often have broad data access that needs governance.
What you can actually do with all this
Building a giant inventory is neat, but if it just sits there, who cares? Here's what's different:
One place to see everything: Instead of logging into five different secrets managers, three cloud consoles, and a dozen SaaS admin panels, you get one view. Identity-first. You pick the service account, you see everywhere it exists, everything it can access, and everyone who's using it.
Automatic risk scoring: We built this on OWASP's Top 10 for NHIs because that's the framework everyone's using. The platform automatically flags:
- Leaked secrets (we're pretty good at finding those)
- Secrets living in both production and dev
- The same credential used in multiple places
- Secrets that haven't been rotated in forever
- Orphaned accounts that nobody owns anymore
The graph view that actually helps: When you find a compromised credential, the platform shows you the whole dependency chain. What services are using it? What data can they access? What will break if you revoke it? This is the stuff that used to take hours of Slack messages and emergency meetings.
Kill switch for leaked secrets: For GitHub, GitLab, and OpenAI secrets, when we detect exposure, you can revoke them with one click. Right from the alert. No copying tokens, no logging into different consoles, no delay while attackers are already poking around.
Metrics that matter: MTTR for secret remediation. Policy compliance trends. Secrets' age distribution. The stuff your manager actually wants to see when they ask, "How are we doing on this?"
This works in the real world
We built this to be enterprise-ready from day one:
- ggscout never exposes your secret values
- OIDC auth means no long-lived integration credentials
- SOC 2 Type II compliant
- Self-hosted option for the "nothing leaves our datacenter" crowd
- Scales to thousands of integrations without turning into molasses
Why this matters right now
Regulators are starting to pay attention to machine identity governance. It's no longer enough to say "we manage our employees' access really well" while ignoring the 100x larger population of service accounts and API keys.
The identity perimeter changed. Most security programs just haven't caught up yet.
If you're a CISO, this gives you the visibility to actually answer when the board asks about your attack surface. With receipts.
If you're an IAM lead, this lets you extend the same lifecycle governance you've built for humans to the machine identities that actually run your business.
If you're a security architect building zero trust, this gives you the telemetry you need to validate that "never trust, always verify" actually means something.
Getting started
If you're already a GitGuardian NHI Governance customer:
- Go to Settings > Integrations > Sources > NHI Governance
- Connect whatever platforms you use
- Start discovering what's been hiding in plain sight
Not using us yet? Talk to our team or check out our interactive demo.
Because at some point, we all need to admit that managing human identities while ignoring machine identities is like locking the front door while leaving every window open.
Let's close those windows.
GitGuardian provides secrets security and NHI governance for enterprises that are tired of machine identities being an afterthought. Learn more at gitguardian.com/nhi-governance.
