Anyone inside your organisation can now drop your production database. Even your intern can grant themselves super-admin privileges and your QA can run a maintenance script that locks your backend for hours. None of them had to learn how. None of them need to know what they just did. They asked Claude to help them get something done, and it did it for them.
If this surprises you, the surprise is the problem. If it doesn’t surprise you, the next question is whether your systems are structured for a world where it’s true.
The specific trigger.
I raised a security ticket recently. The content was run of the mill — our internal privilege grant and revoke flow had no super-admin tier. Anyone with grant permission could grant anything to anyone, including themselves. The UI didn’t allow it, but API calls to whitelisted users was wide open. Classic missing control, textbook finding, the sort of thing a security auditor would mark with a mild tut.
Why had it been that way? Because when the system was designed and built, the people with grant permission were senior engineers who understood privilege boundaries. The missing tier wasn’t a mistake; it was a reflection of who was expected to use the system. Grant permission was itself a credential — if you could use it, you knew what you were doing.
That assumption used to be safe but it isn’t now. Writing the ticket solidified my suspicion that the whole security model of my company — and probably yours — rests on assumptions that have quietly stopped being true.
One week ago, the world lost $6.3 billion through a single laptop.
Binance was hit for $6.3 billion at the end of October — the largest cryptocurrency heist on record. The FBI has pointed the finger at TraderTraitor, a North Korean group inside the Lazarus infrastructure. The exchange’s own initial statement said the attackers reached a service container through a compromised DevOps engineer’s laptop and submitted unauthorised withdrawal transactions. The CEO later clarified that the full attack was more sophisticated than any single laptop’s permissions — but the laptop was the way in.
Think about what that means. One endpoint — a device sitting on one engineer’s desk, assumed trustworthy because the engineer was trustworthy — had a reachable surface area measured in billions of dollars. The laptop was not the attack. The laptop was the key to a system whose access model assumed the person at the keyboard was the person it was issued to.
That’s an external-attacker story. The internal version is already running in your company. The Binance attackers had to compromise a laptop and move through infrastructure to get where they were going. Your junior developer with Claude already has the laptop. They already have the credentials. They don’t need to move through anything. They just need to describe what they’re trying to do and let Claude find the way.
The structural claim.
Does anyone reading this remember the original Sage Accounts with a default admin password of “letmein” (published in the manual) that needed to be deleted to stop any Tom, Dick or Harry accessing their accounts? Welcome to the updated version that now has Claude and doesn’t even need you to know “letmein”!
The old security model inside every company I’ve worked at had an unspoken rule: destructive capability correlates with skill. You could trust the DevOps engineer with the production database because getting into the production database required knowing how not to break it. You could trust a senior engineer with maintenance scripts because writing a maintenance script was itself a competence filter. You could trust someone with grant permission because they understood what granting a permission meant.
This correlation was never a conscious policy. It was emergent. Access was gated by skill because skill was the price of admission. People who shouldn’t have access couldn’t have access, because the systems required knowledge they didn’t have. Each person did their isolated job and was trusted.
Claude dissolves the correlation. The gate is still there — the system still requires knowledge to use — but Claude supplies the knowledge on demand to anyone who asks. The business analyst doesn’t need to learn SQL to drop a table; they need to describe what they want and Claude conjures the magic. The intern doesn’t need to understand the privilege model to escalate; they need to ask Claude how admin roles work. QA doesn’t need to know what the maintenance script does; they need to tell Claude the symptom they’re trying to fix.
The skill filter was holding the door closed. Claude is a key that everyone now has. And in agentic setups — Claude Code, agents with terminal access, anything where the model doesn’t just suggest the command but runs it — the gap between “showed me how” and “did it” has disappeared.
Three places this shows up, if you want to look.
The database. Historically read-only unless you were a backend engineer. Now, anyone who can access the credentials in a shared vault — or who the credentials have been casually shared with — can run anything Claude writes for them. Including things Claude writes without a safety belt. If someone asks Claude to clean up test data in production, Claude will try to help. It will succeed, in the sense that the SQL will execute.
Maintenance scripts and admin tooling. Previously used by one or two people who built them and understood their blast radius. Now accessible to anyone who notices a problem, asks Claude how to fix it, and gets pointed at the script. The script runs but the side effects would have been documented in a wiki that nobody reads anymore. And, the script is probably accessible to Claude and can, therefore, be reverse engineered.
Privilege and access management. This is where my ticket lives. The assumption that whoever controls access understands access is now wrong. Someone unknowingly granting themselves admin because they need to do a thing is not malicious. They just asked Claude how to get past the permission error and did what it recommended.
The uncomfortable part in all three cases is that the person causing damage is not malicious. The threat model inside most companies was built around bad actors — the engineer who gets fired and does something petty, the contractor who shouldn’t have had access, the external attacker who got in. Those threats are still real. But the new threat is your most helpful employee, asking Claude to help them do their job faster, succeeding, and leaving a crater you have to spend a weekend repairing.
The structural response.
I’m not going to pretend I have this fully solved. I’ve been thinking about it for a while now and will continue to do so for a long time to come. But three things seem necessary.
A super-admin tier for every destructive operation. Not because super-admins are more trustworthy, but because the act of needing to request escalation reintroduces the pause that typing used to provide. The friction isn’t the point. The reflection the friction forces is the point.
Audit trails that know about agents. Logging that someone ran a DROP TABLE is useful. Logging that they ran it via Claude, with the prompt they used, is much more useful. The prompt is the intent. The query is the execution. If your audit trail only captures the execution, you’re missing half the story — including the half that tells you whether the damage was deliberate or Claude helpfully offering to clean up test data that wasn’t test data.
A different model of who gets which credentials. The shared vault that worked when there were three engineers and all three understood every system in it does not work when there are now numerous Claudes all working for whomever is typing instructions. Credentials need to be issued on demand, time-boxed, scoped to what the person actually needs for the next hour. This is boring and expensive and the right thing to do.
The uncomfortable corollary.
The most dangerous person in your company is not your worst employee. It’s your best one — the CEO who just learned they can get things done without waiting for the backend team, the analyst who’s tired of asking engineers for data pulls, the PM who’s figured out that Claude will write the migration script if you just describe what you need. They are helping. They are enthusiastic. They are faster than they’ve ever been.
They are also the people most likely to cause the kind of damage that used to require either malice or a decade of career experience. And they will not know what they did until it is too late.
Recently I wrote about AI removing the friction of typing. This piece is the companion. AI has also removed the friction of skill — the invisible, implicit, assumed friction that kept your access model honest when nobody was looking.
The typing was free. The access was free. Neither of those is cheap. Somebody has to decide what the new gates look like, and quickly, because the old ones are already open.