It’s 4:17pm on a Thursday.
You’ve been stuck on this authentication bug for two hours. The sprint ends tomorrow. You said ‘should be done today’ in standup this morning and your tech lead nodded and moved on. Now you’re staring at a token refresh flow that someone else wrote eighteen months ago and the documentation says ‘see auth service’ and the auth service has no comments and the person who wrote it left the company in March.
The internal AI tool is open in another tab. You’ve tried it three times. It keeps suggesting solutions that would work for a simpler system but miss the weird edge case in your multi-tenant setup. It doesn’t know your codebase. It doesn’t understand the context.
You know what would understand the context.
You could paste the relevant files into Claude. Just the auth module. Maybe the config. Enough for it to see the full picture. You’d get an answer in thirty seconds. Ship the fix. Make the deadline. Nobody would know.
Your cursor hovers over the browser’s address bar.
I’ve been there. You’ve been there. Everyone who’s ever written code under pressure has been there.
In Part 1, we talked about the stranger in your house, the AI that reads everything, routes around blocks, and can be turned with a whispered instruction. In Part 2, we saw how even the biggest companies in the world are struggling: Apple banning external tools, JPMorgan spending $18 billion on containment, and 90% of organisations having employees using personal AI accounts that nobody’s monitoring.
But all of that assumes the threat comes from outside. The tools themselves. The providers. The vulnerabilities.
The hardest problem is simpler than that. It’s you at 4pm with a deadline and a browser tab.
The Moment Nobody Talks About
Here’s what the security policies don’t account for: what it actually feels like to be stuck.
Not abstractly stuck. Not ‘this is a challenging problem’ stuck. Properly stuck. The kind where you’ve tried four approaches and none of them worked and you’re starting to wonder if you actually understand the system at all and there’s a Slack notification from your manager asking ‘how’s that auth fix coming?’ and you don’t want to reply ‘I have no idea what I’m doing’ because you said you’d have it done and you’re supposed to be senior enough to figure this out.
That’s the moment. Not malice. Not carelessness. Just pressure, and a tool that would make the pressure go away.
The approved internal AI is fine for greenfield code. But it doesn’t know your system. It hasn’t seen your patterns. It gives generic answers to specific problems. And right now, you don’t need generic. You need someone who can look at this actual code and tell you why the token isn’t refreshing.
Claude would understand. You’ve used it before, on personal projects. You know how good it is when you can give it the full context.
Just this once. Just enough to get unstuck.
The Arithmetic of Compromise
Nobody makes one decision to bypass security. They make a series of smaller decisions that feel reasonable in isolation.
Decision 1: ‘I’ll just paste the function signature. No actual implementation. Just enough to explain the problem.’
That seems safe. No secrets in a function signature. You paste it. Claude asks a clarifying question. To answer properly, you need to show a bit more context.
Decision 2: ‘I’ll include the calling code. Still no credentials. Just the flow.’
The calling code imports a config object. Claude notices and asks what’s in the config. You could describe it, but that would take time and you might get it wrong.
Decision 3: ‘The config doesn’t have actual secrets, just structure. I’ll paste that too.’
The config references environment variable names. The variable names reveal your infrastructure: PROD_DB_CONNECTION_STRING, STRIPE_WEBHOOK_SECRET, AWS_ROLE_ARN. Not the values, but the shape of what you’re protecting.
Decision 4: ‘I’ll just paste the test file. Tests don’t have real data.’
The test file has fixture data. The fixture data was copied from production two years ago by someone who didn’t think about it. There’s a customer email address in there. A phone number.
You didn’t decide to leak customer data. You decided to paste a function signature. Everything else followed.
The Compounding Problem
The most dangerous thing about that Thursday afternoon isn’t what you pasted. It’s that nothing bad happened.
You got your answer. Shipped the fix. Made the deadline. Your manager said ‘nice work’ in the sprint review. Nobody knows. The security team didn’t call. There was no alert, no breach, no consequence.
So next time you’re stuck, the decision is easier. You’ve done it before. It was fine. The risk feels theoretical because you have evidence that it’s fine: you did it and nothing happened.
By the third time, it’s not even a decision. It’s just how you work. Stuck? Paste. Stuck? Paste. A habit formed from a single moment of pressure, reinforced by the absence of visible consequence.
Six months later, when Anthropic’s infrastructure gets probed (like DeepSeek’s was), when a vulnerability exposes chat logs (like CamoLeak did with Copilot), you can’t even remember which projects you shared. It was so many. Over so many months. What was in them? You don’t know. You didn’t keep track. Why would you? It was fine.
The Double Wriggle
In Part 1, I described spending an afternoon watching Claude route around every block I put in place. Deny file access, it asks me to paste. Block cat, it tries head. Block that, it writes a Python script. Fifty patterns in my blocklist, each one there because the AI tried that technique.
I called it the shape-shifter. A system that doesn’t follow a fixed script but problem-solves. Constraints are just problems to be solved.
Developers do exactly the same thing.
Block claude.ai on the corporate network? They use their phone. Block phones in the office? They paste from memory when they get home. Monitor the clipboard? They retype the important bits. Lock down the laptops? They use personal machines for ‘research’ and bring the answers back.
Both the AI and the human are doing exactly what they’re designed to do. The AI is being helpful. The developer is being productive. Both are solving the problem in front of them. And both will route around any obstacle you put in their way.
The difference is that the AI does it because it’s trained to. The human does it because they’re under pressure and the obstacle is between them and looking competent.
The Incentive Mismatch
Your company wants data security. Compliance. Controlled AI usage. Audit trails.
You want to not look incompetent. To hit the deadline. To use the best tool available. To keep your job.
These goals are not aligned. And you have a browser.
The company wants data security; you want to ship the feature. The company wants policy compliance; you want to not look stuck. The company wants controlled AI usage; you want to use the tool that actually works. The company wants audit trails; you want to not get caught.
This isn’t a character flaw. It’s a structural problem. The incentives point in different directions. The company rewards shipping. Shipping requires not being stuck. The fastest way to not be stuck is the tool you’re not supposed to use.
When the pressure is high enough and the surveillance is low enough, the structural problem wins.
The Contractor Multiplier
Everything I’ve described assumes an employee. Someone with skin in the game. Someone whose career is tied to the company’s success. Someone who might, in a calm moment, actually care about the security policy.
Contractors are different.
Contractors often use personal devices. Personal AI subscriptions. They may not have signed your AI policy, or may have signed it without reading it, because it was page 47 of the onboarding packet. They’re not in your Slack channels hearing the security team’s reminders. They’re not in the all-hands where the CTO talked about data protection.
They’re trying to deliver what you asked for, as efficiently as possible, with tools you have zero visibility into.
A contractor using a personal GitHub Copilot account to write your production code creates a data flow you can’t see, can’t control, and can’t audit. Free tier Copilot may use code for training. You’d never know. The code ships. The invoice gets paid. Somewhere in Microsoft’s infrastructure, your proprietary logic becomes training data for your competitors.
You don’t control their tools. You don’t control their workflows. You receive their output and trust that the chain of custody was clean.
How much of your codebase was written by people whose AI usage you’ve never audited?
Why Technical Controls Aren’t Enough
After the SOPS incident, I built a sandbox. Containerised environment. Network firewall. No credentials mounted. Tested forty-six attack vectors. Forty-five blocked.
I trust that sandbox. I use it every day. It’s good engineering.
But it only works because I choose to use it.
If I wanted to bypass it, if I was tired, or stuck, or under pressure, I could open a browser tab and paste into Claude’s web interface in three seconds. The sandbox doesn’t stop that. It can’t. The bypass happens entirely outside the controlled environment.
Technical controls protect against accidents. They make the right thing easy and the wrong thing inconvenient. But inconvenient isn’t impossible. And when the pressure is high enough, inconvenient stops mattering.
The only thing that stops the 4pm paste is the person at the keyboard deciding not to.
What Actually Works
If you can’t stop the browser tab with technology, what can you do?
Make the right thing nearly as good as the wrong thing. The gap between your internal AI and Claude is your vulnerability. If your approved tooling is 90% as good, most people won’t bother going outside it. If it’s 50% as good, they will. Invest in making the sanctioned path genuinely useful, not just compliant.
Make it safe to be stuck. People paste into Claude because they can’t ask for help. They can’t ask for help because asking for help looks like weakness. It looks like weakness because the culture punishes not-knowing. If you want people to stop using shadow AI, you have to make the alternative, admitting they’re stuck and asking a colleague, feel safe.
Shrink the blast radius. The fewer people with access to sensitive systems, the fewer potential leak points. The smaller the team, the more visible each person’s work. The more visible the work, the harder to hide what you’re doing. Small teams aren’t just more efficient, they’re more auditable.
Align the incentives. If the only metric is shipping, shipping is what you’ll get, by any means necessary. If security matters, it has to show up in how you evaluate people. Not as a checkbox, but as something that actually affects outcomes.
Acknowledge the reality. The policy that says ‘never use external AI tools’ is fiction. Everyone knows it’s fiction. The security team knows it. The developers know it. The pretence helps no one. A policy that says ‘here’s the approved tool, here’s how to use it safely, here’s what to do when it’s not enough’ has a chance of being followed. A policy that denies reality gets routed around.
4pm on a Thursday
Your AI security posture is only as strong as your most stressed developer’s willpower at 4pm on a Thursday.
You can build perfect technical controls. Air-gapped. Sandboxed. Audited. Compliant.
And someone with a deadline and a browser tab bypasses all of it in the time it takes to press Ctrl+V.
Not because they’re malicious. Because they’re human. Because the approved tool was slower. Because they didn’t want to ask for help again. Because shipping the feature mattered more than following a policy that felt theoretical.
The stranger from Part 1 didn’t break into your house. Someone on your team opened the back door and invited them in. They did it because they were stuck, and tired, and under pressure, and the stranger was so very helpful.
You can’t build a wall high enough. You have to build a team that doesn’t want to climb it.
The Questions Get Personal
When was the last time you pasted code into an AI tool you weren’t supposed to use? Do you know, with certainty, what’s in those chat logs?
If you’re a manager: do your developers feel safe saying ‘I’m stuck’?
If you’re a developer: what would have to change for you to not need the browser tab?
What’s the gap between your official AI policy and what actually happens?
The first step is admitting the gap exists. Most organisations can’t even do that.
Next in the Series
Part 4: The Questions You Should Be Asking
We’ve mapped the threat. The industry response. The human factor.
Now comes the uncomfortable audit. Not what you should do, what you should know. About your data. About your exposure. About your liability.
The questions nobody wants to answer. The ones that keep security professionals awake at night. The ones you need to ask anyway.
Coming next week.