The Identity Problem Nobody’s Talking About
Ask any cloud security team what keeps them up at night and they’ll mention ransomware, misconfigurations, or phishing. Very few will mention the service principal that was created eighteen months ago, has administrator-level access to your production AWS account, and hasn’t been rotated since.
They should.
In 2026, the most significant shift in cloud security isn’t a new attack technique, it’s the sheer scale of non-human identities now operating inside enterprise environments. Service accounts, API keys, OAuth tokens, CI/CD pipeline credentials, container service roles, and increasingly, autonomous AI agents — these machine identities outnumber human users in most organisations by a staggering margin. Industry research puts the ratio at roughly 100 to 1.
And while organisations have spent years investing in multi-factor authentication, single sign-on, and Conditional Access for their human workforce, the equivalent governance for machine identities is, in many cases, non-existent.
What Exactly Are Non-Human Identities?
Non-human identities (NHIs) encompass any credential, token, or principal that allows a machine, service, or automated process to authenticate and act within your cloud environment. In practice, this includes:
Service accounts and service principals — dedicated identities used by applications to interact with cloud APIs. On AWS, these are IAM roles and users assigned to services. On Azure, they’re app registrations and managed identities.
API keys and access tokens — static or time-limited credentials that grant programmatic access. These are often embedded in configuration files, environment variables, or worse, hard-coded into application source code.
CI/CD pipeline identities — the credentials your build and deployment tools (Jenkins, GitHub Actions, GitLab CI, Azure DevOps) use to provision infrastructure, deploy code, and manage secrets. These typically require broad permissions to function.
OAuth integrations and SaaS connectors — tokens granted when your organisation connects third-party tools to cloud services. Each integration creates a trust relationship that persists until explicitly revoked.
Agentic AI identities — a newer and rapidly growing category. As organisations deploy AI agents that autonomously query databases, call APIs, and execute workflows, each agent operates with its own identity and permissions. These are often granted wide access to be “useful,” creating a significant and largely ungoverned attack surface.
Why This Matters Now
The risk from non-human identities isn’t theoretical. It’s structural and it’s getting worse for three reasons.
1. The Explosion of Machine-to-Machine Interaction
Modern cloud architectures are built on microservices, serverless functions, and event-driven workflows. Each of these components needs to authenticate with others. A single application might involve dozens of service-to-service identity relationships. Multiply that across an organisation’s full estate and you’re looking at potentially hundreds, maybe thousands of non-human identities, most of which were created quickly during development to “get a job done” and never reviewed.
2. Permissions Drift and Accumulation
Human users change roles, leave the organisation, and trigger access reviews. Machine identities do none of these things. A service account created for a proof-of-concept two years ago may still have the same broad permissions it was granted on day one, long after the project ended. This “permissions drift” creates a persistent pool of over-privileged identities waiting to be discovered by an auditor, or by an attacker both creating very different sets of headaches.
3. Agentic AI Changes the Game
The rise of AI agents in enterprise environments introduces identities that don’t just read data they make decisions, execute actions, and interact with other systems autonomously. If an AI agent has permission to query your customer database, call an external API, and write to a storage bucket, it represents a far more capable identity than a traditional service account. Governing these agents requires not just access controls, but an understanding of what the agent does and whether its behaviour is within expected bounds.
The Gaps We See in Client Environments
At Mobilise, we work across AWS and Azure environments in both the public and private sector. When we conduct security reviews and cloud health checks, the findings related to non-human identities are remarkably consistent.
No inventory. Most organisations cannot produce a definitive list of all non-human identities in their environment. Service accounts are scattered across accounts and subscriptions, created by different teams at different times, with no central register.
Over-provisioned by default. The path of least resistance during development is to grant broad permissions often full admin or PowerUser access to get things working. In production, these permissions are rarely scoped down. We regularly find service accounts with AdministratorAccess policies attached with the dreaded */* that only need read access to a single S3 bucket.
No rotation or expiry. Static credentials like API keys, access keys and secrets frequently have no rotation policy. AWS Access Keys older than 90 days are a common finding in our reviews. On Azure, app registration secrets set to expire in two years are often forgotten entirely.
Orphaned identities. When projects end, teams restructure, or applications are decommissioned, the associated service accounts and credentials are often left in place. These orphaned identities are invisible to most teams but remain fully functional and fully exploitable.
No monitoring of behaviour. Even where organisations have invested in CloudTrail or Azure Activity Logs, they rarely have alerting configured for anomalous non-human identity behaviour. A service account that suddenly begins accessing resources it has never touched before should raise an alarm. In most environments, it doesn’t.
A Practical Framework for Getting Control
Getting non-human identities under control doesn’t require a massive tooling overhaul. It requires discipline, visibility, and a systematic approach. Here’s how we recommend organisations can tackle it.
Step 1: Build a Complete Inventory
You can’t govern what you can’t see. Start by producing a comprehensive inventory of all non-human identities across your cloud estate. On AWS, use IAM Credential Reports, Access Analyzer, and the Organizations API to enumerate identities across all accounts. On Azure, use the Microsoft Graph API to list all app registrations, service principals, and managed identities across subscriptions.
Tag each identity with its owner, purpose, associated application, and the date it was last reviewed. If you can’t determine the purpose of an identity or its owner, that itself is a finding.
Step 2: Apply Least Privilege — Ruthlessly
Review every non-human identity’s effective permissions against its actual usage. AWS IAM Access Analyzer can show which permissions have been used in the last 90 days; anything unused should be removed. On Azure, Permissions Management (formerly CloudKnox) provides equivalent visibility.
The target state is that every machine identity has the minimum permissions required to perform its function and nothing more. This is labour-intensive initially but pays dividends in reducing blast radius.
Step 3: Enforce Credential Rotation and Expiry
All static credentials should have automated rotation policies. On AWS, use Secrets Manager with automatic rotation enabled. On Azure, use Key Vault with expiry policies and alerts. Any credential older than 90 days without rotation should be flagged and remediated.
Better yet, eliminate static credentials where possible. AWS IAM roles with temporary credentials (via STS) and Azure Managed Identities remove the need for long-lived secrets entirely.
Step 4: Implement Lifecycle Governance
Non-human identities should follow the same lifecycle governance as human identities: they’re created with a defined purpose and owner, reviewed on a regular cadence, and decommissioned when no longer needed. Integrate NHI reviews into your existing change management and access certification processes.
Step 5: Monitor for Anomalous Behaviour
Configure alerts for non-human identity activity that deviates from established baselines. A service account that typically reads from one S3 bucket but suddenly begins listing all buckets and downloading data from another should trigger an immediate investigation. AWS GuardDuty, Azure Sentinel, and third-party CSPM tools can all support this level of behavioural monitoring.
Looking Ahead: Governance for the Age of AI Agents
As organisations begin deploying agentic AI systems that autonomously perform tasks, make API calls, and interact with data the non-human identity challenge will intensify further. These agents don’t just need access controls; they need behavioural guardrails, audit trails, and the ability to be immediately revoked if they begin operating outside expected parameters.
At Mobilise, we’re already working with clients to build governance frameworks that account for AI agent identities alongside traditional service accounts. The principles are the same: least privilege, continuous monitoring, lifecycle management but the implementation requires new thinking about what “expected behaviour” looks like for an autonomous system.
The Bottom Line
Non-human identities are the largest and least governed part of your cloud security surface. They outnumber your users, they often hold more privilege than your administrators, and they’re the first thing an attacker looks for after gaining initial access.
Getting this right isn’t glamorous work. It’s inventory, policy, automation, and discipline. But it’s the work that separates organisations with a genuine security posture from those with a security dashboard and a false sense of confidence.
If you’re looking to understand the state of non-human identities across your AWS or Azure estate, Mobilise can help. Our cloud health checks include a full assessment of identity hygiene, human and machine with actionable recommendations to reduce risk.
