AI agents need human identity verification, not just credentials

At a glance

What this is: This is a Trusona analysis arguing that AI agent workflows need human identity verification, because scoped credentials alone cannot prove the requester is the genuine person the agent is acting for.

Why it matters: It matters because IAM, PAM, and NHI programmes that stop at token hygiene still leave delegated actions exposed to impersonation, especially when agents execute requests faster and at greater scale than human-operated help desks.

Context

AI agent identity verification is the missing control when software is authorised to act on behalf of a person but cannot independently prove that person’s identity. The article argues that credentials answer only whether the agent may perform the action, not whether the underlying request is legitimate.

That gap matters for IAM and NHI governance because delegated workflows blur verification, authorisation, and approval. If an agent can reset access, move MFA, or trigger another privileged action on behalf of a user, the programme has to decide what evidence of human identity is required before the action is allowed to proceed.

Key questions

Q: What breaks when AI agents can act without a verified human behind them?

A: Fraud and IAM controls lose attribution. If an agent can move money, create accounts, or change settings without a verified human owner, the organisation may detect the action but still be unable to prove who authorised it or whether it was legitimate. That weakens investigation, dispute handling, and governance accountability across the full lifecycle.

Q: Why do AI agents make help desk impersonation risk worse?

A: Agents remove the human hesitation that sometimes interrupts a suspicious request and they scale the attacker’s reach beyond a single phone call. If the workflow accepts a request without proving the person behind it, the agent can execute the same fraudulent action repeatedly and at machine speed.

Q: How do security teams know if their verification controls are actually working?

A: They work if high-risk requests cannot be completed through a single channel and if helpdesk or approval attempts leave a clear audit trail. Look for reductions in informal overrides, fewer password resets completed without corroboration, and lower success rates for phishing simulations that use synthetic audio or video.

Q: Should teams treat agent credentials and human identity verification as the same control?

A: No. Agent credentials answer whether the software may act, while human identity verification answers whether the person behind the request is genuine. Those are different controls with different failure modes, and collapsing them creates a blind spot in delegated workflows that handle resets, recovery, or privileged changes.

Technical breakdown

Why agent credentials do not prove the human behind the request

A bearer token or scoped API credential establishes that a software agent is allowed to call an endpoint. It does not establish who initiated the task, whether that requester is the account owner, or whether the request was socially engineered. In delegated workflows, the agent inherits authority but not identity assurance. That is why credential hygiene, ownership records, and rotation schedules are necessary but insufficient: they govern the software identity, not the human identity embedded in the request context.

Practical implication: treat agent credentials as authorisation for execution, not as evidence of human identity.

What a machine-callable human verification step must do

If an agent is going to use verification at runtime, the check has to be callable, asynchronous, and machine-readable. The agent must be able to initiate the verification, poll for a terminal result, and branch on a simple verdict or risk signal. A browser-only flow or a human-interpreted document does not fit agent execution. The check also needs an external authority the requester cannot influence, otherwise the control collapses back into self-assertion disguised as identity proof.

Practical implication: design verification as an API-driven step with clear pass, fail, and risk states that an agent can consume directly.

Why knowledge questions and selfies fail as delegated identity controls

Knowledge-based authentication is weak because answers increasingly live in breach data, and generative systems can answer public or leaked prompts at scale. Selfie and liveness checks create a different problem: they add biometric collection without necessarily solving the underlying trust question. In delegated agent workflows, the issue is not whether a face looks real, but whether the person behind the request is the rightful account holder and whether an authoritative source can confirm that claim. That is a governance problem, not a cosmetic identity signal.

Practical implication: replace flimsy challenge-response checks with verification against an authoritative source outside the agent’s control.

Threat narrative

Attacker objective: The attacker aims to make a legitimate agent carry out an impersonated request that changes access on the attacker’s behalf.

1. Entry occurs when an attacker or impostor submits a plausible request to an agent acting on someone’s behalf, using the agent’s own access path rather than breaking the application directly.
2. Credential abuse follows when the agent executes the request because its token authorises the action, even though the human requester was never verified.
3. Impact is account takeover or unauthorised privilege change, such as MFA reset, password reset, or other delegated access modification that benefits the impersonator.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Delegated identity verification is a separate control from delegated authorisation. An agent can be perfectly scoped and still faithfully carry out an impersonated request because the software identity and the human identity are being conflated. The industry keeps overloading NHI hygiene with a problem it cannot solve. The implication is that agent workflows need a human-verification layer, not just a better inventory of tokens.

Identity proofing for agent actions must move from static assurance to runtime verification. The old assumption was that the requester could be checked once and then trusted for the life of the session or workflow. That assumption fails when an agent can execute the request asynchronously and at machine speed. The implication is that the control point shifts from who owns the credential to who can be proven, at the moment of action, to be the account holder.

Help desk impersonation is now an agentic trust problem, not only a social engineering problem. Software agents remove the human pause that sometimes exposes a fake request, and they scale an attacker’s reach well beyond a phone call. This is where identity governance and workflow design intersect. The implication is that programme owners need to decide which delegated actions are safe to automate and which require authoritative human verification every time.

Human identity verification becomes part of agent governance when the agent is acting as a proxy. The security question is no longer whether the agent has access, but whether the person behind the request has been verified by a source the requester cannot manipulate. That is a different assurance model from NHI lifecycle management. The implication is that IAM teams must define where proof of personhood belongs in delegated action chains.

Authoritative verification changes the trust boundary, but it does not solve action intent. Confirming that a person is genuine does not prove the request is appropriate, scoped correctly, or safe to execute. This is the named concept of human identity verification in delegated agent workflows. The implication is that verification, approval, and policy enforcement remain distinct controls and should not be collapsed into one workflow step.

What this signals

Delegated human verification will become a design requirement for high-risk agent workflows. Teams that let agents touch recovery, reset, or enrolment steps will need to decide where proof of personhood sits in the workflow and which authority the agent can trust. The programme implication is that identity governance must extend into runtime decision points, not stop at provisioning and rotation.

Human identity verification becomes an orchestration concern when the actor is a proxy. The agent is not the endpoint that needs to be trusted, but the workflow still needs a reliable outside authority to confirm the person the agent represents. That means IAM, help desk, and automation owners have to align on where verification is invoked, how results are consumed, and which actions remain non-delegable.

For practitioners

• Define which delegated actions require human identity verification Map agent-performed actions that can change authentication state, access scope, or recovery paths, and require an authoritative identity check before execution. Focus on actions where impersonation would produce immediate account takeover or durable privilege change.
• Separate agent authorisation from requester proofing Document where the agent’s token authorises execution and where a separate control proves the human behind the request. Keep those decision points distinct in policy, workflow design, and audit trails.
• Require machine-readable verification results Use verification outcomes that the agent can consume as pass, fail, or risk signals, rather than human-readable pages or free-text evidence that the workflow must interpret.
• Limit high-risk delegated actions to authoritative sources Anchor identity checks to sources outside the requester’s control when the action can reset credentials, move MFA, or alter recovery state. Avoid checks that can be satisfied by public data or user-provided assertions.
• Review agent workflows for hidden help desk assumptions Identify places where the workflow assumes a human can pause, question, or escalate. Replace those assumptions with controls suited to agent speed, queue processing, and unattended execution.

Key takeaways

• AI agents can inherit authority without inheriting any way to verify the human behind a request, which makes delegated execution a distinct identity risk.
• Credential hygiene still matters, but it does not stop impersonated requests when the workflow never proves who initiated the action.
• The practical control is to separate authorisation for the agent from verification of the person, especially for resets, recovery, and other security-state changes.

Key terms

• Delegated Identity Verification: A control that proves the human behind a request is genuine before a software agent executes the action. It sits alongside authorisation rather than replacing it, because the agent can be entitled to act while the requester still remains unverified.
• Agentic Proxy Action: An action performed by an AI agent on behalf of a person, where the agent inherits authority to execute but not automatic proof of the person’s identity. The security risk is that a valid workflow can carry out an impersonated request without detecting the fraud.
• Authoritative Identity Source: An authoritative identity source is the system trusted to define who or what should have access. It is usually the HR system for workforce identities or another governed directory for technical identities, and its accuracy determines whether automation strengthens or weakens control.
• Verification And Authorisation Separation: The governance principle that proving who someone is and allowing a system to act are not the same control. In agent workflows, conflating the two creates a blind spot where a legitimate token can execute an illegitimate request.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.