Non-human identities (NHIs) are the service accounts, API keys, tokens, and certificates that power cloud environments and SDLC. They outnumber human identities in organizations (by 92:1) and have quietly become one of the largest attack surfaces in cloud security. As we rapidly adopt cloud services, SaaS and GenAI, NHIs are a critical risk — so much so that they’re climbing to the top of CISO priority lists.
In this blog, we’ll take a deeper look into the three core elements that make up an NHI (in most cases): Consumers, Secrets, and Entitlements. Understanding these components and how they work together is key to securing NHIs and closing off attack paths before they’re exploited.
Element 1: Consumers or the “Machines” Behind the Identities
NHIs are machine identities linked to apps, workloads, and devices that allow them to execute actions at scale on target resources. Developers generate them to automate workflows, integrate third-party services, and enable communication between machines, platforms, or on-prem software.
Almost every non-human identity starts with a consumer – the application, service, device, or automated workload that consumes credentials to authenticate and interact with other systems. In simple terms, consumers are essentially “the who” of NHIs.
For example, AWS refers to applications or backend processes that require credentials to make requests to cloud services (e.g., read data from S3 bucket). In Azure, this might be a service principal or a managed identity assigned to a resource like a VM or Azure Function. In both cloud environments, the consumer is the actor that needs to be identified and authorized in order to access and perform tasks on target resources like databases, APIs, LLMs, etc.
Consumers range from microservices calling internal and external APIs, to CI/CD tools deploying infrastructure, to AI agents and third-party services integrated via API keys.
Think of a consumer like a tourist moving between different locations; the tourist is the entity that initiates the action, crossing borders and accessing new countries. But to move freely, they need the right identification, which brings us to the next NHI core element: Secrets.
Element 2: Secrets or the NHI Credentials
If the consumer is the “who”, Secrets are the “proof”.
Putting the “I” in NHIs, secrets or programmatic access credentials are the actual API keys, authentication tokens, passwords, and certificates that consumers use when they authenticate and gain access to resources. In essence, a secret is what allows a non-human identity to say, “I am allowed to do this”.
Secrets are usually strings of characters and numbers that follow a specific pattern:
Securing secrets has rightly been a focal point of cloud and app security for years and for good reason – they are the most critical element of an NHI – the gatekeepers of access. If a consumer is compromised, it’s dangerous, but when a secret is compromised, it’s catastrophic. That’s because a secret doesn’t just identify the NHI — it authenticates it. A stolen secret lets an attacker operate as the original app or service, often without raising any red flags(the access appears legitimate). Most breaches involving NHIs start with exposed or leaked plaintext secrets.
It is important to note that not all secrets are created equal. They vary in lifespan:
- Long-lived: AWS access keys, static OpenAI, or Slack API tokens
- Ephemeral/short-lived: OAuth tokens, AWS session tokens that auto-expire in minutes or hours
The gist is the same for both types; just like our metaphorical tourist uses their passport to prove their identity at border control, consumers assume secrets to prove their identity to cloud services and other machines. A CI/CD pipeline might consume an AWS key to deploy an EC2 instance, while a microservice might use an OpenAI API key to generate text.
But having a valid passport isn’t enough, the tourist also needs the right stamps (or visas) on it to enter specific countries or restricted areas. In the same way, a secret alone doesn’t define what a consumer can do – that’s determined by Entitlements.
Element 3: Entitlements or What NHIs Can Do?
Entitlements are the permissions, roles, and privileges granted to an NHI – essentially, the answer to “What can this consumer do?” In AWS, entitlements are defined by IAM policies attached to a role or user (for example, an IAM policy might allow s3:ListBucket and s3:GetObject on certain resources). In Azure, entitlements take the form of role assignments (like giving a service principal the “reader” role on a subscription or worse “owner” rights).
Entitlements ultimately determine the scope and power of an NHI.
A secret might be the “key to the kingdom” but entitlements define how far into the kingdom that key lets you go.
The Principle of Least Privilege tells us that each identity – human or non-human – should have only the minimum access necessary to perform its function, no more. In practice though, most organizations are far from this ideal. Granting broad permissions is easier (“this app might need S3 access, let’s just give it S3 Admin”) and often we see privileges accumulate over time as services evolve.
The complexity is staggering – AWS alone has over 18,000 distinct IAM permissions across its services, and when you add Azure and GCP into the multi-cloud mix, the number of possible permissions rises into the tens of thousands. Microsoft’s analysis of real-world cloud environments found that only 2% of permissions granted to identities are ever actually used. That means 98% of permissions are left unused – creating excess, exploitable access if a secret is compromised.
The result is pandemic proportions of over-permissioned NHIs in the cloud and SDLC processes. An Entro Labs security report found that over-privileged NHIs are one of the most common cloud misconfigurations in 2025.
How the Three NHI Elements Work Together
AWS: Data Processing App Using an Access Key
| Consumer | Secret | Entitlements |
| A data processing application designed to analyze and transform customer data stored in S3. | The application uses a static AWS access key stored in the app’s environment variables or config files. | The access key is tied to an IAM user with permissions like s3:GetObject and s3:PutObject for specific S3 buckets. |
The NHI workflow:
- An end user uploads a data file that gets stored on an S3 bucket (target resource).
- The app (consumer) retrieves the AWS access key (secret) from its configuration.
- The app authenticates using the key and accesses the S3 bucket.
- Based on the entitlements assigned to the IAM user, the app reads the data and writes the output back to the S3 bucket.
GitHub: CI/CD Deployment with a Personal Access Token
| Consumer | Secret | Entitlements |
| A GitHub Actions workflow configured to deploy a web application to a cloud platform. | The workflow uses a Personal Access Token (PAT) stored in GitHub Secrets. | The PAT is configured with repository-scoped permissions, allowing the workflow to access the repository’s code and deploy it to the target environment. |
The NHI workflow:
- A developer pushes code changes (commit) to the GitHub repository.
- The GitHub Actions workflow is triggered to build and deploy the web app.
- The workflow, acting as the consumer, retrieves the PAT (secret) to authenticate itself.
- Based on the PAT’s entitlements, the workflow pulls the repository’s code (resource 1), builds the app, and deploys it to the cloud platform (resource 2).
OpenAI: Interactive Chatbot Leveraging an API Key
| Consumer | Secret | Entitlements |
| A chatbot agent designed to generate responses using OpenAI’s large language model. | The agent uses an API key provided by OpenAI – the key is hardcoded in its source code. | The API key grants access to specific endpoints of OpenAI’s API, with usage limits and access scopes defined by OpenAI’s service policies. |
The NHI workflow:
- A user interacts with the chatbot sending a message that requires a generated response.
- The chatbot (consumer) retrieves the OpenAI API key (secret) from its source code (not a best practice but common).
- Using the API key, the chatbot sends a prompt to OpenAI’s API to generate a response.
- OpenAI processes the request and returns the generated response, which the chatbot then presents to the user.
A Holistic Approach to Secure NHI Elements
Stepping back, we’ve seen that Consumers + Secrets + Entitlements form an interlocking triangle for NHIs and machine identities. Focusing on securing just one corner, like locking down secrets, won’t fully solve the problem if the other corners are weak. To reduce NHI risk, organizations need to protect all three elements in tandem:
- Consumers: Know which services exist and what they should be doing
- Secrets: Discover and monitor what credentials are being used and where
- Entitlements: Continuously govern what access each identity actually needs
This holistic approach of securing the NHI Lifecycle can sound daunting, given the scale of cloud deployments, but it’s exactly where the industry is heading.
New tools and platforms are now tackling the NHI challenge by bridging the gaps between non-human identity, secret management, and access governance. Entro has pioneered and is now leading these efforts.
Entro’s platform is designed to give security and IAM teams unified visibility and control over all their NHIs. It automatically scans and discovers non-human identities and the secrets they use across your infrastructure, creating a comprehensive inventory of every service account, API key, and token in the environment – exposed and vaulted.
Entro correlates NHI elements and enriches them with context to answer key questions:
- Which workload is using this secret?
- What permissions does it have?
- Are those permissions actually being used?
Powered by NHIDR™ (Non-Human Identity Detection and Response), Entro monitors for suspicious NHI behavior in real-time and automatically alerts on misconfigurations, helping to stop NHI exploits before they become a breach.
Interested in learning more about securing your non-human identities? Schedule your free assessment now.
