A few weeks ago I came across a story that I couldn’t stop thinking about. A small startup called CodeWall built an AI agent, pointed it at McKinsey’s internal AI platform, and had full access to the entire production database in two hours. No credentials. No insider knowledge. Just a domain name and some patience.
Then they did it again to BCG.
McKinsey had 46.5 million chat messages exposed — strategy discussions, M&A activity, client financials, all stored in plaintext. BCG had 3.17 trillion rows of workforce and compensation data sitting behind zero authentication. Both firms patched within 48 hours once they were told. But the damage was already possible.
The vulnerability in both cases? Not some exotic zero-day exploit. SQL injection — an attack that’s been on the OWASP Top 10 most critical security risks list since 2003. The fix is well-known, cheap to implement, and taught in every introductory security course.
So Why Did It Happen?
Both firms were building fast. McKinsey launched its Lilli platform in 2023 and had 70%+ adoption within two years. BCG’s GAMMA division was shipping AI-powered analytics tools for M&A due diligence and workforce intelligence. These are complex, high-stakes applications — built at startup speed inside firms that historically governed technology like knowledge shops, not software companies.
This is the vibe coding problem. Andrej Karpathy coined the term in 2025 to describe building software by describing what you want to an AI and iterating on the output — without deeply understanding the code it writes. The AI produces something that works. But “it works” is not the same as “it’s secure.”
At McKinsey, the AI correctly parameterized query values — but concatenated JSON field names directly into SQL. The code looked safe. It passed their internal scanners. It wasn’t caught for over two years. At BCG, an internal analyst tool built for internal use ended up on the public internet with its authentication layer simply missing.
Neither of these is a sophisticated failure. Both are the kind of thing that gets caught in a basic security review — if anyone does one before launch.
Why This Matters for Finance and Accounting Teams
I see two direct issues for accountants and finance professionals here.
The first is client data liability. Both firms were storing sensitive client information in systems that turned out to be open to anyone. If your team builds or deploys an AI tool that processes client data, your firm owns the liability — regardless of whether a human or an AI wrote the code. “We used AI to build it quickly” is not a defense under professional standards, data protection law, or client engagement agreements.
The second is IT general controls. AICPA guidance, SOC 2 frameworks, and standard ITGCs all require that new systems go through change management and access control review before production deployment. An AI-built internal tool that skips this process creates audit exposure and compliance risk — even if it’s “just an internal tool for the team.”
The Threat Is Automated Now
Here’s the part that changes the calculus for every firm regardless of size. CodeWall’s agent autonomously selected McKinsey as a target, mapped the attack surface, found the vulnerability, and had full database access in two hours — with no human in the loop. These tools scan at scale. It doesn’t matter if you’re a small regional firm or a Big 4. Every company with an exposed endpoint is a potential target.
The window between “we deployed it” and “someone found the flaw” is now measured in hours, not months.
5 Things Every Manager Needs to Know
- AI writes code that looks right but may not be safe. Functional is not the same as secure. Someone with security judgment needs to review AI-generated code before it touches real data.
- Shipping fast creates a new kind of risk. When you can build something in a week, there’s no time for anyone to raise a flag. If you don’t have a process for that, you’re creating exposure.
- Client and employee data in an AI tool is still your responsibility. Who or what built it doesn’t change your liability.
- Ask one question before anything goes live: who reviewed it for security? You don’t need to be technical to ask this. If no one can answer it, the tool isn’t ready.
- The threat is automated. Attackers are using AI agents that scan continuously at machine speed. No company is too small to be found.
The pace of AI development isn’t slowing down. McKinsey and BCG aren’t cautionary tales about reckless companies — they’re cautionary tales about what happens when even the most sophisticated organizations move fast and skip the security review step. The fix isn’t to stop building. It’s to make “who reviewed this for security?” a standard part of how your team ships.
Want the CPE credit? Take the full lesson on EverydayCPE and earn 0.2 CPE credits: [lesson link]
Leave a Reply