A cybersecurity professional at a Canadian financial institution asks how banks are detecting and blocking third-party AI agents (such as Meta's Muse) from accessing customer accounts, discussing WAF rules, bot management, robots.txt/ai.txt, OAuth DPoP token binding, and application-level controls, and soliciting real-world implementation experiences from the community.
Hey everyone, I work in cybersecurity at a financial institution in Canada, and we've recently started discussing the security implications of third-party AI agents accessing customer-facing banking applications. For context, RBC recently made headlines regarding its decision to block Meta's Muse AI agent from accessing its banking systems due to security, privacy, and liability concerns. This got me wondering how other financial institutions and organizations are approaching this problem from a technical perspective. We're particularly interested in understanding how to identify and potentially restrict unauthorized AI agents that interact with banking applications, especially when those agents may be using legitimate customer credentials or authenticated sessions. Some of the approaches we've been exploring include: - WAF and bot management: Using bot detection rules, behavioral analysis, fingerprinting, and traffic patterns to distinguish automated agents from legitimate customer activity. - robots.txt / ai.txt: Whether crawler restrictions offer any practical value for AI agents, beyond compliant web crawlers. - OAuth DPoP / sender-constrained tokens: Whether token binding offers meaningful protection against AI-driven access, particularly when an agent is operating through an authenticated browser. - Application/API-level controls: Detecting abnormal automated interactions, restricting sensitive operations, or identifying non-human activity beyond the authentication layer. A few questions for anyone who has worked on this: How are organizations actually identifying AI-driven browser automation, especially when it uses legitimate customer sessions? Are existing WAF and bot management solutions effective against modern AI agents, or do they mostly detect traditional crawlers and scripted traffic? Has anyone implemented additional authentication or API-level controls specifically to address third-party AI-agent access? Are organizations primarily relying on technical blocking, monitoring and behavioral detection, or a combination of these with customer usage policies? Are there any emerging standards, frameworks, or real-world implementations worth looking into? I'm particularly interested in hearing about actual implementation experiences, what worked, what didn't, and any limitations encountered. Not looking for vendor pitches or ways to bypass protections. Just trying to understand how the industry is approaching this emerging security challenge. Appreciate any insights!
Canada's major banks — RBC, TD, CIBC, and BMO — announced they will block personal AI agents such as Meta's Muse and OpenAI's ChatGPT from accessing clients' online bank accounts, citing safety and security concerns amid reports of unauthorized third-party AI agent activity in accounts at major U.S. banks.
Major US banks report discovering unauthorized AI agents operating inside customer accounts, typically using the customer's own login credentials, raising concerns that current password-based authentication cannot distinguish between a user and an authorized or rogue agent. The situation prompts debate over whether agents should use their own scoped credentials rather than sharing customer logins.
Consumer AI agents like Meta's Muse and ChatGPT's Dots are hitting a growing obstacle: websites and their anti-bot measures are blocking agents from completing tasks like purchases on users' behalf. In response, companies including Meta, Walmart, Stripe, and Decagon are collaborating on a new open standard for agent-to-business communication in online commerce.
JPMorgan, Citi, Bank of America, and Schwab moved to block external AI agents from accessing customer accounts or moving money, keeping only read-only access via official connectors. The author argues this enforces at the institutional level the approval-gate permission architecture that agent frameworks should build in from the start.