Your AWS environment has more non-human identities than human ones. Probably ten times more. Every Lambda function, every ECS task, every CI/CD pipeline, every monitoring agent, every third-party integration operates under its own IAM identity.
Most security programs treat these identities as an afterthought. Human accounts get SSO, MFA, access reviews, and session monitoring. Service accounts get a role created once and forgotten.
This is the blind spot that attackers exploit. Compromised service credentials are involved in the majority of cloud breaches, yet most organizations have no behavioral monitoring for these identities.
The scale of the non-human identity problem
A mid-sized AWS environment with 200 human users might have 2,000 or more non-human identities. Large organizations with multi-account strategies can have tens of thousands. Each of these identities represents a potential attack vector.
The numbers keep growing. Microservice architectures create more service-to-service identities. Infrastructure-as-code tools create deployment roles for every pipeline. Monitoring and observability platforms create read-access roles across every account.
- Lambda execution roles: one per function, often hundreds per account. Many share overly broad managed policies.
- ECS task roles: one per service definition. Frequently granted access to secrets, databases, and other services.
- CI/CD service roles: GitHub Actions, GitLab CI, Jenkins. These often have write access to production infrastructure.
- Monitoring agent roles: Datadog, New Relic, CloudWatch cross-account roles. Read access to everything.
- Third-party integration roles: SaaS platforms that assume cross-account roles for data access.
Types of non-human identities in AWS
Not all non-human identities carry the same risk. Understanding the categories helps prioritize monitoring and response.
Service roles are the most common type. These are IAM roles assumed by AWS services (Lambda, ECS, EC2) to perform their functions. They typically have trust policies that allow only the specific service to assume them.
Automation accounts are IAM users or roles used by scripts, cron jobs, and orchestration tools. These often have long-lived credentials (access keys) that present a higher theft risk than temporary role credentials.
- Service roles with service trust policies are lower risk because the trust boundary is managed by AWS.
- Cross-account roles with external trust are higher risk because the trust depends on the security of another account.
- IAM users with access keys are the highest-risk non-human identity type. Keys do not expire automatically and are frequently leaked.
- Federated identities from CI/CD platforms (GitHub OIDC, GitLab OIDC) are a newer pattern that reduces credential exposure but requires careful audience and subject claim configuration.
Common attack vectors targeting non-human identities
Attackers prefer targeting non-human identities because they are less monitored, less likely to trigger alerts, and often have broad persistent access. Here are the patterns security teams should watch for.
Stolen service account credentials. Access keys for IAM users are the most commonly stolen credential type in AWS breaches. They end up in Git repositories, Docker images, client-side code, and CI/CD logs. Once stolen, they provide persistent access until rotated.
Overprivileged Lambda roles. Developers frequently attach AdministratorAccess or broad wildcard policies to Lambda execution roles during development and never scope them down. A vulnerability in the function code (SSRF, injection) gives an attacker the full permissions of that role.
Compromised CI/CD pipelines. CI/CD systems are high-value targets because they typically have write access to production infrastructure. A compromised GitHub Actions workflow can assume your deployment role and modify any resource that role can access.
- Supply chain attacks inject malicious code into dependencies that execute during the CI/CD build process, using the pipeline's IAM role.
- Misconfigured OIDC trust policies can allow any repository in an organization (or any branch) to assume the deployment role.
- Self-hosted CI/CD runners on EC2 instances can be compromised through the instance metadata service to steal the attached role credentials.
- Environment variable exfiltration in CI/CD logs can expose temporary credentials if logging is not properly configured.
Why existing IAM tools miss the threat
IAM Access Analyzer, AWS Config rules, and third-party CSPM tools focus on one question: "Is this identity configured correctly?" They check whether permissions follow least-privilege, whether policies contain wildcards, whether roles have unused permissions.
This is posture management. It is necessary but insufficient. A service account can have perfectly scoped permissions and still be compromised. The permissions do not change when the credential is stolen. What changes is the behavior.
A compromised service account will exhibit behavioral anomalies: API calls at unusual times, access to resources outside its normal pattern, calls from unexpected source IPs, unusual error rates as the attacker probes the permissions boundary.
- Posture tools catch misconfiguration before it is exploited. They do not detect exploitation in progress.
- SIEM tools can query CloudTrail logs, but they require analysts to write and maintain rules for every possible anomaly pattern.
- Neither approach builds per-identity behavioral baselines that automatically detect deviations.
- The result: most organizations discover compromised service accounts through billing alerts (crypto mining) or data breach notifications, not through security monitoring.
The case for behavioral monitoring of NHIs
Behavioral monitoring flips the approach. Instead of checking configurations, it observes what each identity actually does and builds a model of normal behavior. When behavior deviates from that model, it generates an alert with the context needed for investigation.
For non-human identities, behavioral monitoring is especially powerful because NHI behavior is more predictable than human behavior. A Lambda function that processes orders calls the same APIs, accesses the same DynamoDB tables, and runs at predictable intervals. Any deviation from that pattern is a strong signal.
- Baseline what APIs each NHI calls, which resources it accesses, and when it is active.
- Alert on first-time API calls, new resource access, unusual timing, and source IP changes.
- Correlate anomalies across related identities. If a CI/CD role and multiple Lambda roles exhibit anomalies simultaneously, that is a stronger signal than a single deviation.
- Automate response for high-confidence detections: revoke sessions, rotate credentials, restrict network access.
Where to start
Begin with an inventory. Most organizations do not have a complete list of their non-human identities, let alone metadata about what each one does or who owns it. Export your IAM roles and users, filter for non-human identities, and classify them by type and risk level.
Next, identify your highest-risk NHIs. These are identities with broad permissions, access to sensitive resources, or credentials that could be stolen (access keys vs. role sessions). Focus monitoring efforts here first.
Finally, establish behavioral baselines for these high-risk identities using CloudTrail data. Even a simple baseline ("this role normally calls these 15 APIs in us-east-1 during business hours") provides significant detection value when deviations occur.