Consumer AI Agents and Customer Accounts: CIAM Controls

Your customers are handing their passwords and live sessions to AI agents that sign in, browse and transact as if they were the customer, and your CIAM stack cannot tell the difference. Browser-based assistants, shopping agents and personal AI tools increasingly operate inside customer accounts at banks, retailers, airlines, utilities and subscription services. Some type the customer's password into the login form; others ride a session the customer started; a few use an API the business offers. Each pattern creates a different mix of fraud, liability and support risk. This guide covers how customer identity (CIAM) teams detect agent sessions, decide what agents may do, replace credential sharing with consented and scoped delegated access, and revoke it cleanly. It is written for CIAM architects, fraud teams and product owners; the human proxy case (carers, attorneys, family members) is covered in Delegated and Proxy Access in CIAM.

Source note: standards and vendor facts on this page are taken from the official documents listed under Standards and references, checked in November 2026. The session classes, journey tiers, implementation plan and checklist are NHI Mgmt Group recommendations. Confirm against the official text before relying on it.

Key takeaways

Credential sharing is the default today. Without a delegated route, agents sign in with the customer's password or session, which is indistinguishable from the customer and defeats your audit trail.
Offer a better door, then narrow the old one. An OAuth-based delegated access route with fine-grained, revocable grants gives agents a legitimate path and makes password-based agent logins an exception you can manage.
Scope by business flow, not by screen. Read-only account views, low-value actions and high-risk actions (payee changes, address changes, large payments) need different grants and different step-up rules.
Keep the customer in the loop for consequential actions. Backchannel approval on the customer's own device separates "the agent asked" from "the customer agreed".
Revocation and visibility are customer features. A connected-agents page with per-agent activity and one-click revoke is the control customers and regulators will ask for.

How consumer agents reach customer accounts

The integration pattern determines what you can see and control. Most businesses face all four at once.

Pattern	How it works	What you can see	Main risk
Credential sharing	Customer gives the agent their username and password (and sometimes OTPs); the agent signs in through the normal login form	A normal login, perhaps from a new device or a cloud IP range	The agent operator holds a full credential; no scope limit; looks like account takeover or like nothing at all
Session riding	Agent runs inside the customer's own browser or a remote browser after the customer signs in	The customer's session, with automated interaction patterns	Every action is attributed to the customer; prompt injection on your pages can steer the agent
Signed agent traffic	Agent operator signs requests with HTTP Message Signatures so you can verify which operator sent them	Verified operator identity, but not which customer authorised what	Operator identity is not customer consent
Delegated API access	Customer authorises the agent through OAuth; the agent calls your API with a scoped, revocable token	Agent client, customer, scopes and every call	Over-broad scopes, weak client vetting, long-lived refresh tokens

The IETF's OAuth 2.0 Security Best Current Practice (RFC 9700) states that the resource owner password credentials grant "MUST NOT be used", because it exposes the user's credentials to the client and works poorly with multi-factor authentication. Credential-sharing agents recreate that pattern outside OAuth. NIST SP 800-63B-4 places responsibility on subscribers not to disclose their secrets, including through credential sharing, and notes there are very few technical controls that detect willful sharing. That is why the practical answer is to offer a delegated route rather than rely on detection alone.

Detecting agent sessions

Detection has two jobs: recognising declared agents so they can be routed to the right policy, and spotting undeclared automation inside customer accounts.

Declared operators: verify signed requests where agent operators use HTTP Message Signatures. The Web Bot Auth work is still at Internet-Draft stage (the architecture draft, last at version -05, has been replaced by draft-meunier-webbotauth-httpsig-protocol as checked on 12 November 2026), so treat details as subject to change. See Web Bot Auth and HTTP Message Signatures for Agents.
Traffic classification: separate verified agents, known crawlers and unknown automation at the edge. See the Bot vs AI Agent Traffic Management Guide; this page assumes that layer exists and focuses on what happens after login.
Login signals: new device and hosting-provider network origins for an established customer, logins that complete faster than a person could type, and OTP entry from a different network than the login.
In-session signals: navigation that skips pages a person would view, form fills without focus or keystroke patterns, high page rates and repeated identical sequences across many accounts from the same operator infrastructure.
Cross-account signals: one device fingerprint or network range touching many customer accounts is either an agent operator or a credential stuffing operation, and both need a decision. See the Account Takeover Prevention Guide.

Do not block on a single signal. Classify the session (customer, declared agent, suspected agent, suspected attacker), then let the policy for that class decide which actions are allowed.

Deciding what agents may do

OWASP API Security Top 10 2023 risk API6 Unrestricted Access to Sensitive Business Flows is the right lens: the harm comes from automated access to flows such as purchasing, reservations and comment posting (OWASP's examples) and, in our view, account changes, not from a single request. Map your customer journeys into tiers and set the agent policy per tier.

Tier	Example actions	Agent via delegated access	Agent via shared credential or session
1. Read	Balances, order status, bookings, usage, statements	Allow with a read scope	Allow; monitor rate
2. Low-value write	Basket changes, preferences, booking a slot, small purchases to saved payment methods within limits	Allow within per-grant limits	Allow with step-up on unusual patterns
3. High-value or irreversible	Payments above a threshold, cancellations with fees, refunds to new destinations, loyalty point transfers	Require customer approval on their own device for each action	Require step-up the agent cannot complete alone
4. Account control	Password, email, phone, MFA or address changes, adding payees, closing the account	Not grantable to agents	Block or force out-of-band customer confirmation

The tier 4 line protects the recovery channels. If an agent, or someone controlling it, can change the email address or MFA method, the customer loses the ability to take the account back.

Building a delegated access route

A delegated route gives agents a legitimate, scoped and revocable credential and gives you an identity for each agent client separate from the customer.

Client onboarding

Register each agent product as an OAuth client with a named operator, contact, privacy terms and redirect URIs; use confidential clients with strong client authentication where the operator runs the agent server-side.
Tier clients: unverified clients get read scopes only; verified operators with agreed terms may request write scopes. See the OAuth Dynamic Client Registration Security Guide if you allow self-service registration.

Consent and scope

Coarse scopes for reads, rich requests for actions: RFC 9396 OAuth 2.0 Rich Authorization Requests (Standards Track, May 2023) adds an authorization_details parameter, a JSON array whose objects carry a required type and optional fields such as actions, locations, datatypes, identifier and privileges. It can express "up to this amount, at this merchant, from this account". The customer may grant a subset, and the token response returns what was actually granted. See the OAuth Rich Authorization Requests (RAR) Guide.
Plain-language consent: name the agent operator, list what it can see and do, state limits and expiry, and link to the connected-agents page where it can be revoked.
Expiry by default: grants expire (for example 30 or 90 days, set by your risk appetite) unless the customer renews them. RFC 9700 requires refresh tokens for public clients to be sender-constrained or rotated. See the OAuth Refresh Token Rotation and Expiry Guide.

Identifying the actor in every token

RFC 8693 OAuth 2.0 Token Exchange distinguishes impersonation, where the requester is treated as the subject, from delegation, where the actor keeps its own identity and the token names both parties. Its act claim identifies the current actor, with nested claims recording earlier actors in a chain. Issuing delegation tokens with the customer as sub and the agent client in act lets every downstream service log and limit agent actions separately from the customer's own. See the OAuth Token Exchange and Delegation Guide.

Customer approval for consequential actions

OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core 1.0, a Final specification, lets a client that already knows the user start an authentication on a separate authentication device, typically the customer's phone, without redirecting a browser. Its binding_message is shown on both devices so the customer can match the approval to the request, and results are returned by poll, ping or push. RFC 9396 notes that authorization_details can be sent in a backchannel authentication request, so a tier 3 action can show the customer exactly what the agent is asking to do. See the OAuth Step-Up Authentication Challenge Guide and Human-in-the-Loop for AI Agents Guide.

Handling password and session-based agents

A delegated route will not stop all credential sharing at once. Manage the remainder deliberately.

Publish a position: state in customer terms and help pages whether agents may sign in with customer credentials, and which route you support instead.
Classify, do not silently block: suspected-agent sessions get tier 1 and 2 access; tier 3 and 4 actions trigger step-up that requires the customer, such as a push approval or passkey on the customer's device.
Tell the customer: notify on new automated-looking sessions with a link to review and end them, and to set up delegated access instead.
Reauthenticate on risk: NIST SP 800-63B-4 Section 5.2 sets reauthentication requirements; shorten session lifetimes and require reauthentication for sensitive actions in suspected-agent sessions.
Prepare for prompt injection: content you render (reviews, messages, product descriptions) can contain instructions aimed at agents. Keep account-changing actions behind confirmations the agent cannot satisfy alone.

Visibility, revocation and support

Connected agents page: list each agent grant with operator, scopes, limits, created and last used, plus recent actions taken through it, with a revoke button.
Revocation that bites: revoking a grant revokes refresh tokens and invalidates access tokens at the resource servers within a short window; customers should not wait for expiry. See Revoking Delegated Access During an Active Agent Incident.
Support scripts: agents need to know how to check whether a disputed action came from the customer, an agent grant or a suspected-agent session, using the act claim and session class in logs.
Operator-level action: if one agent client misbehaves across many customers, suspend the client, not each grant.

Implementation plan

Measure (weeks 1 to 4): add session classification in logging-only mode and measure how much authenticated traffic looks like agents, by journey.
Tier journeys (weeks 2 to 6): agree the four tiers with fraud, legal and product, and map every account action.
Protect tier 4 first (weeks 4 to 8): enforce out-of-band confirmation for account control changes in all suspected-agent sessions; this reduces account takeover risk whatever the agent policy becomes.
Pilot delegated access (months 2 to 4): read scopes with one or two agent operators, with the connected-agents page and revocation working before launch.
Add actions (months 4 to 6): rich authorisation for tier 2 limits, backchannel customer approval for tier 3.
Tighten (after 6 months): move suspected-agent sessions from monitor to enforce for tier 3, and direct customers to delegated access.
Rollback: keep every enforcement rule behind a feature flag per journey, so a false-positive spike can return a journey to monitor mode without disabling the rest.

Smaller businesses without an API programme can stop at steps 1 to 3: classify sessions, protect account control changes with customer confirmation and publish a clear position on agent access.

Detection and measurement

Log the session class, agent client and act claim with every account action, and alert on tier 3 or 4 attempts from suspected-agent sessions, one client acting across an unusual number of accounts, and grants used from unexpected networks.

Share of agent activity on the delegated route compared with credential and session-based agent sessions.
Account takeover and dispute rate in suspected-agent sessions compared with customer sessions.
Step-up completion rate for tier 3 actions requested by agents (low completion may mean customers did not intend the action).
Median time to revoke from customer request to tokens rejected at the resource server.
Grants past expiry or unused for 90 days, which should be zero after clean-up runs.

Framework mapping

Framework	Reference	Relevance
OWASP API Security Top 10 2023	API6 Unrestricted Access to Sensitive Business Flows	Tiering customer journeys and limiting automated access to them
MITRE ATT&CK	T1078 Valid Accounts; T1110.004 Credential Stuffing; T1539 Steal Web Session Cookie; T1550.001 Application Access Token	Abuse patterns that agent sessions resemble or enable
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement; IA-11 Re-authentication; AC-12 Session Termination	Tier policy, step-up and session limits
NIST SP 800-53 Rev. 5	SI-4 System Monitoring; AU-6 Audit Record Review, Analysis, and Reporting	Session classification and agent activity review
NIST CSF 2.0	PR.AA-03; PR.AA-05; DE.CM-01	Authenticating users and services; least-privilege grants; monitoring
NIST SP 800-63B-4	Section 5 Session management; Section 5.2 Reauthentication	Session lifetimes and reauthentication for sensitive actions

Common failure patterns

Blocking all automation: customers keep using agents through shared credentials from less visible infrastructure, and you lose the signals you had.
Treating operator identity as consent: a verified agent operator signature says who sent the request, not that this customer approved this action.
One broad scope: "account access" grants that include payee or contact changes hand account control to the agent.
Impersonation tokens: tokens that show only the customer make disputes unresolvable and stop per-agent limits.
Grants that never expire: customers forget agents they tried once, and long-lived refresh tokens stay valid.
No customer-facing revoke: customers must call support to remove an agent, so they do not.

Practitioner checklist

Classify authenticated sessions as customer, declared agent, suspected agent or suspected attacker, in monitor mode first.
Map every customer account action to one of four tiers and set agent policy per tier.
Require out-of-band customer confirmation for account control changes in any non-customer session.
Offer an OAuth delegated route with client registration and operator vetting.
Use rich authorisation requests for limited actions and backchannel customer approval for high-value actions.
Issue delegation tokens that name the agent in the act claim and log it with every action.
Set grant expiry and rotate or sender-constrain refresh tokens.
Ship a connected-agents page with activity history and immediate revocation.
Publish your position on agent access in customer terms and help content.

Consumer AI Agents and Customer Accounts: Controlling Agents Acting for Your Users