Old Friend Showed Up With a Key: Non-Human Identity Governance
IAM Role doesn’t have a password. A Lambda function doesn’t need MFA, aservice account never quits, never goes on vacation, never says “I forgot my password” and that’s exactly why nobody questions it.
According to Tenable’s 2026 Cloud and AI Security Risk Report, 52% of non-human identities carry critically excessive permissions a rate that outpaces human identities (37%). Somewhere in your environment, there are ghosts quietly stacking up privileges nobody’s watching.
This article is about making them visible.
Principle 1: They’re Not Human, But Their Permissions Are Real
“Not human” doesn’t mean “harmless.”
Non-human identity (NHI) is a surprisingly wide family: IAM Roles, service accounts, Lambda functions, CI/CD pipelines, AI agents, API integrations. What they all share is this none of them has a person sitting behind it approving every action. They act on their own.
That’s where the problem starts. When a human user does something wrong, someone notices. It comes up in a meeting, it raises an eyebrow in a Slack thread. But a service account opened three years ago, whose founding developer left long ago, that nobody remembers the purpose of anymore it might still be running with full permissions.
Nobody notices, because nobody’s looking.
Principle 2: Ghost Roles Permissions That Never Die, But Never Live Either
The most dangerous access is the access nobody remembers granting.
A project ends. An integration gets abandoned. A “temporary” test role never gets deleted. Over time, your environment accumulates roles that serve no purpose anymore but still sit there with full permissions these are called ghost roles. This isn’t theoretical: roughly a third (37%) of over-privileged non-human identities aren’t actively used at all meaning a meaningful chunk of the biggest risk pool out there is identities nobody’s touched in ages.
Why are these so dangerous?
- Nobody’s monitoring them, because nobody “owns” them.
- CloudTrail logs rarely surface them, since they’re not being used until someone hijacks them.
- They’re ideal targets for attackers: an over-permissioned, under-watched combination.
This is exactly what IAM Access Analyzer’s unused access findings are built for. It continuously reviews last-accessed information across your IAM roles and users, and surfaces unused roles, unused access keys and passwords, and permissions that haven’t been exercised within a set tracking window. If a role hasn’t made a single API call in six months, that’s your signal a candidate for deletion, or at minimum a serious trim.
Ask yourself: does every role in your environment have an owner, or does it look like some of them are ghosts haunting an empty house?
Principle 3: AI Agents Same Old Problem, New Generation
Tell an agent “just this once,” and it hears “forever.”
The development driving 2026’s NHI conversation is AI agents. You give an agent access to get a task done but that access usually isn’t scoped to the task. It’s scoped to “get it done, whatever it takes.”
The numbers back this up starkly. The Cloud Security Alliance’s March 2026 report, “The Identity and Access Gaps in the Age of Autonomous AI” (commissioned by Aembit), found that 68% of organizations can’t reliably tell whether an action came from an AI agent or a human. Tenable’s telemetry shows why that’s dangerous: 18% of organizations have AI services holding administrative permissions that are rarely, if ever, audited. Different research firms, same story nobody’s watching, and everybody’s exposed.
This is standing privilege permission that stays open indefinitely, never temporary. Even after an agent finishes its job, that permission is still sitting there, still active, still waiting to be misused.
AWS’s own security team is leaning into this problem too. In a June 2026 post, AWS walked through using resource-based policies on Amazon Bedrock AgentCore to grant one tenant cross-account access while restricting another to VPC-only traffic in a shared, multi-tenant AI platform — in other words, scoped, tenant-specific access for agents is now an officially recommended pattern, not just a best practice you invent yourself.
The fix is the same logic that applies to human identities just applied to a machine this time:
- Give the agent a scoped, resource-based policy access to exactly what it needs, nothing more.
- Replace standing privilege with temporary, time-boxed access when the task ends, the permission ends.
- Audit every agent like you’d audit a person who did what, when, logged and traceable.
Telling an AI agent “you can do this” is easy. The hard part is remembering to say “not anymore.”
Principle 4: You Can’t Govern What You Haven’t Inventoried
You can’t protect what you can’t count.
Most organizations’ biggest question is: “How many NHIs do we actually have?” And the honest answer is usually: we don’t know.
The first step of NHI governance isn’t exciting — it’s inventory. But it’s non-negotiable:
- Every role, every service account needs to be listed.
- Every one needs an owner a person or team who can answer “what is this for.”
- Every one needs a documented purpose — why it exists, what it’s used for.
An identity with no owner is a weapon with no one responsible for it. Nobody looks at it until something goes wrong.
Principle 5: Lifecycle Management Birth, Review, Retirement
NHIs deserve a retirement plan too.
Human users have a natural lifecycle: you’re onboarded, your role changes, you leave. NHIs usually never get this they’re created once and live forever.
A healthy NHI lifecycle should look like this:
- Creation: When an NHI is provisioned, its purpose, owner, and minimum required permissions should be clearly defined.
- Periodic review: At regular intervals (quarterly, say), check whether each NHI is still actually being used.
- Automatic expiration: Unused identities should be disabled automatically don’t rely on human memory.
Without these three, your environment fills up with ghost roles over time. And every ghost role is an open door that makes an attacker’s job easier.
Finally: Make the Invisible Visible
NHI governance isn’t a complex technology. What’s complex is breaking the habit of ignoring it.
- Non-human identity doesn’t carry less risk than a human one it just gets noticed less.
- An unused permission is a door waiting to be closed.
- When you grant an AI agent access, don’t trust it like a human audit it like one.
- No identity without an owner should be allowed to live in your environment.
Remember: the invisible isn’t dangerous because it’s weak it’s dangerous because nobody’s looking at it.
References:
- Tenable, 2026 Cloud and AI Security Risk Report — https://www.tenable.com/blog/cloud-ai-research-report-2026-governance-vs-innovation
- AWS Security Blog, Secure multi-tenant AI agents with Amazon Bedrock AgentCore resource-based policies — https://aws.amazon.com/blogs/security/secure-multi-tenant-ai-agents-with-amazon-bedrock-agentcore-resource-based-policies/
- AWS Documentation, IAM Access Analyzer unused access findings — https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html
- AWS Security Blog, ICYMI: June 2026 @AWS Security — https://aws.amazon.com/blogs/security/icymi-june-2026-aws-security/
- Cloud Security Alliance, The Identity and Access Gaps in the Age of Autonomous AI (Mart 2026) — https://cloudsecurityalliance.org/press-releases/2026/03/24/more-than-two-thirds-of-organizations-cannot-clearly-distinguish-ai-agent-from-human-actions