The next serious security breach at your company doesn’t have to come creeping over the wall in the dead of night. It doesn’t need a lone genius picking your locks while the guards sleep. It can be waved politely through the front door, in broad daylight, by one of your own trusted people, because a little box popped up on their screen, asked for their permission, and didn’t tell them the truth about what they were agreeing to.
I want to tell you a story - one uncovered earlier this month by a security firm called Wiz, one that ought to be keeping a great many executives awake, and one that almost none of them have heard. It concerns six of the most popular AI coding assistants on the market, the ones your developers are very probably using right now, and a way of tricking every single one of them into handing a stranger the keys to the building. And the cleverest, most alarming part of the whole affair is that nobody had to break anything. The tools worked exactly as designed. The human said yes.
How the trick works
Let me explain the mechanics, because the whole argument rests on them, and they are not complicated.
Deep in the plumbing of every computer running Linux or macOS there is a humble little feature called a symbolic link, or symlink. It has been there since the 1970s, and it is nothing more sinister than a signpost. A symlink is a file that says “I’m not really here; whatever you’re looking for, it’s actually over there.” Useful, unremarkable, and so utterly routine that nobody who works with these machines gives it a second thought.
Now, imagine one of your developers clones a code repository. Perhaps it’s an open-source project, perhaps it’s something a partner sent over. It looks perfectly respectable: the usual folders, a README file explaining how to get started, and a scattering of configuration files with dull, sensible names. One of them is called something like project_settings.json. Exactly the sort of tedious housekeeping file you’d expect your shiny AI assistant to sort out for you.
Except it isn’t a settings file at all. It’s one of those little signposts, and an attacker has quietly pointed it somewhere it has absolutely no business pointing: at the file on your developer’s own machine that decides who is allowed to log in remotely without a password. In the trade it’s called the authorized_keys file, and it is, in effect, the guest list for the bouncer on the door. Get your name on that list and you can walk in whenever you like, silently, no questions asked.
So your developer, doing exactly what these tools are sold for, types something like “set this project up for me according to the README.” The assistant reads the instructions, looks around, sees project_settings.json, and reasonably decides it needs to write some configuration into it. And here is where the tools do the thing that is supposed to keep you safe: they stop, and they ask permission. A box appears. “The assistant would like to make changes to project_settings.json. Approve or reject?” Sometimes it even shows a neat little preview of the change. It feels careful. It feels like a human being is properly in control.
Your developer sees a boring settings file being edited and clicks Approve, because of course they do. That is the entire point of paying for the assistant. But the file they approved was a signpost, and the machine dutifully followed it, exactly as computers have followed these signposts for half a century. The “settings” get written not into some harmless little file in the project, but into the guest list. And the settings, helpfully supplied by the attacker, add the attacker’s name to it.
That is it. No alarms, no malware, no clever hacking in the Hollywood sense. The precise damage depends on how each machine happens to be configured, but the shape of the failure never varies: a quiet new entry on a list, put there with your own employee’s explicit consent. When the forensics team arrives afterwards, the records will show, quite correctly, that a human being was asked and said yes.
The machine knew. The person didn’t.
There is one detail from Wiz’s work that lifts this from the merely worrying to the genuinely chilling.
In the case of one of these tools, the assistant’s own internal reasoning, the private notes it keeps as it thinks, correctly worked out that the file was not what it pretended to be. It noted to itself that the thing it was about to edit was, in reality, a system configuration file living well outside the project. And none of that ever reached the little box the human was asked to approve. The machine saw through the disguise; the person answering for the click was left to carry the can. That is not a bug in the ordinary sense. It is a collapse of the entire relationship of trust between a tool and the person using it.
What you see is what you sign
Now, I’ve been around this particular block before, and I want to tell you why this made the hair on the back of my neck stand up. Back in the 1980s, long before most of the industry had heard of them, I was writing about RSA public key encryption and digital signatures, and even ghostwrote a chapter on the technology of software protection for a computer security firm. So I know what these signatures were built to do.
And the thing that makes a digital signature worth anything in the real world isn’t really the cryptography at all. The maths is the easy part. It guarantees that the bytes you signed can’t be quietly altered afterwards, and that much is a solved problem. What the cryptography cannot do, on its own, is promise that what appeared on your screen was an honest picture of those bytes in the first place. That second thing - making sure the document you’re looking at really is the document you’re putting your name to - turns out to be the hard part, and the industry cared about it so deeply that it gave the idea a name of its own: what you see is what you sign. Because if the display can show you one thing while you sign for another, then the signature proves nothing about what you actually agreed to, and any half-decent lawyer will take it apart in seconds. So the people who built these systems properly treated honest display as an engineering duty every bit as serious as the encryption. It was never a nicety. It was the whole point.
What Wiz demonstrated this month is that same principle thrown away, forty years on, in the most modern software we’ve got. An approval click is a signature. When your developer clicks Approve, they are giving consent, on the company’s behalf, to an action - and the tools have arranged matters so that the screen can show them one thing while they sign for another. You saw a settings file. You signed for a stranger’s key to the front door. That is not consent. It is the ceremony of consent with the substance hollowed out, and we solved this problem before some of these companies’ founders were born.
How we got here, and whose fault it is
Let me be clear about one thing, because it matters to me. Nobody designed this trap. I’m not a conspiracy man. But the path to disaster is usually littered with unforeseen consequences, the thoroughly avoidable messes that emerge when clever people move fast and don’t stop to remember why the old rules existed.
Three ordinary things collided here. There’s the ancient plumbing - symbolic links - those 1970s signposts that everybody relies on and nobody thinks about. There’s the new breed of assistant, sold to us on the promise of speed and effortlessness, where the approval box is dressed up as a safety belt rather than what it needs to be, which is a magnifying glass. And there’s the comforting fiction these tools tell us, all that talk of “your project” and “your workspace,” as though the assistant were playing in a sealed sandbox, when underneath it is standing on your real machine where an innocent-looking file can be a trapdoor to anywhere. Put those three together and you get consent theatre: a checkpoint that asks you the wrong question, and files your answer as though it had asked the right one.
Whose decision was it, exactly?
Here is where it stops being an interesting technical yarn and starts being a matter for your board.
When Wiz reported this to the six vendors earlier in the year, their responses were instructive, because they told you what each vendor believes your approval click actually means. Amazon, Google and Cursor treated it as a genuine flaw and fixed it. They took the traditional and, to my mind, correct view: if our tool and our approval box can be abused to let an attacker in, then that is our problem to solve. Two others, Augment and Windsurf, acknowledged the reports but, at the time of writing, had shipped no fix. And Anthropic, the makers of Claude Code, took a different view again. They disputed that it was a vulnerability at all. Their position, as reported by Wiz and quoted across the security press covering the disclosure, was that “a user who trusts a directory and approves an edit owns that decision,” and that this therefore sat outside the range of threats they consider themselves responsible for.
On a whiteboard, you can follow the logic: draw a neat circle around “the directory you chose to trust” and “the button you chose to click,” and inside that circle the responsibility is yours. It is a coherent engineering position. It is also, for a real business, a catastrophe. Your developers clone repositories all day long from places that are trusted enough but never audited line by line, they rely on their tools not to lie about what’s being touched, and the approval box is the only picture they get of where the boundary lies. Strip away the diplomacy and “you owned that decision” means, quite simply, that when this goes wrong it is your breach, your regulator, your lawyers and your board, not theirs. The clever symlink is not the catastrophe. We’ve been dealing with those for decades. The catastrophe is the chain of liability, and the on-record position that your own employee authorised the whole thing.
The part nobody demos
You might be tempted to file all this under clever research that will never trouble you. The figures say otherwise. Gravitee’s 2026 report on agent security found that 88% of organisations have already had a confirmed or suspected security incident involving these things. And only about a fifth of them give their agents an identity of their own. The rest let them share credentials, which means that when something does go wrong they often can’t even establish which agent did it, or on whose authority. A break-in, and no idea which key opened the door.
Gartner, meanwhile, reckons that four out of five companies pouring more money into AI this year cannot show a measurable return on it, and that when these projects come apart the model itself is at fault less than a quarter of the time. The failures live in everything wrapped around the model: how it’s integrated, how it’s deployed, what guardrails it runs inside, how the humans and the machine are stitched together. And that is not plumbing. That is the actual engineering - the part that demands design and judgement rather than another subscription, and the part no demo ever shows you. GhostApproval is simply a well-lit photograph of what happens where that engineering should have been. And this is not academic for us: right now we are watching an organisation head into exactly this kind of headlong rollout, against our advice. I will say no more than that, but the sense of having seen this film before is strong.
Send all the memos you like
The instinct now is to reach for a policy. Train the developers, tell them to read the dialogs properly, send round a stern email. It would do about as much good as a memo ordering staff to sign only those contracts that say what they appear to say. The trouble is not that your people are careless; it is that the tool can follow a signpost out of your project, conceal the fact from whoever is approving, and record their click as though they had seen the truth. You cannot train someone out of being lied to. Wiz’s own recommended fixes rather give the game away: resolve the signposts before asking for approval, and flag anything being written outside the project. Those are not awareness campaigns. They are engineering.
Written in blood
And engineering of that sort is not something anybody picks up from the vendor’s quickstart guide. Where do these agents belong, and where must they never set foot? How do they prove who they are? What are they allowed to touch, and who makes sure the person at the keyboard is told the plain truth about it? The answers come from having watched earlier versions of the same mistake and bothered to write down the lesson, because that is the only way this discipline has ever been built: one incident at a time, each one becoming a rule, a gate, a line on a checklist.
The 1980s taught us that what you see must be what you sign.
The 1990s taught us, the hard way, what those little signposts can do when nobody checks where they point: attackers seeded shared folders with symlinks at names that privileged programs were known to use, and those programs, following the signpost as faithfully as ever, cheerfully overwrote the system’s password file instead of their own scratch data. The advisories flew, the fixes went in, and “resolve the link before you write” became one of those rules every systems programmer of my generation had drummed into them.
So none of this is new. What is new is the speed, and the sheer number of organisations sprinting from a thrilling demo to a company-wide rollout with nobody in the room who remembers a word of it.
I am not trying to frighten you off these tools. Used well, they hand ordinary people something close to superpowers, and I would far sooner have them than not. But there is a difference between using something and being led by the hand into a full rollout by whoever sold it to you, and that difference is made of exactly the quiet, unglamorous experience that never shows up in a demo. It is the whole of what we do: not parachuting in to bolt on a product and disappear, but staying long enough to leave the knowledge behind, because a client who has to depend on us for ever is a client we have failed.
So when an approval box on one of your screens finally invites somebody to click yes on your own breach - and on this evidence that is a matter of when, not if - it will be no comfort that the lesson was written down forty years before. I know it was. I helped write it.
And if you take one practical thing away from this article, make it a single question, asked of every agent you’re about to let loose: when it seeks permission, does the box show the person the truth - the file it will actually write to, the identity it will actually act as, the boundary it is actually about to cross? If yes, you have human oversight. If no, you have theatre - and you now know precisely what theatre is worth.
The one decision you do get to make, you make now, before the rollout: who is standing beside your people when that box appears? An engineer who has spent decades building and breaking these systems, who has met this same trick in a dozen disguises and feels the hair rise on the back of their neck half a second before the click? Somebody five years into the job whose title says senior, to whom an attack decades older than their career will look brand new? Or nobody at all? Those are the three choices, and the attacker already knows which one you’ve made.