By NHI Mgmt Group Editorial TeamPublished 2026-06-08Domain: AnnouncementsSource: SumSub

TL;DR: AI-driven fraud is getting harder to distinguish from legitimate automation, with Sumsub citing a 180% year-on-year increase in multi-step, coordinated attacks in 2025 and a model that binds agent activity to verified human identity for accountability. The real shift is that identity teams must govern automation as a trust and attribution problem, not just a bot-detection problem.


At a glance

What this is: This is a Sumsub announcement about AI Agent Verification, which links AI-driven automation to verified human identity so businesses can separate lawful automation from malicious agent activity.

Why it matters: It matters because IAM and fraud teams now have to decide when automation should be challenged, attributed, or allowed across human, NHI, and emerging agentic workflows.

By the numbers:

👉 Read Sumsub's article on AI agent verification and Know Your Agent


Context

AI agent verification sits at the intersection of fraud prevention, identity assurance, and governance. The core problem is simple: once automation can initiate actions at scale, security teams need a reliable way to decide whether the activity is legitimate, suspicious, or unauthorised without treating every automated interaction as the same risk.

For IAM programmes, the challenge is not just detecting bots. It is proving who is accountable when automation moves money, opens accounts, changes controls, or triggers high-value actions. That is why AI agent identity now has to be handled as a governance problem, not only a detection problem, and it links directly to broader NHI and human identity controls.

For teams already building NHI programmes, the useful question is how verified identity, risk scoring, and step-up checks fit into existing lifecycle and access decisions. For teams with emerging agentic workflows, the same control logic starts to blur the boundary between human authorisation, machine activity, and delegated execution.


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 complicate identity and access management programmes?

A: They complicate IAM because they sit between user intent and machine execution. A delegated action can look legitimate at the device level while still being unauthorised at the business level, so traditional user-centric controls miss the accountability gap. Teams need assurance, context, and ownership together, not authentication alone.

Q: How do security teams decide when to challenge automated activity?

A: They should challenge automation when the action is high risk, state changing, or hard to reverse. The right trigger is not simply that the activity is automated, but that the business impact would be material if the actor were impersonated, misused, or operating outside an approved delegation boundary.

Q: What should organisations do when delegated automation changes role or leaves service?

A: They should treat delegated automation like a governed identity with lifecycle events, not a one-time setup. When the human sponsor changes role or exits, the automation’s authority, approvals, and exception paths must be reviewed so accountability does not outlive the business relationship that justified it.


How it works in practice

How AI agent verification uses risk-based identity checks

AI agent verification combines detection of automated activity with risk scoring and conditional challenges. In practice, that means the system first identifies when behaviour looks machine-driven, then weighs contextual signals before deciding whether to let the action proceed, add friction, or require stronger proof of a real human behind the request. Liveness tests are used at higher-risk moments to reduce impersonation risk, especially where deepfakes or account takeover could exploit weak assurance. The important design choice is not blanket blocking, but policy-driven escalation based on risk and action sensitivity.

Practical implication: map high-risk workflows to step-up identity proofing instead of relying on default bot blocking.

Why accountability matters when automation can act at scale

The governance issue is attribution. When an AI agent can initiate transactions, create accounts, or change settings, the organisation needs a defensible way to tie that action back to a verified human owner or authoriser. Without that linkage, automated activity becomes difficult to investigate, contest, or certify in fraud reviews. This is why identity assurance is doing more work here than classic bot management. It is not just identifying non-human traffic, but establishing a chain of accountability that survives review, dispute, and remediation.

Practical implication: require an attributable human owner for every automation path that can change customer, payment, or account state.

How verified human identity changes the control boundary for automation

The control boundary shifts from 'is this a bot?' to 'is this automation authorised, attributable, and proportionate to the risk?' That is a more useful model for modern digital operations because many legitimate workflows now rely on browser automation and delegated action. Verified human identity lets teams distinguish legitimate delegated activity from anonymous abuse, but it also exposes where current IAM and fraud controls are too coarse. If policy only understands users or devices, it will miss the accountability layer that agent-driven workflows now require.

Practical implication: extend policy models so delegated automation carries both device signals and human accountability evidence.


NHI Mgmt Group analysis

AI agent verification is really an accountability control, not a bot control. The article frames automation as manageable when it can be tied to a verified human, which places the control problem squarely in identity governance rather than perimeter filtering. That matters because fraud teams often over-index on machine detection while missing the attribution layer that decides who is answerable for the action. The practitioner takeaway is that automation policy and identity assurance now need to be designed together.

Verified human identity can reduce fraud ambiguity, but it does not solve delegated trust on its own. Linking activity to a person helps separate legitimate automation from anonymous abuse, yet the control still depends on where that person authorisation begins and ends. In IAM terms, this is a boundary-setting problem across delegated access, step-up verification, and lifecycle governance. The practitioner implication is to make accountability explicit for every automation path that can affect value, funds, or control states.

Delegated automation accountability: This is the named concept this announcement sharpens. The article shows that once agents act on behalf of people, the programme must prove who authorised the action, not merely whether the action came from a known device or session. That shifts the field toward human-backed automation governance, where accountability is attached to delegated execution rather than just authentication events. The practitioner conclusion is to treat attribution as a first-class identity control.

Agentic fraud pressure is converging with NHI governance gaps. AI agents, browser automation, tokens, and service identities are all part of the same operational surface when actions are executed without a person in the loop. That is why this topic cannot be isolated inside fraud tooling alone. The broader lesson is that IAM, fraud prevention, and NHI governance now share the same trust boundary, and teams that manage them separately will miss the control overlap.

From our research:

  • 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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, inappropriately sharing sensitive data, and revealing access credentials.
  • That gap is why teams should also study OWASP Agentic AI Top 10 alongside the governance controls in Ultimate Guide to NHIs.

What this signals

Delegated automation accountability: The near-term programme shift is from detecting anonymous automation to proving who stands behind it. Once AI agents can initiate customer or payment actions, security teams need identity evidence that survives review, exception handling, and incident investigation.

The practical pressure point is lifecycle governance. If the human sponsor changes role, the automation cannot be left with the same authority by default, because the approval chain no longer matches the business relationship that created the risk. Teams that formalise that boundary now will have a clearer path to policy, audit, and fraud response.


For practitioners

  • Map automation paths to accountable humans Inventory every workflow where AI or browser automation can create accounts, move funds, change controls, or trigger payouts, then require a named human owner for each path. Make the owner visible in approval, exception, and incident processes.
  • Apply step-up checks at high-risk moments Use liveness or equivalent identity assurance only where the action changes state materially, such as onboarding, account control changes, or high-value payouts. Avoid blanket friction and reserve stronger checks for the moments where impersonation would matter most.
  • Separate bot detection from authorisation policy Treat device intelligence and bot detection as signals, not final decisions. Combine them with entitlement, transaction sensitivity, and lifecycle context so authorised automation can proceed while anonymous or unowned automation is challenged or stopped.
  • Extend lifecycle governance to delegated automation Define how delegated automation is onboarded, reviewed, and offboarded when the underlying person changes role or leaves. If the automation keeps acting after the human relationship has changed, the accountability model has already failed.

Key takeaways

  • AI agent verification reframes automation as an identity and accountability problem, not just a bot-detection problem.
  • Sumsub cites a 180% year-on-year increase in multi-step, coordinated attacks, which explains why risk-based identity assurance is gaining urgency.
  • Practitioners should tie every high-risk automation path to a verified human owner and lifecycle review point.

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 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Agent-driven automation raises identity and accountability risks.
NIST AI RMFAI governance needs explicit accountability for delegated automation.
NIST CSF 2.0PR.AA-01Identity assurance and authorised actions are central to this topic.

Document who is accountable for each automation path and review it in governance cycles.


Key terms

  • AI Agent Verification: AI agent verification is the process of linking automated actions to a known, validated human identity or other accountable owner. It turns automation from an anonymous event into a governed activity with attribution, risk checks, and reviewable evidence across the action lifecycle.
  • Delegated Automation: Delegated automation is machine-executed activity performed on behalf of a person or business process. The control issue is not whether the machine can act, but whether the delegation boundary, approval, and ownership remain valid when the action has financial, account, or security impact.
  • Liveness Verification: Liveness verification checks that a real, present person is participating at a critical moment rather than a replay, deepfake, or synthetic impersonation. In automation-heavy environments, it is used selectively where identity fraud would create material risk and where human authorisation must be proven.
  • Accountability Chain: An accountability chain is the set of identity, approval, and ownership links that explain who authorised an action and who remains responsible for it. In AI-assisted workflows, that chain must be explicit enough for audit, dispute handling, and incident response.

Deepen your knowledge

AI agent verification and delegated automation accountability are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into automation-heavy workflows, it is a useful place to start.

This post draws on content published by Sumsub: AI Agent Verification and Know Your Agent. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-08.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org