Notifications
Clear all
Topic starter
06/06/2026 11:16 am
TL;DR: Cookie syncing, credential injection, TOTP reuse, and inbox polling can get AI agents past login screens, but they also clone human session assumptions into machine access, according to WorkOS. The stronger pattern is OAuth 2.1 with scoped, time-limited, revocable agent tokens that preserve auditability and enterprise visibility.
NHIMG editorial — based on content published by WorkOS: Logging AI agents into web apps, from cookie hacks to proper OAuth
Questions worth separating out
Q: How should security teams handle AI agents that need to log into SaaS applications?
A: Use delegated authorization rather than cloned human sessions.
Q: Why do cookies and reused second factors fail as agent authentication controls?
A: They authenticate the wrong thing.
Q: How do you know if agent access is actually governed instead of merely enabled?
A: Look for separate grants, bounded scopes, time limits, and logs that distinguish human activity from machine activity.
Practitioner guidance
- Ban cloned human sessions for enterprise agents Disallow cookie syncing and profile copying for production agent access, especially where the application serves multiple users or customers.
- Scope agent access by task, not by user account Define the minimum set of actions an agent needs, then map those actions to explicit OAuth scopes or equivalent grants.
- Make token expiry and revocation visible in operations Track when agent grants expire, where they are used, and who can revoke them.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The cookie-syncing workflow patterns and browser-state mechanics behind cloned sessions
- The password-manager, TOTP, and inbox-based login paths used to get agents through authentication gates
- The OAuth 2.1 and MCP authorization flow details for building scoped agent access
- The session-scoped authorization model for third-party tools such as Snowflake, Google Workspace, and Salesforce
👉 Read WorkOS's analysis of OAuth for AI agent app access →
AI agent app login: what changes when OAuth replaces cookies?
Explore further
06/06/2026 11:57 am
Human session replay is the wrong trust model for agents: Cookie syncing and credential injection work because they inherit a human login pattern into machine execution. That pattern assumes the authenticated subject is the same actor who will decide, inspect, and terminate the session. In practice, an agent can chain actions across systems without that human oversight, which makes the session itself the wrong security boundary. Practitioners should stop treating session replay as a variant of normal identity use and classify it as delegated access without governance.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- That same research found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows how weak the operational baseline remains.
A question worth separating out:
Q: Should organisations let AI agents use the same login flow as employees?
A: Usually no. Human login flows assume interactive decision-making, visible consent, and a person who can notice anomalies. Agents need task-scoped access and clear offboarding. If the same login flow is reused, the organisation usually loses visibility into who or what actually used the session.
👉 Read our full editorial: OAuth for AI agents is replacing cookie hacks in app access
