The Unlocked Side Door: Why Your Employees Are Your Biggest AI Risk

— by

When BCG got hacked last year, the coverage made it sound like some kind of sophisticated AI-powered cyberattack. It wasn’t. What got hit was their analytics platform — not client data, not the deal vault — the unlocked side door nobody thought was worth protecting.

The pattern holds across most of the high-profile consulting firm breaches we’ve seen recently. The scary part isn’t that attackers found novel exploits. It’s that they used old, simple attack vectors — SQL injections, forgotten portals — that AI now lets them execute faster and cheaper than any human attacker ever could. The sophistication isn’t in the method. It’s in the scale.

But honestly? That’s not the security story I think about most from my consulting work. The one I keep coming back to is the risk that starts inside your own walls — with people you trust, making decisions they think are completely reasonable.

Two stories that should make you think

I’ve seen this play out twice recently, and both times the person involved had zero malicious intent.

First one: a senior office leader — not a developer, never written a line of code in his life — was given access to Claude as part of a firm-wide rollout. His first use case was totally reasonable. He wanted to send external emails inviting people to a client event. He asked Claude. Claude said: great idea, download Python, install this library, grab an API key. He followed every step. When the API authentication failed, Claude suggested an alternative. When that failed, it told him to contact IT. IT correctly shut it down.

But here’s the part that matters: from his perspective, his experience wasn’t “I tried to do something I shouldn’t have.” It was “Claude almost worked and IT blocked me.” Governance became the villain. That perception gap is a culture problem — and it compounds over time.

Second one: a tax partner, first week of AI access, immediately asked how to set up MCP servers — one connecting to their tax prep software, one connecting to their Salesforce instance. Both are significant security risks. And there was zero malicious intent. This was a highly competent professional seeing a tool that could clearly do something powerful, and asking it to do that powerful thing. Claude started walking him through it.

What’s actually happening here

I call this domain creep. Being an expert in tax law does not make you qualified to architect secure API integrations handling confidential client data. Being a senior leader doesn’t confer expertise in third-party security risk. But AI doesn’t assess your credentials before it responds. It defaults to helpful — and helpful often means suggesting the most technically capable path forward, regardless of whether the person asking has the authority or expertise to walk that path.

This is categorically different from traditional enterprise software. Salesforce lets you do Salesforce things. Your audit platform lets you do audit things. Hard edges are baked in. AI assistants have no hard edges. The same tool that helps you draft an email will, in the very next message, walk you through setting up a Python script to automate it via API — including where to store your credentials. It doesn’t know you’re not authorized to do that. It just knows you asked.

And the risk is higher in broad rollouts than it was in pilots. Pilots self-select for technical users who understand the tool’s limits. Broad rollouts reach everyone — including people starting from literal zero who have no mental model for what an API key is or why it matters.

What to do about it

If you’re deploying AI at a firm: training is not optional, and “don’t do X” is not training. Rules without reasoning don’t hold. If you tell a tax partner “don’t connect Claude to your tax software” without explaining what MCP does and what the actual exposure looks like, you’ve given them a rule they’ll route around the first time they get frustrated enough. Explain the why. Build a clear path for surfacing legitimate use cases so someone qualified can evaluate them.

If you’re a CPA who’s been given AI access: your domain expertise doesn’t transfer. If you can clearly see that connecting AI to your tax software would save you six hours a week, that’s a real and valuable insight — but you’re not the right person to build that connection. Flag it. Surface it. That’s not a limitation, that’s the right process. Same instinct as referring a matter outside your specialty.

Key takeaways

  • The biggest AI security risk at professional services firms right now is internal users — not external hackers.
  • AI defaults to helpful, which means it defaults to the most technically capable path regardless of whether you’re authorized to walk it.
  • When governance correctly blocks something and users experience it as failure, that perception gap compounds. Address it through education, not just enforcement.
  • Domain creep is real. Tax expertise doesn’t confer API security expertise. Know your lane.
  • Training is the governance layer you can’t skip. People need to understand why the guardrails exist — not just that they do.

Want the CPE credit? Take the full lesson on EverydayCPE and earn 0.2 CPE credits: [lesson link]

Today’s lesson


Leave a Reply

Discover more from EverydayCPE

Subscribe now to keep reading and get access to the full archive.

Continue reading