A Hong Kong insurer's claims team connects an AI agent to Outlook, the policy system and a shared drive. It works. Adjusters love it. The agent runs on an API key a developer generated under his own account.
Nine months later the developer resigns. His laptop is wiped, his email is closed, and his access badge is returned. The agent keeps running. Nobody in IT can say which systems it can reach, whose authority it is acting under, or how to switch it off without breaking the claims queue.
That gap has a name. It is the AI agent identity problem, and in the last five weeks it has become one of the most crowded categories in enterprise software. This guide explains what agent identity is, why it matters now, and a practical framework for governing agent access before your agent count outgrows your controls.
What is AI agent identity?
AI agent identity is the practice of giving every AI agent its own registered, governed identity, with a named human owner, permissions scoped to its task, short-lived credentials and a full audit trail. It replaces the common habit of letting agents borrow an employee's login or carry a static API key that never expires.
Think of it as onboarding a digital worker properly. A new employee gets a staff record, a manager, role-based access and an exit process. An agent deserves the same treatment, because it can read, write and send on your behalf.
Okta, whose products underpin workforce login at many large enterprises, frames the discipline as four questions every organisation must be able to answer at any moment:
--- Where are my agents? A complete register, including agents employees built themselves.
--- What can they do? The apps, data, MCP servers and other agents each one can reach.
--- What are they doing? A live, attributable log of actions.
--- How do I respond? The ability to revoke access instantly when something goes wrong.
If your team cannot answer all four for every agent in production, you have an identity gap, regardless of how good the underlying AI model is.
Why has agent identity become a board-level issue in 2026?
Agent identity has become a board issue because agents now take actions, not just answer questions, and most organisations govern them far more loosely than people. Okta's 2026 research found only 34% of organisations apply the same security controls to agents as to human staff, while 58% reported an AI-related security incident or close call.
The numbers come from Okta's AI Agents at Work 2026 survey of 292 executives and 492 knowledge workers across seven countries. Three findings stand out for leadership teams:
--- Overconfidence: 90% of executives were confident in their visibility into AI tools, yet 52% of employees admitted using AI tools without approval.
--- Credential exposure: 16% of workers said they had shared login credentials or passwords with an AI tool.
--- Inconsistent controls: only 34% treat agents with the same rigour as employees.
Analysts expect consequences. Gartner predicted in May 2026 that by 2027, 40% of enterprises will demote or decommission autonomous AI agents because of governance gaps discovered only after production incidents.
The vendor market has responded fast. According to Forkast's September 2026 analysis, Okta, IBM, Broadcom and Dataiku all shipped standalone agent governance products within roughly two weeks. Okta made Agent SSO generally available on 24 August, included in core SSO at no additional cost, and on 22 September announced a kill switch, agent gateway and shadow-agent discovery. OpenAI's GPT-6 Astra computer-use model, launched on 3 September, ships switched off by default for enterprise workspaces until an admin enables it.
How is an agent identity different from a service account?
A service account runs fixed, predictable code, so its access can be set once and reviewed yearly. An AI agent decides at runtime which tools to call, can hand work to other agents, and often acts on behalf of a specific person. That makes delegation, scope and real-time monitoring essential, which service-account practices were never designed to cover.
Most IT teams already manage non-human identities such as service accounts and API keys. The instinct is to put agents in the same bucket. That works for a scheduled script. It fails for an agent for three reasons:
--- Non-deterministic behaviour: the same agent may call the CRM today and the finance system tomorrow, depending on the prompt.
--- Delegation chains: an agent acting for a relationship manager may invoke a second agent, which calls a third tool. Accountability must be traceable through every hop.
--- Speed and scale: an agent can take hundreds of actions a minute. Quarterly access reviews cannot keep up.
The practical difference is that an agent identity links three things together: the agent, the human or team that owns it, and the specific task it is authorised to perform.
What does a practical agent identity framework look like?
A practical framework has four layers: register every agent with a named owner, scope its access to the task rather than the person, log every action in a place security can see, and build a tested way to contain it. Each layer maps to one of the four questions and can be rolled out incrementally over a single quarter.
Layer 1: Register and own
Every agent gets an entry in your identity directory, a business owner and a technical owner. No owner, no production access. Include agents built in low-code tools and browser extensions, which is where shadow agents usually live.
Layer 2: Scope to the task
Grant the minimum access the task requires, using short-lived tokens instead of permanent keys. An agent that drafts claim letters needs read access to the claim file, not write access to the payments ledger.
Layer 3: Log and observe
Send agent actions to the same monitoring your security team already uses, tagged so an agent action is never mistaken for a human one. Review outcomes, not just uptime.
Layer 4: Contain and offboard
Define who can switch an agent off, how fast, and what happens to its in-flight tasks. Tie agent offboarding to employee offboarding, so an owner's resignation triggers a review of every agent they own.
How should access scale with an agent's level of autonomy?
Access should grow in proportion to autonomy. Gartner's May 2026 model defines four levels: observe, advise, act with approval, and act autonomously. Read-only agents need light controls; autonomous agents need continuous monitoring, circuit breakers and rapid rollback. Applying one uniform rulebook to all agents is exactly what Gartner warns will cause failure.
Gartner's four levels give leadership teams a common language for approving agents:
--- Level 1, Observe: read-only access, outputs seen only by the requester. Baseline controls: scoped data access, authentication, usage logging.
--- Level 2, Advise: drafts and recommendations, humans execute. Add accuracy and hallucination testing and user training.
--- Level 3, Act with approval: can write data or send messages after explicit human sign-off. Add approval audit trails and agent-specific incident response.
--- Level 4, Act autonomously: executes within guardrails, humans review exceptions. Add continuous monitoring, circuit breakers and named accountability.
AWS's Reimagine 2026 research, reported by Help Net Security on 28 September, adds a useful rule: treat a new agent like a new hire on probation. Start with human approval, widen autonomy only as reliability is proven, and set security limits outside the agent, because agents can misinterpret or work around rules embedded in their own instructions.
What does agent identity look like in a Hong Kong enterprise?
In Hong Kong, agent identity sits on top of existing obligations. Under the Personal Data (Privacy) Ordinance, your organisation remains the data user when an agent processes personal data. Regulated firms also face HKMA and SFC supervisory expectations. A clear register, scoped access and audit logs are how you demonstrate that control to regulators and clients.
Financial services
A bank's relationship managers use an advisory agent that summarises client portfolios. At Level 2 it reads data but never trades. The identity team scopes it to one business unit's client records and logs every retrieval, which gives compliance a ready answer during a supervisory review.
Logistics
A freight forwarder lets an agent update shipment status in its transport management system. Because it writes data, it runs at Level 3 for its first 60 days, with a supervisor approving each batch. Autonomy is widened only after error rates are measured.
Professional services
A mid-sized accounting firm discovers 14 agents that staff built on personal accounts. Rather than banning them, it registers the useful ones, assigns owners, moves them onto firm-managed credentials and retires the rest.
For personal data, the PCPD's Model Personal Data Protection Framework for AI remains the local reference point. Agents with persistent memory deserve special attention, because they accumulate personal data over time.
What are the most common agent identity mistakes?
The most common mistakes are letting agents run on borrowed human credentials, storing permanent API keys in configuration files, applying the same rules to every agent, forgetting agents when their owner leaves, and buying several overlapping governance tools without a single register. Each one is avoidable with a written policy and an owner.
--- Borrowed credentials: the agent inherits everything its human can reach, far more than its task needs.
--- Permanent keys: static keys leak through code repositories and chat logs, and nobody rotates them.
--- Uniform governance: over-restricting simple agents pushes teams to build shadow agents; under-restricting autonomous ones creates the incidents Gartner describes.
--- Orphaned agents: agents keep running after their owner leaves, exactly the scenario Okta highlighted at Oktane in September.
--- Governance sprawl: identity from one vendor, runtime controls from another and monitoring from a third can become harder to manage than the agents themselves.
--- Policy on paper only: the AWS research found that slow approval processes push AI use underground.
Security testing matters too. Agent permissions should be part of your AI red teaming and penetration testing scope, and agent activity costs belong in your AI FinOps reporting.
What should you ask your IT team and vendors this quarter?
Ask five questions: how many agents run today, who owns each one, which use permanent keys, how fast can any agent be switched off, and what happens to an agent when its owner leaves. Then track four board metrics: owner coverage, short-lived credential coverage, time to revoke, and shadow agents discovered each month.
Five questions for your next leadership meeting
--- How many AI agents are running in production today, including ones built by business teams?
--- Does every agent have a named business owner?
--- Which agents still authenticate with permanent API keys or personal accounts?
--- If an agent misbehaved at 3am, how many minutes would it take to cut off its access?
--- What happens to an agent when its owner resigns or changes role?
Four metrics to report upward
--- Owner coverage: percentage of agents with a named owner. Target 100%.
--- Credential hygiene: percentage of agents on short-lived tokens.
--- Time to revoke: tested minutes from decision to full shutdown.
--- Shadow discovery: unregistered agents found per month, which should fall over time.
When evaluating vendors, ask whether their agents support standard identity protocols, whether actions are logged in a format your security tools can read, and whether you can revoke an agent's access without calling their support desk.
What is the strategic takeaway?
Agent identity is not a security side project. It is the operating licence for scaling AI agents. Organisations that register, scope, log and contain their agents now will be able to expand autonomy with confidence. Those that do not will meet their governance gaps the way Gartner predicts: after an incident.
Start small. Build the register this month, assign owners, retire permanent keys, and test your kill switch before you need it.
We understand AI. We understand you. With UD by your side, AI never feels cold.
Reviewed by the UD enterprise AI team. Figures cited were verified against the original publications on 29 September 2026.
Find Out Where Your Organisation Stands
Now that you have the framework, the next step is knowing how ready your organisation is to govern AI agents at scale. We'll walk you through every step, from an AI readiness assessment and agent inventory to access policy design, deployment and ongoing performance tracking, drawing on 28 years of serving Hong Kong enterprises.
