By NHI Mgmt Group Editorial TeamDomain: Agentic AI & NHIsSource: TrusonaPublished September 9, 2026

TL;DR: An agent can have valid credentials and still execute an impersonated request, because authorization proves only that the software may act, not that the human behind the request is genuine, according to Trusona. The governance gap is that verification and delegation are being treated as the same problem when they are not.


At a glance

What this is: This article argues that AI agent workflows need a separate check for the human they are acting for, because credential hygiene alone does not verify request legitimacy.

Why it matters: This matters because IAM, PAM, and NHI programmes can otherwise approve actions that look authorized at the token level but remain unverified at the human-identity level.

By the numbers:

👉 Read Trusona's blog on verifying the human behind AI agent actions


Context

AI agent identity governance is not the same as human identity verification. In this case, the core problem is that an agent can inherit authority to act while inheriting no reliable way to confirm the human behind the request, which leaves account recovery and delegated actions exposed to impersonation.

That distinction matters for IAM and NHI teams because credential management answers who or what may execute an action, while verification answers whether the request itself is legitimate. Trusona’s example shows why those controls cannot be collapsed into a single workflow without leaving a governance gap.

For teams already working on AI agent oversight, the question is not whether the agent has a token. The question is whether the request can be tied to a verified human identity before the agent carries out a sensitive action.


Key questions

Q: How should security teams handle delegated access when AI agents act on behalf of customers?

A: Security teams should treat delegated access as a separate governance layer, not as a normal login session. Define what the agent can do, how much value it can move, which approvals are required, and how delegation is revoked. Without those boundaries, the agent inherits more authority than the customer intended and fraud risk expands quickly.

Q: Why are AI agent credentials not enough to prevent impersonation?

A: Because credentials establish authorization for the agent, not authenticity of the underlying request. An agent with a valid token will carry out a fraudulent instruction just as faithfully as a legitimate one. The missing control is verification of the person being represented, not more token management.

Q: What breaks when humans verify AI output but do not own the workflow?

A: Responsibility becomes ambiguous. A human may approve a result that was substantially shaped by a machine, while the controls still record the human as the primary actor. That gap weakens auditability, makes recertification less meaningful, and can hide where the real decision authority sat inside the workflow.

Q: Should organisations use one control for both NHI governance and human request verification?

A: No. NHI governance should manage the agent's token, scope, and ownership, while request verification should prove the human behind the action. Combining them hides the failure mode and gives a false sense of security, especially in delegated access and identity recovery flows.




NHI Mgmt Group analysis

Identity verification and NHI credential management are not interchangeable controls: This article exposes a common governance mistake, which is treating an agent's ability to act as proof that the underlying request is legitimate. NHI hygiene can tell you who the software is, but it cannot tell you who asked the software to act. Practitioners should stop collapsing these controls into one workflow.

Delegated authority without request-origin verification is a weak identity model: The real failure is not that the agent lacks credentials, but that the organisation has no verifiable link between the action and the human who initiated it. That is a governance gap across IAM, help desk workflows, and privileged recovery paths. The implication is that delegated actions need explicit human-origin assurance, not just authorization.

AI agent workflows expose a new trust boundary between authorization and verification: Agentic automation makes the old help desk social engineering problem faster, more repeatable, and easier to scale. The same impersonation that once depended on a convincing phone call can now be embedded in a software workflow that executes at machine speed. That changes incident probability and response assumptions for identity teams.

Named concept: delegated authority verification gap: This is the control failure where an agent is trusted to act because it is authenticated, even though the human request it executes has never been independently verified. It is a distinct problem from secret rotation or token ownership. Organisations that do not name this gap will keep overestimating what NHI controls can prove.

Human verification must become an explicit policy decision in agent governance: Not every action should require the same level of assurance, but sensitive recovery, enrollment, and access changes cannot be left to agent discretion alone. The right design question is which actions must be tied to outside-the-requester verification. That is now an identity governance decision, not just a product choice.

From our research:

  • Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
  • 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
  • See also: OWASP Agentic AI Top 10 for the control patterns that address agent goal hijacking, tool misuse, and identity abuse.

What this signals

The operational signal here is that AI agent governance is moving beyond credential inventory and into decision provenance. If a workflow can reset authentication, change access, or approve recovery without proving who initiated it, the control framework is incomplete. Teams should treat this as a workflow design issue, not a narrow authentication issue.

Delegated authority verification gap: identity programmes need a named control boundary for proving the human origin of an agent-driven request. That boundary is distinct from token management, and it belongs in IAM, PAM, and agent governance conversations together, not separately.

With 80% of organisations already reporting agent actions beyond intended scope, per the AI Agents: The New Attack Surface report, the risk is no longer hypothetical. Practitioners should expect more pressure to prove request legitimacy before allowing sensitive automation to proceed.


For practitioners

  • Define which agent actions require external human verification Map account recovery, MFA reset, enrollment changes, and other high-impact actions to a verification step that checks the human behind the request against an authority the requester does not control.
  • Separate NHI credential controls from request authenticity controls Keep token rotation, scoping, and ownership reviews in the NHI programme, but add a distinct control for proving request legitimacy before the agent executes sensitive changes.
  • Require API-callable verification for agent workflows Use a verification method the agent can initiate, poll, and branch on, rather than a human-only page that breaks automation or invites bypass.
  • Review overnight queue handling for high-risk actions Identify agent-driven support or recovery tasks that run without human oversight and decide which of them should pause until verification succeeds from an external source.

Key takeaways

  • AI agents can be authorized to act and still be unable to prove the human behind the request, which leaves a direct impersonation gap.
  • Credential management is necessary but insufficient when the security decision depends on who initiated the action, not just what token is present.
  • Identity teams should treat human-origin verification for delegated actions as a separate governance control, especially for recovery and authentication changes.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Identity and tool misuseThe article is about agent-driven action and identity verification boundaries.
Recommendation — Map delegated-action workflows to agent identity and tool-misuse controls before allowing high-impact execution.
OWASP Non-Human Identity Top 10NHI-01 — Inventory and OwnershipThe post distinguishes agent identity management from human request verification.
Recommendation — Inventory agent credentials and owners separately from request-origin verification requirements.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article centres on governance for agentic actions and accountability boundaries.
Recommendation — Define governance for who can initiate agent actions and who must verify the human request behind them.
NIST CSF 2.0PR.AC-4 — Access Permissions and AuthorisationsThe agent may be authorized, but the human request still needs separate assurance.
Recommendation — Apply PR.AC-4 alongside request verification so authorization does not substitute for identity proof.
NIST SP 800-53 Rev 5IA-2 — Identification and AuthenticationThe issue is proving the identity behind high-risk delegated actions.
Recommendation — Extend identification and authentication to the human origin of delegated requests before sensitive actions execute.

Key terms

  • Delegated Authority Verification: A control that proves a human request behind an automated action is legitimate before the system executes it. It sits beside authorization, not inside it. In AI agent workflows, this separates token possession from request authenticity and prevents an authenticated agent from acting on an impersonated instruction.
  • Request Origin Assurance: Evidence that ties a sensitive request to a verified initiating human, rather than to the software that delivered it. This matters when an AI agent can perform privileged actions on behalf of users. The control is about provenance of intent, not the agent's own identity or scope.
  • Delegated Action Workflow: An operational path where one identity, often an AI agent, performs a task for another identity. The workflow may be authorized, but that does not mean the request source has been verified. Security teams must govern both the delegated permission and the proof of who initiated the delegation.
  • Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.

What's in the full article

Trusona's full blog covers the operational detail this post intentionally leaves for the source:

  • Runnable agent-skill setup for ATO Protect, including the shell-based workflow and environment variable configuration.
  • The exact verification sequence for creating, polling, and resolving a human identity check inside an agent workflow.
  • Implementation details for running the check against external authority records rather than requester-controlled data.
  • The distinction between the software-agent use case and the separate human help desk Agent Verify workflow.

👉 Trusona's full post covers the agent skill workflow, identity check mechanics, and the scope limits of the verification model.

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 building or maturing an identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on September 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org