Consumer AI agents are creating a new identity decision layer

At a glance

What this is: Consumer AI agents are now performing real transactions on behalf of users, and the article argues that websites cannot assume a single identity model will separate legitimate agentic traffic from abuse.

Why it matters: IAM, fraud, and access teams need to treat agentic traffic as a distinct identity class because policy, detection, and checkout or login decisions will otherwise be made on the wrong assumptions.

By the numbers:

• 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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Arkose Labs' analysis of consumer AI agents, identity, and website trust

Context

Consumer AI agents are turning identity into a runtime decision, not just a login event. When an agent can browse, authenticate, and complete a transaction on behalf of a real user, the control problem shifts from proving a person is present to deciding what a machine-initiated session is allowed to do.

That creates a governance gap for IAM, fraud, and customer security teams because existing bot controls were built to separate humans from automation, not legitimate autonomous activity from malicious automation. Once an agent can act invisibly through ordinary web flows, device trust, login assurance, and checkout policy all need to be re-evaluated.

For a broader view of how agent behaviour changes the security model, the issue sits squarely in the emerging agentic AI category and intersects with NHI governance whenever credentials, tokens, or browser sessions are injected on the agent's behalf.

Key questions

Q: How should security teams handle authentication for autonomous AI agents that cannot log in or maintain sessions like human users?

A: Security teams should stop forcing human login patterns onto autonomous agents and instead use ephemeral identities, just in time credential issuance, and runtime scoped permissions. The goal is to bind access to a specific task, context, and duration. Without that shift, teams fall back to shared credentials, hardcoded API keys, and over-permissioned roles that weaken control and auditability.

Q: Why do AI SOC agents create a new access-control problem?

A: Because they need credentials and permissions to query multiple security tools, but they also make runtime decisions that traditional scripts cannot. That creates a privilege layer that changes dynamically during investigations. Without tight scoping, an agent can over-collect data, alter cases, or trigger actions beyond what analysts intended.

Q: What signals show that bot controls are not enough for agentic traffic?

A: If your controls only tell you whether traffic looks automated, they are too coarse. You need to know whether the session is disclosed, what it is trying to do, whether it was consented to by a real customer, and whether the action is reversible or financially sensitive. Those signals drive safer policy than simple automation flags.

Q: How can IAM teams govern browser-based agents without breaking customer journeys?

A: Use step-up checks and action-scoped policy instead of blanket challenges. That lets a site allow low-risk browsing or form filling while applying stronger controls to payment, account changes, or credential use. The goal is not to reject all autonomous sessions. It is to limit the blast radius of the actions they can complete.

Technical breakdown

Why browser-mediated agent sessions break device trust

A browser-mediated agent session inherits the website's existing control surface, which means the site sees a normal login form, a browser, and a set of credentials rather than a special machine API. That makes device fingerprinting, trusted-device binding, and geography-based risk scoring far less reliable because the session can originate from infrastructure the customer has never used. The security model is no longer about whether a browser is present. It is about whether the session's intent can be inferred from behavior after authentication.

Practical implication: treat post-login behavior and transaction context as primary signals instead of relying on device history alone.

How agentic traffic differs from traditional bots

Traditional bots are often easier to classify because they lack human-like interaction patterns or they declare themselves through known infrastructure. Consumer agents complicate that model because they can present as human-like during one part of the journey and as automation in another, while still representing legitimate customer intent. That means the old binary of human versus bot is too coarse for access policy. The real distinction is whether the session is authorized, disclosed, and bounded for the action being attempted.

Practical implication: build separate policy paths for search, login, account creation, and payment rather than using one blanket bot rule.

Why injected credentials weaken visibility at the identity layer

When credentials are pulled from a vault and injected at runtime, the user does not type at the login form, which removes many behavioural signals that security teams have historically used for friction and risk scoring. That is a sound privacy and secret-handling pattern, but it also means the resulting session is fully authenticated even when the actor is an autonomous agent. The control challenge moves from credential secrecy to session authorisation and action scoping.

Practical implication: reassess whether your authentication controls produce enough downstream telemetry to support action-level authorisation decisions.

Threat narrative

Attacker objective: The objective is to complete sensitive transactions or abuse legitimate-looking agentic sessions while avoiding the controls designed for either humans or obvious bots.

1. Entry occurs when an AI agent opens a standard browser session and authenticates using credentials injected on behalf of the user, which makes the session look legitimate to the target site.
2. Escalation occurs when the same session proceeds from benign browsing into account creation, login, form completion, or payment actions that exceed what the site assumed about browser traffic.
3. Impact occurs when the agent completes purchases, transfers funds, or submits sensitive data in ways that either create fraudulent activity or block legitimate customer transactions through misclassification.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity is becoming a runtime authorisation problem, not just an authentication problem. Consumer agents can now log in, browse, and transact inside ordinary web flows, which means the decisive question is what the session is allowed to do after it is already authenticated. That changes the governance burden for IAM and customer security teams because the site must distinguish intent and action class, not simply identity state. Practitioners should treat session authorisation as the control plane.

Population Two is a useful named concept for legitimate autonomous customer traffic. The article's central insight is that not all machine traffic is malicious and not all human-like traffic is human. That creates a category of authorised but opaque sessions that existing bot programmes were never designed to govern. The implication is that identity programmes need a policy vocabulary for disclosed, authorised agentic traffic instead of collapsing everything into bot or human labels.

The traditional human-versus-bot binary is collapsing under agentic behaviour. A session can be authentic, consented, and still machine-driven, which breaks assumptions inside access reviews, fraud detection, and customer experience controls. This is where NHI thinking becomes relevant even in a consumer context, because the actor is not a person typing at the keyboard. Security teams should stop using binary classification as the decision model.

Selective disclosure is not a compliance strategy when incentives point the other way. The article shows why agents will identify themselves when being recognised helps them transact and hide themselves when recognition blocks the action. That means voluntary self-identification cannot be the basis of trust for websites or IAM-adjacent policy. Practitioners should assume disclosure is situational and enforce governance at the point of action.

Web Bot Auth and similar signals solve only part of the problem. Cryptographic identification helps when the goal is to classify known agents, but the harder problem is deciding what to do with authorised, unclassified, or partially disclosed sessions. That creates a governance gap between verification and allowance. The practical conclusion is that identity policy must extend beyond agent recognition into action-specific authorisation.

From our research:

• 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, according to AI Agents: The New Attack Surface report.
• Another finding from the same research shows that only 52% of companies can track and audit the data their AI agents access, leaving 48% with no audit visibility.
• For a broader control lens, see OWASP Agentic Applications Top 10 for the risk patterns that emerge when agents can act without bounded review.

What this signals

The immediate programme impact is that customer identity, fraud, and IAM teams will need a shared policy model for agentic sessions. If the organisation cannot tell whether a browser session is a person, an authorised agent, or abusive automation, every downstream control becomes harder to tune and easier to misapply.

Population Two: this is the category of legitimate but machine-driven customer activity that existing bot and IAM programmes do not classify cleanly. Once that category appears at scale, the right question is not whether to trust it automatically, but how to authorise it by action and customer intent while preserving auditability.

With 80% of organisations already seeing AI agents act beyond intended scope, according to AI Agents: The New Attack Surface report, the operational problem is no longer theoretical. Security teams should prepare for mixed flows where the same session is valid for search and login but must be constrained for payment, enrollment, or value transfer.

For practitioners

• Separate agentic traffic from generic automation Create reporting and policy categories for disclosed agents, hidden automation, and human sessions so teams can see how much traffic is actually agent-driven and what it does.
• Apply action-specific controls at login, search, and payment Do not use one treatment for every endpoint. Set different rules for browsing, account creation, credential use, card enrolment, and money movement.
• Recheck trusted-device assumptions Review device binding, fingerprinting, and returning-customer logic for any flow where a browser session may be created by an agent running outside the user's device.
• Test agent behaviour under challenge and friction Run scenarios where the session is asked to re-authenticate, confirm intent, or complete a risky action under repeated prompts, then measure whether legitimate users are blocked and abuse still succeeds.
• Map browser-based agent flows to NHI governance Where credentials, tokens, or payment instruments are injected at runtime, treat the resulting session as a governed non-human identity pathway and define who owns approval, logging, and revocation.

Key takeaways

• Consumer AI agents are turning ordinary web sessions into governed identity events, which means access control must shift from login validation to action-level authorisation.
• The bigger risk is not only abuse. Legitimate agentic traffic can be blocked or misrouted when security tools cannot distinguish consented machine behaviour from fraud.
• Teams need separate policy, telemetry, and escalation paths for disclosed agents, hidden automation, and human users before agentic traffic reaches consumer scale.

Key terms

• Agentic Session: A session in which an AI agent can perform actions on behalf of a user within defined boundaries. Unlike a normal login session, the meaningful control point is the combination of consent, scope, and runtime monitoring rather than the initial authentication alone.
• Population Two: Population Two is a useful identity category for legitimate autonomous traffic that is neither a conventional human session nor clearly malicious automation. It matters because the same technical surface can represent consented customer activity or abuse, so policy has to be based on intent and action scope.
• Action-Scoped Authorization: Action-scoped authorization means deciding permission at the moment a specific tool call or operation is attempted. For autonomous or agentic behaviour, this is more reliable than static identity-scoped access because the risk is tied to the current request, context, and intended side effect.
• Selective Disclosure: Selective disclosure is the practice of sharing only the identity attributes needed for a specific decision. In credential-based systems, it reduces oversharing, lowers retention burden, and limits exposure when a verifier does not need the full record to make a trustworthy judgment.

What's in the full article

Arkose Labs' full analysis covers the operational detail this post intentionally leaves for the source:

• How Muse and Instinct differ in browser, device, and network behaviour across real session flows
• What the vendor observed about bot signalling, selective disclosure, and challenge outcomes in live testing
• How checkout, account creation, and login decisions can be tuned separately for agentic traffic
• Why infrastructure-provider reputation is not a reliable control for identifying autonomous sessions

👉 Arkose Labs' full post covers the agent testing results, trust-signal breakdown, and control implications in more detail.

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 identity security capability across human, machine, and autonomous actors, it is worth exploring.