Non-Human Identity Security: Governing the Machine Credentials That Are Quietly Becoming Your Biggest Cloud Vulnerability

Twenty years into building cloud infrastructure, I have watched the security industry pivot its attention from one threat category to the next. Perimeter firewalls gave way to endpoint detection. Endpoint detection gave way to identity-centric security. And now identity-centric security is grappling with an inconvenient truth: we spent years securing how humans authenticate, and almost no time securing how machines do it.

Non-human identities (NHIs) are the dominant identity class in every enterprise I work with today. The average machine-to-human ratio sits around 45:1. In cloud-native environments running active Kubernetes deployments and multiple CI/CD pipelines, that ratio climbs to 144:1. And with AI agents being deployed across engineering organizations at speed in 2026, the ratio is accelerating in ways that should make every security architect genuinely uncomfortable.

The Entro Security 2025 State of Non-Human Identities report put numbers to what I have been seeing in the field: 97% of NHIs carry excessive privileges, nearly half have not had credentials rotated in over a year, and two-thirds of enterprises surveyed have suffered at least one breach traceable to a compromised non-human identity. The biggest SaaS breach of 2025 started with an attacker exploiting stale OAuth tokens from a third-party integration, which then cascaded into hundreds of downstream customer environments.

If your security posture is mature on the human side (MFA enforced, SSO deployed, quarterly access reviews running) but you have not built equivalent discipline for machine identities, you have a serious asymmetry in your defenses. That asymmetry is what attackers are exploiting right now. This article is about closing the gap.

What Counts as a Non-Human Identity

The term “non-human identity” covers a broader surface than most teams initially realize. Here is the taxonomy you need to manage:

Service accounts are the accounts created in cloud providers (AWS IAM roles, GCP service accounts, Azure managed identities) or in operating systems that applications and automated processes use to authenticate. They are the most common NHI type, and they accumulate fast. Every microservice, every scheduled job, every infrastructure automation script tends to get its own service account, often created by a developer who then moves on to something else.

Long-lived API keys are static credentials issued by cloud providers, SaaS platforms, payment processors, and internal services. They are convenient to create and disastrous to leave unmanaged. API keys typically do not expire by default. They get copied into environment variables, pasted into configuration files, and eventually end up in version control. GitGuardian’s research puts the number of secrets committed to public GitHub repos in the millions per year, and that number keeps growing.

OAuth tokens and app-to-app integrations are the invisible connective tissue of the modern SaaS stack. When your JIRA integrates with Slack, when your CI system pushes deployments to your cloud provider, when your monitoring tool reads your Kubernetes API: each of those connections creates an OAuth token or similar credential that persists in the background, often with permissions far broader than the integration actually needs.

Machine certificates are X.509 certs used for mTLS between services, issued by internal certificate authorities or by standards like SPIFFE. Certificate lifecycle management is its own discipline, and I covered it in the article on SPIFFE and SPIRE for workload identity. When rotation is not automated, expired certs cause outages. When rotation is automated but not monitored, compromised certs can go undetected for weeks.

CI/CD pipeline credentials are the credentials your build systems use to pull from artifact registries, deploy to cloud environments, run tests against staging databases, and push container images. A pipeline credential typically has read access to secrets, write access to production environments, and the implicit trust of every developer who has ever merged a pull request. I have audited organizations where a single GitHub Actions secret had effectively admin-level access to five AWS accounts.

AI agent credentials are the newest and fastest-growing category. Every AI agent that reads a database, calls an external API, sends an email, or queries a vector store needs credentials to do those things. Unlike human employees who request access through a ticketing system, AI agents often have credentials provisioned by a developer in thirty seconds with no access review at all. The security challenges specific to AI agents are significant even before you factor in the identity governance problem layered on top.

Why Machine Identities Spiral Out of Control

The fundamental problem is organizational, not technical. Humans get onboarded through HR processes that eventually also drive identity lifecycle management. When an employee leaves, offboarding procedures (when they work) revoke access. Machine identities have no equivalent lifecycle. They are created by engineers during development, often as a short-term measure that becomes permanent, and then they outlive the projects, services, and people who created them.

I have done NHI audits for organizations that discovered service accounts created six or seven years ago, still active, still carrying broad permissions, with no clear owner. The engineer who created them left the company years ago. The documentation is gone. The system those accounts were created for was decommissioned and rebuilt twice. But the IAM role is still there, still assumable, still granting S3 read access to three production buckets.

The scale compounds because there is rarely a central registry. Cloud provider consoles show you the IAM entities in that specific cloud account. Your secrets manager shows you the secrets stored there. Your SaaS platforms each have their own OAuth app management interfaces. Your CI/CD system has its own credential store. None of these systems talk to each other. Building a complete inventory of every NHI in your estate requires stitching together a dozen data sources, which is exactly why most organizations have never attempted it.

There is also the shadow NHI problem: credentials that live entirely outside your sanctioned systems. Developers create personal API keys using their own accounts for faster iteration. Service credentials get hardcoded in Dockerfiles. Local development configurations with production credentials get accidentally pushed to repositories. Each of these is a shadow identity your security team does not know exists until it gets exploited.

How Attackers Exploit Non-Human Identities

When a threat actor wants access to your cloud environment, they have two main paths: compromise a human identity (phishing a user, cracking a password, stealing MFA codes) or compromise a machine identity (finding an exposed API key, exploiting a CI/CD pipeline, escalating from a compromised service account). The machine path is increasingly preferred because of three structural advantages for the attacker.

Credentials are often long-lived. An API key accidentally pushed to a public GitHub repo three years ago may still be valid today. There is no session expiry, no suspicious login alert, no geography-based anomaly detection to trigger.

Privileges are often excessive. The 97% excessive-privilege statistic reflects a real pattern: it is easier to grant an IAM role AdministratorAccess than to figure out the minimum required permissions. That developer convenience becomes an attacker’s force multiplier.

Detection is harder. When an attacker authenticates as a service account, the authentication looks legitimate. There is no failed login attempt to alert on, no unusual user-agent string, no geographic impossibility. The traffic blends into normal operational activity.

The attack chain for an NHI breach follows a consistent pattern: find an exposed credential (public git repo, misconfigured S3 bucket containing a config file, compromised developer laptop). Use that credential to gain initial access, starting with read-only operations to avoid triggering alerts. Enumerate what other permissions the NHI carries. Escalate by using the service account’s permissions to assume higher-privileged roles, access other services, or create new credentials. Establish persistence before anyone notices. Cloud environments are especially susceptible to this chain because cloud IAM is designed for inter-service trust: a compromised service account in one part of your environment may be able to assume roles across multiple accounts or impersonate other services entirely.

The NHI Governance Lifecycle

Securing non-human identities requires the same lifecycle discipline you apply to human identity governance. The phases are: discover, classify, right-size, rotate, and monitor.

Discover

You cannot secure what you do not know exists. The first step is building a complete inventory across your estate: pull service accounts from every cloud account and region, scan your secrets manager and any legacy credential stores, ingest OAuth app registrations from your SaaS platforms, query your CI/CD systems for stored credentials, and scan code repositories for hardcoded secrets.

Automated scanning is non-negotiable at any reasonable scale. Tools like GitGuardian handle the git history and repository scanning side. Cloud-native tools like AWS IAM Access Analyzer and Google Cloud’s IAM Recommender provide utilization data on service accounts. Dedicated NHI platforms (Entro, Astrix, Token Security) aggregate across all these sources and build a unified inventory. This discovery step is almost always sobering. I have never done an NHI inventory exercise that did not surface credentials the team had forgotten existed, integrations no one had documented, and service accounts with privileges that far exceeded any current use case.

Classify

Once you have the inventory, classify each NHI by sensitivity, ownership, and usage. Sensitivity asks: what could an attacker do with this credential? An API key for a read-only monitoring integration is lower risk than a service account with write access to production infrastructure. Assign risk tiers accordingly.

Ownership asks: who is responsible for this credential? Every NHI needs a human or team owner accountable for its existence and responsible for reviewing its permissions. In a microservices environment, the team that owns the service should own the service accounts that service uses, following the same principles that govern Kubernetes RBAC and service account ownership.

Usage asks: is this credential still active? IAM Access Analyzer’s last-accessed data and equivalent features from other providers let you see when a credential was last used. A service account unused for ninety days is either orphaned or tied to a periodic job you have forgotten about. Either way, it warrants investigation before you assume it is safe to leave in place.

Right-Size Permissions

The principle of least privilege applies to machine identities exactly as it does to human identities. Every NHI should have precisely the permissions needed to perform its function and nothing more.

In practice, right-sizing starts with IAM Access Analyzer and equivalents that show you which permissions an entity has versus which it actually uses. AWS’s IAM Access Analyzer can generate least-privilege policies from observed access patterns. GCP has an equivalent in the IAM Recommender. These automated suggestions are a starting point, not a finish line: a human needs to review them in context before applying them.

For new NHIs, shift this left. Make minimal IAM policy definition a standard part of the creation workflow, not a cleanup exercise afterward. Require policy review as part of the pull request process for any infrastructure code that creates service accounts. The connection to workload identity federation matters here: if your services still authenticate to cloud providers using long-lived IAM user credentials with static access keys, that is the first thing to change. Workload identity federation (IRSA on EKS, GKE Workload Identity, Azure Workload Identity) replaces static credentials with short-lived tokens tied to the workload’s identity. No long-lived key to rotate, no key to leak, no key to accidentally commit.

Rotate Credentials

For credentials that cannot be replaced with workload identity, rotation is mandatory. The industry is converging on short rotation windows: API keys should rotate at least every 90 days, and for high-risk integrations, considerably more frequently.

Automated rotation is the only rotation that actually happens at scale. HashiCorp Vault’s dynamic secrets feature is one of the most powerful tools here: instead of storing long-lived credentials, Vault generates ephemeral credentials on demand with a configurable TTL. A database credential generated by Vault for a specific service might be valid for only one hour. When it expires, it is automatically revoked. There is nothing to steal and stockpile.

Cloud-native equivalents exist: AWS Secrets Manager has built-in rotation lambdas for RDS, Redshift, and other services. But rotation only helps if it is comprehensive. The common failure mode is rotating credentials in the secrets manager while missing the seventeen other places that credential was copied to, leading to application outages that teach teams to avoid rotation. That is exactly the wrong lesson to draw, and it is a predictable consequence of doing rotation as a manual, ad hoc operation.

Monitor and Detect

The final phase is ongoing monitoring for anomalous NHI behavior. This is harder than monitoring human identity because there is no “this service account just logged in from Lagos when it normally logs in from us-east-1” equivalent. Machine identity traffic looks consistent until it does not.

Effective NHI monitoring detects: sudden spikes in API call volume from a service account, service accounts calling APIs they have never called before, credentials used from IP addresses outside your known infrastructure ranges, authentication events at times inconsistent with the service’s normal schedule, and multiple failed authentication attempts followed by a successful one.

Cloud providers publish these events through CloudTrail (AWS), Cloud Audit Logs (GCP), and Azure Monitor. Building detection rules on top of these logs is how you catch NHI compromises in progress rather than weeks after the fact. Your monitoring and logging stack needs to be ingesting identity plane events, not just application and infrastructure logs. Identity plane visibility is what separates teams that detect NHI compromises in hours from teams that find out about them through third parties.

The NHI Tooling Landscape

The tooling market for NHI security has matured significantly in the past two years, moving from scattered point solutions to purpose-built platforms.

Purpose-built NHI platforms are the newest and fastest-growing category. Entro Security, Astrix Security, and Token Security all provide unified NHI inventory, risk scoring, and remediation workflows that span cloud providers and SaaS platforms. These tools connect to your cloud accounts, git repositories, CI/CD systems, and SaaS platforms via APIs and build the cross-system inventory that is otherwise manually painful. Clutch Security focuses specifically on AI agent credentials. Aembit takes a different approach: dynamic, just-in-time credential issuance for service-to-service communication, so workloads never hold long-lived credentials at all.

Vault and cloud-native secrets managers remain the foundation for credential storage and dynamic secret generation. HashiCorp Vault is the most full-featured option, with support for dynamic secrets across a wide range of integrations and the ability to generate short-lived credentials for databases, cloud providers, and PKI systems. AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault are simpler but deeply integrated with their respective providers. For most organizations, cloud-native secrets managers handle cloud workloads well, while Vault earns its place when you need dynamic credential generation or multi-cloud support.

Cloud IAM tools from the providers themselves are significantly underutilized. AWS IAM Access Analyzer, GCP IAM Recommender, and Azure IAM Access Reviews are free and genuinely useful for identifying over-privileged service accounts and generating least-privilege policy recommendations. Their limitation is that they only see their own cloud’s identities, so they cover only a fraction of your total NHI estate.

Secret scanning tools like GitGuardian and Trufflehog address the exposed-credentials problem specifically. They scan git history, CI/CD pipelines, and sometimes live environments for credentials that have leaked outside their sanctioned location. This is detective control, not preventive, but catching an exposed credential quickly changes the blast radius dramatically. The software supply chain security implications are worth noting: your build pipeline is also an NHI attack surface, and the credentials used in CI/CD pipelines need the same governance discipline you apply to production services.

AI Agents Are Accelerating the Problem

The AI agent deployment wave is the variable that changes the difficulty calculus for NHI governance in 2026. Every AI agent that interacts with real systems needs credentials. Those credentials need to be scoped, rotated, monitored, and revocable. And unlike traditional services that have stable, predictable permission requirements, AI agents often need broad, dynamic access to be useful, which conflicts directly with least-privilege.

I have talked with security teams at companies deploying dozens of AI agents across their engineering organizations, and the pattern is consistent: developers provision agents with permissive credentials because restricting them too tightly breaks agent functionality in hard-to-debug ways. Agents accumulate credentials faster than any tracking system follows. And the credentials tend to be long-lived because rotating them requires redeployment, which is more friction than developers want to deal with in iteration-heavy AI development cycles.

The secure AI agent architecture discussion covers prompt injection and guardrails, but the identity layer is a separate problem. An AI agent that can access your databases, email systems, and cloud APIs with a single static credential set represents a single point of compromise for a significant portion of your environment. If that agent’s credential is stolen, the attacker inherits everything the agent can do, typically with no session context that would trigger anomaly detection.

The mitigation approach: treat AI agent credentials as high-sensitivity NHIs from provisioning time, apply just-in-time dynamic credential issuance with short TTLs, implement audit logging on every action the agent takes so you can reconstruct post-compromise behavior, and enforce strict scoping even when it requires more careful agent design. The tools emerging specifically for AI agent identity management are worth evaluating if you are deploying agents at any scale. The alternative is attempting to bolt governance onto agents after the fact, which is harder than building it in from the beginning and significantly less effective.

This Is the Core of Zero Trust for Machines

Non-human identity governance is not a standalone initiative. It is a load-bearing component of any zero trust architecture that takes machine-to-machine communication seriously. The zero trust principle of “never trust, always verify” applies to service calls exactly as it does to human access. Every service interaction should authenticate explicitly, carry minimum required permissions for that specific operation, and generate an auditable record.

The practical zero trust implementation for NHIs includes: no static, shared credentials in configuration files or environment variables; workload identity wherever the platform supports it; mTLS between services using short-lived certificates from an automated PKI; continuous verification that service accounts are still needed and still appropriately scoped; and automated detection when NHI behavior deviates from baseline.

This is a real operational investment. But the alternative, which is what most organizations are currently running, is a large, invisible attack surface where a single stolen API key can cascade into a production breach affecting multiple services and environments. I have seen that play out enough times to know which posture I would rather defend.

Where to Start

If NHI governance is new territory for your team, prioritize in this order:

Begin with discovery across a narrow scope. Pick one cloud account, one SaaS platform you know is broadly integrated, and your primary CI/CD system. Run an NHI inventory across those three. The results will define the scope of the problem for your organization better than any external threat model can.

Fix the obvious findings immediately: rotate any credentials that have not been rotated in over a year, revoke any NHIs with no clear owner, and apply workload identity federation for any service still using static IAM user credentials with long-lived access keys.

Build rotation automation before expanding scope. If you try to scale NHI governance without automated rotation, you create unsustainable operational overhead and teach engineers that security slows things down.

Instrument detection. Get IAM and API-plane events flowing into your SIEM and write baseline detection rules before building more complex governance machinery. You cannot improve what you do not measure, and you cannot investigate what you cannot see.

Then expand systematically: add more cloud accounts, add SaaS platforms, add AI agents as they are deployed. The framework scales with consistent application. The organizations that will have strong NHI postures in 2027 are the ones starting to build this discipline now, while the attack pattern is becoming clear but before the incident that forces the issue. In my experience, there are always two ways to learn security lessons. The proactive window is still open here. Take it.