Why bot or human is becoming the wrong question for access

At a glance

What this is: This is an analysis of why human-versus-bot verification is losing value as AI agents begin acting on behalf of users in commerce and banking.

Why it matters: It matters because identity programmes will need to govern delegated action, not just login success, across human, agentic, and account-level access decisions.

Context

The governance gap is no longer whether a login looks human enough, but whether the actor behind it is allowed to take the next action. Traditional verification assumes that proving presence, device continuity, or liveness resolves trust, yet delegated software can still operate with valid credentials while exceeding the user’s intended authority. That makes identity control a question of session governance, not just authentication.

In banking, the problem is sharper because customer expectations already tolerate background risk checks, step-up prompts, and continuous verification. In ticketing and other high-demand consumer flows, the same controls are often used differently: they are tuned to stop bulk abuse, not to govern legitimate agents acting for real users. The article is strongest where it shows that the same identity event can require very different controls depending on the action being requested.

Key questions

Q: How should organisations govern autonomous agents that act on behalf of users?

A: They should require clear delegation, task-scoped permission, and continuous traceability back to a human creator. The goal is not to impersonate the user more perfectly, but to narrow what the agent can do, preserve auditability, and separate ordinary automation from high-risk action.

Q: Why do bot detection controls struggle with AI agents?

A: Bot detection controls struggle because AI agents can behave like normal users or services while still acting independently. A fingerprint or traffic pattern can show automation, but it cannot always prove whether the actor is trusted, delegated, or abusive. That creates ambiguity at the exact point where authorisation should be decisive.

Q: What breaks when liveness checks are treated as proof of trust?

A: Liveness checks only confirm that a real person was present at a point in time. They do not prove the later action was intended, safe, or still within scope. When an AI agent inherits that trust, the organisation can end up approving transactions or changes that were never explicitly authorised for that session.

Q: Should financial organisations use the same controls for customers and agents?

A: No. Customers, human delegates, and software agents represent different risk profiles and should not receive the same approval path. Human logins can rely more on identity verification, while agents need delegated authority limits, per-action policy checks, and stronger confirmation for transactions that change funds, ownership, or access.

Technical breakdown

Why login success no longer proves user intent

A successful login only proves that a credential, device, or biometric check passed at the front door. It does not prove that the subsequent action was authorised by the account owner. That gap matters when AI agents operate inside a user session, because the agent can inherit trust from the user and still take actions the user never meant to approve. In practice, identity assurance must extend beyond authentication into action-level authorisation, session context, and behavioural consistency. Risk-based authentication already collects signals such as device history and location, but those signals only work if they gate the right action at the right moment.

Practical implication: Treat login as an input to decisioning, not the decision itself, and bind approval to the requested action.

Why bot detection breaks down with authorised agents

Bot controls were built to separate automated abuse from legitimate human activity, but agentic commerce blurs that line. An AI agent may wait in a queue, complete a purchase, or submit a payment on behalf of a user while behaving much like the abusive automation the control was meant to stop. The technical failure is not just classification error. It is that the system lacks a reliable way to distinguish authorised delegation from unauthorised automation. Once an agent can act through a valid account, proof of humanity at sign-in becomes a weak control for downstream action.

Practical implication: Add policy and delegation checks to the transaction layer, not just bot screening at the edge.

How KYA turns delegated access into governed identity

Know Your Agent shifts the problem from identity proofing the person to governing the software entity that acts for them. That means the organisation needs to trace the agent’s authority back to a known customer, define its permitted scope, and apply step-up controls when the action exceeds that scope. This is especially relevant in finance, where reading balances, moving funds, and paying vendors are not equivalent risk events. KYA is therefore a delegated-access model, not a new form of authentication. It creates a policy boundary around what the agent may do, when, and under whose authority.

Practical implication: Use delegated-access policies that limit agent scope per session, per action, and per risk tier.

NHI Mgmt Group analysis

Human-versus-bot verification is becoming a brittle control boundary. The article shows why login-time proof alone cannot answer the governance question that now matters most: who or what is authorised to act after authentication succeeds. Once an AI agent can inherit a valid session, the control problem shifts to delegated authority, not identity presentation. Practitioners should treat this as an access governance problem, not a fraud-only problem.

Action-level authorisation is the named concept that will matter most here. The decisive security question is no longer whether a session was created by a human or a bot, but whether a specific action was approved for that actor in that context. That maps directly to identity governance, PAM thinking, and session-bound policy enforcement. Security teams that keep validating presence while ignoring permitted action scope will miss the real abuse path.

KYA is best understood as delegated identity governance for consumer and financial workflows. The article correctly frames agent authority as something that must be traced back to a known user and constrained per session. That is an important extension of existing identity controls because it makes software-mediated action explicit rather than implicit. The practitioner implication is to govern agent authority with the same seriousness previously reserved for privileged human access.

Risk-based authentication remains useful, but it is no longer sufficient on its own. Continuous signals about device, location, and behaviour still help, yet they do not resolve whether an agent should be permitted to move money, buy inventory, or submit instructions. The gap is between trust assessment and delegated execution. Organisations that close that gap early will be better positioned as agentic commerce becomes normalised.

What this signals

Action-level authorisation will become a core identity control for agentic commerce. The industry is moving toward a world where proving that an account holder was present is not enough to justify what happened next. Security and identity teams should expect policy engines to evaluate the requested action itself, not just the login event, especially where software can act with delegated authority.

Session governance will matter more than static trust decisions. If an AI agent can complete routine tasks and then cross into higher-risk activity, the control boundary has to move inside the session. That means practitioners should prepare for per-action approvals, narrower delegation scopes, and better separation between customer identity, human consent, and machine execution.

For practitioners

• Define action-scoped delegation policies Separate read-only, low-risk, and high-risk actions so an AI agent can check balances but cannot move money or approve purchases without added controls.
• Bind approvals to session context Require the approval decision to include device history, location, requested action, and the agent’s declared purpose before permitting execution.
• Add step-up controls for high-impact transactions Trigger human confirmation when an agent requests payments, transfers, address changes, or other irreversible actions that exceed its normal pattern.
• Separate bot abuse controls from agent governance Keep anti-bot friction for abuse suppression, but add a distinct policy layer that governs authorised agent activity inside valid sessions.

Key takeaways

• AI agents make bot or human a weak security question because valid login does not prove valid intent for later actions.
• The more useful control is action-scoped delegation, where each task is approved against the authority granted to the agent.
• Financial and commerce workflows will need step-up controls for high-impact actions even when the session itself looks legitimate.

Key terms

• Agentic Commerce: Agentic commerce is a buying and transaction model where software agents act on behalf of a person. The identity challenge is not just proving who owns the account, but constraining what the agent may do, for how long, and under what revocation and audit rules.
• Resource-Level Authorisation: A control pattern where each application or service decides whether a subject should be allowed to act. The decision is based on identity, context, and policy rather than on network location. This is the practical mechanism that makes zero trust enforceable in real environments.
• Know Your Agent: A governance pattern for verifying that an AI agent is the intended actor, not a hijacked or impersonating one. It extends identity assurance beyond login by focusing on runtime behaviour, delegated authority, and the integrity of the agent's actions across connected systems.
• Step-Up Verification: Step-up verification is a stronger identity check applied when risk increases, such as during password reset, device change, or privileged access request. It uses higher-assurance signals than a static question, such as device possession, authenticated context, or approved administrative review.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to translate identity policy into controls for human, machine, and agentic access.