Non-Human Identity Security in AWS (2026)

What it is: a non-human identity (NHI) is any login or credential used by a machine rather than a person - a service account, an IAM role assumed by an application, an access key baked into a script, or, increasingly in 2026, an AI agent that logs into AWS to do a task on its own. Why it matters: in most AWS accounts today, non-human identities vastly outnumber human users, and attackers know it - a stolen machine credential often has broad, quiet access and nobody watching a dashboard to notice it behaving strangely, the way they might notice a human's odd login. When it applies: any AWS account that runs automation, scheduled jobs, CI/CD pipelines, backend services, or AI agents - which today is essentially every production AWS account. This post walks through non-human identity security on AWS in plain, practical steps.

Why non-human identities are the bigger risk

A human user typically logs in through a browser, from a small number of known locations, doing a limited range of actions - which makes unusual behaviour easier to spot. A non-human identity might call the AWS API thousands of times a day, from a server, at all hours, doing a wide range of legitimate actions. That normal-looking noise is exactly what makes a compromised machine credential hard to catch: the attacker's misuse blends into traffic your team already expects to see. Add AI agents into the mix - software that can now decide on its own which AWS action to take next - and you have identities whose behaviour is even harder to predict in advance, which is exactly why they need tighter guardrails, not looser ones.

Stop using long-lived access keys

A long-lived AWS access key is a username-and-password-style credential that does not expire on its own. If it leaks - committed to a public code repository, left in a config file, or stolen from a compromised laptop - it keeps working until someone manually finds and revokes it, which can take days or months. Wherever possible, replace long-lived keys with IAM roles, which hand out short-lived, automatically-expiring credentials instead. For workloads outside AWS that still need to authenticate - an on-premises server, a third-party SaaS tool, or an AI agent running outside your AWS account - IAM Roles Anywhere lets you issue the same kind of short-lived credential using a certificate, instead of a static key that can be copied and reused indefinitely.

Rotate what you cannot eliminate

Some secrets cannot be replaced with a role - a third-party API key, a database password, a shared credential a vendor requires. For these, use AWS Secrets Manager to store the secret centrally and rotate it automatically on a schedule, rather than leaving the same static value in place for years. Automatic rotation limits how long a leaked secret stays useful to an attacker, even if you never find out it leaked in the first place.

Give every identity the least privilege it needs

Least privilege means every non-human identity gets only the exact permissions its job requires, not a broad role reused across many services because it was convenient to set up once. A backup job that only needs to read from one S3 bucket should not also be able to delete EC2 instances or read secrets it never touches. Review IAM policies attached to service roles the same way you would review a human employee's access - by asking what this specific identity actually needs to do its specific job, not what would be convenient to grant.

Find and remove identities nobody is using

Every AWS account accumulates orphaned non-human identities over time: a service account for a project that was decommissioned, an access key generated for a one-time migration that was never deleted, a role created for a proof-of-concept that quietly became permanent. Each of these is standing risk with no business purpose. Use AWS IAM Access Analyzer and the IAM credential report to find identities and access keys that have not been used in a defined window (90 days is a common baseline), and build a routine - monthly or quarterly - to review and remove them.

Log and monitor every non-human identity

Every action a non-human identity takes should be logged through AWS CloudTrail, and that log should feed into monitoring that can flag unusual behaviour - a service role suddenly calling APIs it has never used before, an access key being used from an unfamiliar location, or a spike in activity outside normal hours. Because non-human identities generate high volumes of routine traffic, effective monitoring depends on establishing what "normal" looks like for each identity first, so genuine anomalies stand out instead of getting lost in the noise.

Bringing it together

• Replace long-lived access keys with IAM roles, or IAM Roles Anywhere for workloads outside AWS.
• Rotate any secret you cannot eliminate, using AWS Secrets Manager on an automatic schedule.
• Scope every service role and AI agent identity to least privilege - only what the specific job needs.
• Regularly find and remove unused identities and stale access keys.
• Log every non-human action through CloudTrail and monitor for behaviour that breaks the identity's normal pattern.

Non-human identity security is not a separate discipline from identity and access management - it is the part of IAM that has quietly grown to outnumber everything else in a modern AWS account. Treating it with the same rigor you apply to human access, rather than as a background convenience, closes one of the most commonly exploited gaps in cloud environments today.