Customer sessions assume a single human principal with visible intent and reviewable behaviour. When an agent uses that session, the authorisation boundary shifts from a person to software, which can repeat actions faster than review cycles can detect. That creates fraud, overspending, and attribution problems inside the same account.
Why customer sessions become risky when an AI agent uses them
A customer session is designed around a single human principal, a human pace of action, and a reviewable trail of intent. When an AI agent reuses that session, the trust model changes without the session issuer necessarily knowing it. The same authenticated context can now drive high-volume, low-latency actions that look like the customer, even when the behaviour is software-driven.
That shift matters because customer sessions often carry implicit trust: payment approval, profile changes, order placement, data access, and support interactions may all be available inside one live session. Once an agent inherits that context, the boundary between “the customer did this” and “the agent did this on the customer’s behalf” becomes blurred, which creates control, fraud, and attribution problems even before any compromise is proven.
AI agents also change the tempo of the session. A human usually acts in bursts, with pauses that support challenge, review, or cancellation. An agent can repeat actions, chain requests, and explore options much faster than a person would, which means small mistakes can become fast-moving account abuse. The AI Agent Authorisation Guide is useful here because the practical fix is not “more session time”, but narrower, task-scoped authority.
Customer sessions also tend to be fragile from a governance point of view. They were not built to express delegated authority, so organisations often end up treating an agent’s use of a customer session as if it were ordinary end-user activity. That assumption can hide whether an action was user-initiated, agent-initiated, or fully automated, and it weakens the evidence needed for fraud review, dispute handling, and operational containment. For a broader view of how identity and risk change as autonomy rises, see AI Agents vs Agentic AI.
Where the risk shows up in real operations
The first exposure is fraud and misuse inside an otherwise valid session. If the agent can click, submit, buy, transfer, or change settings faster than a customer would, then rate limits and human review windows may not catch the activity in time. The risk is not limited to obvious abuse, it also includes legitimate-looking overuse that exceeds the customer’s real intent or budget.
The second exposure is blast radius. A session that was acceptable for a single human action can become too powerful when an agent chains requests across a checkout flow, support workflow, or account management path. This is why the Zero Trust for AI Agents guidance is relevant: each action should be verified as if it could have impact, not assumed safe because the session was already authenticated.
The third exposure is attribution failure. When a dispute, incident, or anomaly occurs, teams need to know whether the customer, the agent, or another tool initiated the action. Without that separation, investigations become slower and remediation becomes more conservative, because teams cannot reliably distinguish legitimate delegation from misuse. The result is often more friction for customers and less confidence for operators.
Session reuse can also create hidden third-party and consent risk. If the agent reaches out through external services, consent flows, token reuse, or tool integrations, the original customer session may become the launching point for actions that the customer never directly reviewed. The CoPhish OAuth phishing via Copilot Studio example shows how agent-driven workflows can turn a trusted interaction into a token-abuse path.
What practitioners should change before allowing agent use of customer sessions
Start by deciding whether the agent is acting as the customer, alongside the customer, or only with explicit delegated authority. Those are different trust models, and they should not share the same session treatment. If the answer is unclear, the default should be to narrow the agent’s permissions rather than inherit the full customer session.
What to verify: confirm that the action is bounded to a specific task, that the session cannot silently expand into unrelated account functions, and that the system can log which step was initiated by the agent versus the person. If you cannot explain that boundary in an incident review, the session model is too loose.
Decision rule: if a session can move money, change entitlements, or expose customer data, treat it as high-impact even when the login itself is valid. In that case, prefer per-action approval, short-lived authority, and explicit attribution over long-lived reuse. The practical goal is to make each sensitive action independently defensible, not merely authenticated at the start.
What good looks like: the session supports the user experience, but the agent cannot silently inherit broader customer intent. The control is working when automation reduces effort without removing review, attribution, or the ability to stop the flow quickly.
Practitioner takeaway: customer-session reuse is dangerous when it turns a human trust model into machine-speed execution without a new delegation model. If the organisation cannot prove who authorised each sensitive action, the session is being used too broadly.
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 SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent use of customer sessions is an identity and privilege boundary problem. |
| Recommendation — Constrain agent privileges so each sensitive action is separately authorised. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Reusing customer sessions for agents can break the intended authentication boundary. |
| Recommendation — Use distinct delegated credentials instead of letting agents inherit customer sessions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Customer-session risk often comes from weak control over session-bearing credentials and tokens. |
| AC-6 — Least Privilege | Agents should not receive the full power of a human customer session by default. | |
| Recommendation — Manage session credentials with short lifetimes, rotation, and revocation controls. Limit each agent to the minimum access needed for the specific task. | ||
| NIST Zero Trust (SP 800-207) | AC-6 — Least Privilege | Zero trust directly supports per-action verification for delegated agent activity. |
| Recommendation — Verify every sensitive request and remove standing privilege where possible. | ||