The Call Is About To Come From Inside The House

You would have to be living under a rock to have missed all the talk about Agentic AI, and how it is going to revolutionize the way we live and work. AI-powered agents will be anything and everything – from personal shopper to travel concierge, executive assistant to inventory manager, medical diagnostician to customer service representative, software developer to security pentester. Article after article is devoted to both the opportunities and the risks. And when it comes to risk, all of us working in the Digital Identity space are not prepared for what is coming.

Photo by Growtika on Unsplash

In the wake of OpenAI releasing Operator, a Computer-Using Agent (CUA), in research preview, I’ve read many breathless posts about the future of Web-based Agentic AI (as opposed to API-based Agentic AI), and how it makes every website “programmable”, even without APIs. If you have worked in software development, you can visualize the mechanics easily – it’s like giving a QA Automation tool like Selenium WebDriver a brain, so that instead of just automating web applications for rinse-and-repeat testing, it can actually read the data, make decisions, adjust course, and take action. That framing should also make it easy to immediately grok how this will break the identity and security infrastructure we currently have, or are putting in place. I mean, we have been dealing with these in our QA Automation projects forever. I thought I’d share the thoughts that immediately jumped to my mind, mostly because I need to not be the only one worrying about these (#MiseryLovesCompany).

1) Bypassing/Breaking/Compromising Authentication Mechanisms

Since CUAs rely on web-based browsing, they necessarily run into some of the same break points that QA automation runs into – like multi factor authentication, bot verification techniques, and more. Any CUA would currently have to give the user back control of the browser to take these actions before proceeding. This high friction point is going to run head first into consumer dissatisfaction and business mandates to “just make it work”, and all of us in identity can guess exactly what will follow:

  • Users will hand over passwords to their Agent service so it can log in as them, or grant them access to their password managers (probably as a feature getting built into first the browser password manager and then the generic password managers).
  • Users will turn off MFA to allow their agents to work.
  • Any guesses on what will happen to passkeys? If syncing of the private key was the worst that you thought could happen….
  • There will people looking at how authorized session hijacking can become a feature to leverage, much like how Selenium allows direct manipulation of cookies and local storage, enabling agents to hoover up valid session tokens and bypass login screens. Case in point: Build MCP servers for any website with automatic browser auth syncing
  • Just like Selenium can sometimes bypass automation (bot) detection protections using headless browsing and user-agent spoofing, expect Agentic AI tools to develop capabilities to do the same.

2) Violating Authorization Boundaries (When They Exist)

QA Automation scripts often execute actions as a high-privilege test user (e.g., an admin account) to avoid breaking tests that are verifying functionality but not data or access restrictions. The rush to deploy Web-based Agentic AI tools will mean that like other tools of the past, it won’t be built with proper scope controls, thereby driving implementors to grant it excessive privileges. You can guess the rest.

As for consumer applications, those rarely have differentiated access control models built in for their users. That means a customer that wants to use a CUA, but limit what it can and cannot do will be out of luck. We saw this play out in the days of screenscraping-based personal finance applications, and how long it took for us to move everyone over to OAuth2 and FAPI as the better and more secure approach.

3) Weakening Security Controls

(aka “Is that a DDoS attack, or an army of Agents here to take advantage of the limited time deal we announced?”)

It won’t just be Authentication controls that are impacted. There are many security protections that will likely be obstacles in the path of Web-based Agentic AI. Would any of us be surprised to find out that IT teams were told to weaken or disable security mechanisms (e.g., Content Security Policy, SameSite cookies, Bot and DDoS detection) to facilitate automated agents, inadvertently creating vulnerabilities?

And these are just what immediately jumped to mind. I am sure there are many more that I’m not even thinking of.

Identity vendors and practitioners everywhere really need to shift into high gear to help organizations properly prepare for what’s headed their way. The demand to support Web-based Agentic AI will put a great deal of pressure on them to enable safe acceptance, and being the “Agent of No” (see what I did there) is not likely to go well. As for what can be done – more on that later.