Entro Security's 2026 research found that non-human identities now outnumber human identities by 144 to 1 in cloud-native enterprise environments, up from 92 to 1 in the first half of 2024. Most Hong Kong organisations are still running identity governance programmes designed for the humans.
That mismatch is the quiet failure point in enterprise AI. Your board approved agents that book, approve, reconcile and email on the company's behalf. Nobody approved a way to tell one agent from another, or to prove afterwards which one acted.
What is agent identity?
Agent identity is the practice of giving each AI agent its own verifiable credential, its own permission scope, and a recorded delegation chain showing which human authorised which action. It answers three questions during an incident review: which agent acted, on whose behalf, and under what authority.
Without it, an agent's activity appears in your logs as whatever shared API key it borrowed. The action is real. The accountability is not.
The term entered enterprise vocabulary in 2026 for a practical reason. Identity platforms that were built to answer "is this person who they claim to be" now have to answer "is this agent acting within the authority a person actually gave it", which is a different question with a different failure mode.
The Cloud Security Alliance's 2026 work on non-human identity governance describes the same gap: agents provision access, trigger workflows and interact with enterprise systems as non-human identities, while the controls governing them were written for static machine accounts.
This matters because agents do not behave like software. They make choices inside a task, and those choices consume permissions that nobody scoped in advance.
Why is agent identity different from a service account?
A service account has standing identity and standing scope: the same permissions, permanently, regardless of task. An AI agent has variable scope per task, acting for different users, at different times, through different delegation chains. Treating an agent as a service account grants it the union of every permission it might ever need.
The practical difference in one line
--- A service account asks: what is this system allowed to do?
--- An agent identity asks: what is this agent allowed to do, right now, for this person, on this task?
An agent that reconciles invoices for the finance controller at 09:00 and drafts vendor emails for procurement at 14:00 should not hold both permission sets at once. Under a service-account model, it does.
How many non-human identities does a typical enterprise already have?
Across all enterprise environments the average ratio of non-human to human identities sits near 45 to 1, rising to 144 to 1 in cloud-native estates according to Entro Security's 2026 research. For a 300-person Hong Kong company, that implies roughly 13,500 machine credentials already in circulation before a single agent is deployed.
Gartner projects that 40% of enterprise applications will integrate task-specific AI agents by the end of 2026, up from under 5% when the forecast was published.
Two structural forces drive the count. Cloud adoption and microservices decomposition each multiply the credentials a single business process needs, and every SaaS integration you approve arrives with its own credential set attached.
The governance confidence gap tracks the growth. Industry surveys in 2026 report that only around 1.5 in 10 organisations are highly confident they can secure non-human identities, against nearly 1 in 4 for human identities.
Gartner further projects the average Fortune 500 organisation will run more than 150,000 agents by 2028, against fewer than 15 in 2025. The curve is not linear, and neither is the credential sprawl underneath it.
What does the Hong Kong PCPD say about agentic AI?
In March 2026 the Privacy Commissioner for Personal Data issued a specific alert treating agentic AI as a distinct and elevated privacy risk, citing the unprecedented level of access and autonomy granted to agents combined with security controls that have not been tested at scale. The PCPD's May 2026 compliance checks across 60 Hong Kong organisations found 95% already using AI in daily operations, with over half running three or more AI systems.
The PCPD's concern is specific: agents may reach local devices, files, emails, credentials, browser contents and external services, then execute multi-step tasks without real-time human involvement.
No PDPO contraventions were found in that round of checks. The recommendations were governance structures, privacy impact assessments, AI audits, staff training and incident-response plans. That is a regulator describing the gap before it becomes an enforcement action.
How do you build an agent identity framework in four steps?
A workable framework has four steps: inventory every agent and the credential it currently uses, issue each agent a unique credential, scope permissions per task rather than per agent, and log the delegation chain so every action traces back to an authorising human. Most organisations can complete the first two steps in a quarter.
Step 1: Inventory before you govern
List every agent running in production, including the ones a business unit deployed without telling IT. For each, record the credential it uses and whether that credential is shared with anything else. Shared credentials are your highest-severity finding.
Step 2: Issue unique credentials
Each agent receives its own identity. In 2026 the common patterns are JWT tokens with custom claims, mTLS client certificates from an enterprise PKI, or cloud-vendor managed identities. The Model Context Protocol specification mandates OAuth 2.1 with PKCE for protected HTTP deployments, which gives integration teams a defensible default.
Step 3: Scope per task, not per agent
Permissions attach to the task the agent is executing and the human who authorised it, not to the agent as a permanent entity. This is the step most programmes skip, and it is the one that limits blast radius.
Step 4: Log the delegation chain
Every logged action should name the agent, the authorising human, the task scope and the timestamp. If your audit trail cannot answer "who told it to do that", you do not have an audit trail.
What does this look like in a Hong Kong financial services firm?
Consider a 400-person licensed asset manager running agents for client onboarding checks, portfolio reporting and internal helpdesk. Under shared credentials, the onboarding agent technically holds read access to client records, portfolio positions and the internal wiki, because those permissions were bundled once at deployment.
Under an agent identity model, the onboarding agent receives a credential scoped to onboarding records only, valid for the duration of the task, tied to the compliance officer who initiated it.
When the regulator asks who accessed a specific client file on a specific date, the answer takes minutes rather than a forensics engagement. That is the operational value, separate from the security value.
The cost argument usually settles the debate. Retrofitting identity onto agents already in production means re-testing every integration those agents touch, which in a licensed firm also means re-running the change-control process for each one.
Designing it in at deployment costs a fraction of that, and the difference is almost entirely engineering time rather than licence spend.
The same logic applies to logistics firms running agents against shipment systems and to property managers running agents against tenant records. The sector changes; the delegation problem does not.
What goes wrong when enterprises skip agent identity governance?
Three failures recur. Agents accumulate permissions nobody reviews, incidents cannot be attributed to a specific agent, and departing staff leave behind agents still acting under their delegated authority. Each is cheap to prevent at design time and expensive to unwind after deployment.
Failure 1: Permission accumulation
An agent gets a new capability, and someone widens its credential rather than issuing a scoped one. Twelve months later the agent can reach systems its original business case never mentioned.
Failure 2: Unattributable incidents
Something moved data it should not have moved. The log shows a shared service credential used by four agents and two integration scripts. Your investigation now starts from zero.
Failure 3: Orphaned delegation
A department head leaves. Their agents keep running under an authority that no longer exists, and offboarding checklists built for humans do not catch them.
There is a second-order effect worth naming. When a regulator or an auditor cannot get a clean attribution answer, the practical response inside most organisations is to slow agent deployment across the board, including the agents that were governed properly.
One unattributable incident therefore costs more than the incident. It costs the momentum of every AI initiative that was working.
These failures compound with the ones described in shadow AI adoption, where staff deploy tools outside any governance process at all.
What should you do in the next 90 days?
Run an agent inventory in weeks 1 to 4, classify agents by data sensitivity in weeks 5 to 8, and issue unique credentials to your highest-sensitivity agents in weeks 9 to 12. This sequence produces a board-presentable position without pausing any AI initiative already in flight.
--- Weeks 1 to 4: inventory every production agent and its current credential
--- Weeks 5 to 8: classify by the sensitivity of data each agent can reach
--- Weeks 9 to 12: issue unique, task-scoped credentials to the top tier
--- Ongoing: review the delegation chain quarterly, alongside human access reviews
How to frame this for your board in one slide
--- Current state: how many agents run in production, and how many share credentials
--- Exposure: the most sensitive dataset any shared credential can currently reach
--- Regulatory position: what the PCPD's March 2026 agentic AI alert asks of you
--- Plan: the 90-day sequence, with the owner and the budget for each phase
Boards approve identity work when it is framed as attribution rather than as security spending. Attribution is a governance concept the audit committee already understands, and it converts an open-ended technology request into a defined control gap with a closing date.
The reason to start with inventory rather than tooling is that most organisations discover their agent count is wrong by a factor of two or three. You cannot buy a control for a population you have not counted.
The strategic takeaway
Agent identity is not a security add-on you bolt on after deployment. It is the difference between an AI programme you can explain to a regulator and one you can only apologise for.
The organisations that will move fastest on agentic AI over the next eighteen months are the ones that solved attribution early, because they can approve new agents without reopening the same governance argument every quarter.
Hong Kong enterprises have a narrow advantage here. The PCPD has published its concerns before enforcement, which means the framework can be built deliberately rather than under pressure. That window does not stay open indefinitely.
We understand AI. We understand you. With UD by your side, AI never feels cold. Twenty-eight years of working alongside Hong Kong enterprises has taught us that the governance conversation is never really about technology. It is about whether a department head can stand in front of the board and account for what the system did.
Reviewed by the UD enterprise AI team.
Now that you have the framework, the next step is finding out where your organisation actually stands. We'll walk you through every step, from AI readiness assessment to agent inventory, credential design, and board-level reporting.
