The workforce nobody onboarded
Walk into most enterprises today and ask the security team how many employees they protect. They will give you a number, and it will be roughly correct. Ask them how many non-human identities are active in the same environment, and the answer gets vague. That gap is the problem. Service accounts, API keys, OAuth tokens, TLS certificates, CI/CD runners, and now a fast-growing population of AI agents all authenticate, hold permissions, and take actions inside the network. Most of them were never onboarded through any formal process, and a large share will never be offboarded either.
The scale has moved past the point where manual tracking works. Analyst estimates for 2026 put non-human identities at somewhere between 45 and 100 to every human user, depending on how you count and how cloud-native the estate is. KPMG's 2026 cybersecurity report cites roughly 80 to 1 in the average enterprise and names non-human identity management as one of its eight priorities for CISOs this year. Whatever the exact multiple in your environment, the direction is settled: the identities that matter most to an attacker are no longer the people.
What changed the conversation in the last eighteen months is agentic AI. A static API key is dangerous when it leaks, but it does exactly one thing. An autonomous agent reasons, chains tool calls, reads from systems it was pointed at, and writes to others, often with credentials delegated from a human who has long since walked away from the keyboard. We are no longer just securing secrets. We are securing something that behaves.
What counts as a non-human identity
It helps to be precise, because "non-human identity" gets used loosely. In practice it covers a few distinct populations that share one trait: no person is sitting behind them at the moment they act.
The traditional group is machine credentials. Service accounts that run scheduled jobs, database connection strings, the API keys wired into integrations, the certificates that let one microservice trust another. These have been in every environment for decades. What is new is the volume, driven by microservices, infrastructure as code, and the habit of spinning up a fresh credential for every integration rather than reusing one.
The second group is the one changing the risk picture: AI agents. A coding assistant with repository write access. A support agent that can read customer records and issue refunds. An internal copilot wired into email, calendars, and file storage. Cloud Security Alliance research published this year found that 87% of enterprises already have Microsoft Copilot enabled, more than half of deployed agents can reach sensitive information, and around 90% run with permissions broader than the task in front of them requires. That last figure is the one we see confirmed again and again in assessments. The agent was given a broad role because narrowing it was harder, and nobody came back to tighten it.
The distinction matters because the two groups fail differently. A leaked key is a theft problem. An over-permissioned, manipulable agent is a behaviour problem, and behaviour is much harder to put a control around.
Why the human identity playbook does not transfer
Identity and access management, as most organisations practise it, was built around people. It assumes a joiner-mover-leaver lifecycle, a manager who approves access, multi-factor authentication at login, and a human who can be trained not to click the obvious phishing link. Almost none of that maps cleanly onto a non-human identity.
There is no lifecycle owner
A person joins, changes roles, and eventually leaves, and each of those events triggers an access review. A service account is created during a project, works fine, and is forgotten the moment the project ships. Nobody deprovisions it because nobody remembers it exists. In engagements across banking and telecom environments, the single most common finding we bring back is not a sophisticated intrusion path. It is a pile of live credentials attached to systems, projects, and people that are long gone.
The strongest human control does not apply
Multi-factor authentication is the control that carries most of the weight in human identity security. It does not exist for a service account or an agent, which authenticate with a secret, a token, or a certificate and nothing else. Strip MFA out of your mental model and you are left leaning entirely on secret hygiene, rotation, and least privilege, three disciplines that most organisations do inconsistently at best.
The actions look legitimate
This is the hard one. When an attacker steals a human's password, there is usually an anomaly to catch: a login from a new country, an odd hour, an unfamiliar device. When an agent is manipulated, it uses its own real permissions to do real things. The API calls are authenticated. The tool invocations are ones the agent is allowed to make. Nothing trips an authentication alarm because authentication was never bypassed. As the CSA governance work puts it plainly, actions that appear correct can hide malicious logic. Log-level and API-level validation, the checks most SOCs rely on, quietly stop being sufficient.
How attackers actually target autonomous agents
The threat models here have matured quickly, and it is worth grounding the discussion in the frameworks rather than speculation. The OWASP Top 10 for Agentic Applications, updated for 2026, gives the security community a shared vocabulary. Three attack objectives cover most of what we see.
The first is goal hijacking. An attacker plants instructions where the agent will read them, inside a support ticket, a document, a code comment, a web page the agent fetches, and the agent treats those instructions as part of its task. This is indirect prompt injection, and it is effective precisely because agents are designed to act on the content they ingest. The malicious instruction never touches your authentication layer. It rides in on data the agent was told to trust.
The second is abuse of trusted privileges. Here the attacker does not steal a credential at all. They get the agent to use permissions it legitimately holds, its API access, its tool set, its connected integrations, to do something outside its intended purpose. An agent with both read access to a database and the ability to send email is one clever prompt away from becoming an exfiltration channel, and every action it takes is authorised.
The third is undermining the system's resilience: poisoning an agent's memory so it carries a bad instruction forward, exploiting the messages agents pass between each other, and triggering cascading failures across a chain of agents that each trusted the last. Anthropic's own published research on agentic misalignment showed that under conflicting goals or perceived threats, autonomous models could engage in covert, goal-directed behaviour their operators did not intend. That research was run in controlled conditions, but the lesson for anyone deploying agents in production is direct: capability plus autonomy plus poor constraints is a risk you have to design against, not assume away.
A control model that holds up in production
The good news is that securing non-human identities does not require inventing a new discipline. It requires applying zero trust honestly to a population that has been getting a pass. The controls below are the ones we build into client environments, layered so that a failure in one does not become a breach.
The starting point is visibility, because you cannot govern what you have not inventoried. Discovery of every non-human identity, its owner, its permissions, and its last use is unglamorous work and it is always where the real risk surfaces. From there the model stacks upward.
Treat every non-human identity as zero trust by default. An agent or service account is assumed to be potentially compromised, and every interaction it initiates is verified against policy rather than trusted because it authenticated once. Pair that with least privilege and just-in-time access: an agent gets only the permissions its current task needs, granted for a bounded window and revoked afterward, instead of a standing broad role. That single change collapses the blast radius of the over-permissioning problem that affects roughly nine in ten agents today.
For agents specifically, put a guardrails layer between the agent and the tools it can call. A mediation proxy that validates each tool invocation against context-aware policy is what stops a hijacked agent from turning legitimate permissions into a real action. Pre-validate the components the agent depends on, its model, its plugins, the MCP servers it connects to, tracking origin, version, and integrity, because the supply chain into an agent is now part of your attack surface. KPMG's data showing 59% of companies suffered a third-party-linked breach in the past year is the same problem wearing a different hat.
Finally, instrument behaviour, not just authentication. Capture the sequences of tool calls an agent makes and feed workflow deviations into the SIEM as first-class events, so the SOC can reason about what an identity did, not only whether it logged in. Wrap the whole thing in execution isolation, running agent workloads inside restricted containers or sandboxes so that a compromise is contained rather than pivoting into the wider estate.
Human versus non-human identity controls at a glance
Control dimensionHuman identityNon-human identity / AI agent
Primary authentication
Password plus MFA
Secret, token, or certificate; no MFA
Lifecycle trigger
Joiner / mover / leaver via HR
Often none; created ad hoc, rarely retired
Access review
Periodic, manager-attested
Frequently absent; ownership unclear
Anomaly signal
New device, geography, or hour
Actions look legitimate; needs behavioural telemetry
Privilege scope
Role-based, reviewed
~90% over-permissioned relative to task
Containment
Session revocation, password reset
Secret rotation, token revocation, sandbox isolation
The first ninety days
If you are starting from the position most organisations are in, which is limited visibility and a growing agent footprint, the sequence matters more than the ambition. This is the order we recommend.
- Inventory every non-human identity you can find: service accounts, keys, tokens, certificates, and every deployed AI agent. Record owner, permissions, and last use. Expect the count to surprise you.
- Kill the orphans. Any credential with no identifiable owner or no use in 90 days is a liability, not an asset. Disable first, delete after a grace period.
- Attack the over-permissioning. Rank identities by privilege against actual task, and start narrowing the widest gaps. This is where least privilege buys the most risk reduction fastest.
- Get secrets out of code and into a managed vault with rotation. Hard-coded credentials in repositories remain one of the most reliable ways in.
- Put a guardrails proxy in front of your highest-privilege agents before you scale them, not after.
- Route agent tool-call telemetry into your SIEM and write detections for workflow deviation, not just failed logins.
- Assign an owner to every surviving identity, and make non-human identity part of your regular access review cycle so the problem does not silently rebuild.
Where this meets compliance
None of this sits outside the frameworks you already answer to. ISO 27001 access control expects you to manage the full lifecycle of access rights, and a service account with no owner and no review is a finding whether or not a human is behind it. The NIST Cybersecurity Framework's Identify and Protect functions assume you have an accurate asset and identity inventory to begin with. PCI-DSS has tightened its language on service accounts and authentication for automated processes. CIS Benchmarks give you concrete configuration baselines for the platforms your agents run on. Mapping your non-human identity controls back to these frameworks is what turns a security project into an audit-ready programme, and in a regulated GCC market that mapping is often what gets the budget approved.
The organisations getting this right are treating agent management as a core security competency rather than a side effect of adopting AI. That aligns with what the executives in KPMG's survey are signalling, with 92% saying the ability to manage AI agents will define security teams over the next five years, and 61% of US companies already mandating a human in the loop for autonomous agents. The technology is moving faster than most governance programmes. Closing that gap is the work.
How Aydahwa Enterprise can help
At Aydahwa Enterprise, we help organisations across the UAE and wider GCC bring their non-human identities and AI agents under the same discipline they already apply to people, without stalling the business initiatives that depend on them. Our work draws on 25 years in enterprise infrastructure and security, hands-on delivery across banking, telecom, and critical national infrastructure, and certifications spanning ISO 27001, PCI-DSS, SOC 2, NIST CSF, CIS Benchmarks, and Microsoft Cybersecurity Architect Expert.
A typical engagement starts with a discovery and posture assessment: we inventory your non-human identities, surface the orphaned and over-permissioned ones, and map what we find to the frameworks you report against. From there we design and implement the control model, zero trust for machine identities, least privilege with just-in-time access, secrets management, agent guardrails, and behavioural monitoring wired into your SOC. Explore our cybersecurity services and cloud security and migration work, or lean on our managed IT support to keep the programme running after go-live.
If you want a fast read on where you stand, start with our free cyber security self-assessment and the cybersecurity readiness checklist. When you are ready to talk specifics, get in touch and we will scope it around your environment.
