CyBehave | Heroes exists because of vibe coding.

Having designed and built security champion programmes over the years, I kept running into the same challenge at various times - no proper platform for building and managing one. Not a spreadsheet with names in it, an actual platform that understood how these networks behave, who the connectors are, where influence sits, what people are capable of and what gets in their way. I knew what it needed to do. I could not have handwritten it in any reasonable timeframe alongside a full-time job and being a doctoral researcher.

So I vibe coded it, initially to answer a narrower question than the one I ended up answering. I wanted to know whether I could build something genuinely working this way, with security and privacy sitting at the centre rather than bolted on once it was too late to change anything. That was the test. If the answer was no, the idea was dead and I would have lost a few weekends.

The answer was yes, and after many more weekends, that platform is now company.

What I noticed while building it was how much of my own background was running underneath the whole process without being asked for. I built security and privacy as fundamental principles, the code was based around zero-trust and I thought about tenant isolation because I have spent years dealing with what happens when nobody did. I asked what was ending up in the logs. None of that is virtue. It is pattern recognition, laid down over a long time, firing unprompted.

John in Sales does not have that. And John is about to build an app.

The polish is the problem

For most of the history of software, how something looked was a reasonably honest signal of how it had been built. Not a perfect signal, but a useful one. Clean interfaces, sensible flows and a considered login screen tended to indicate a team who had thought carefully about their work, and teams who thought carefully usually thought about more than the surface. The correlation was never causal, but it held often enough that all of us learned to read it.

That correlation has now broken, and it broke quietly.

What John produces in an afternoon will look like enterprise software. A proper login page, a dashboard with cards, a settings screen, sensible empty states, a decent typeface. It will look like something that went through design review, security review and a release process, because the model has absorbed what all of that output looks like. What it will not contain is any of the reasoning those processes exist to perform.

So when John shows it to his manager, nobody in that chain has any reason to ask a question. It looks finished. Finished things have been checked. That inference was always slightly lazy, and it is now simply wrong, and none of us have updated the instinct yet.

This is the same failure that shows up when people over-trust model output generally. Fluent, confident, well structured prose used to indicate somebody who knew what they were talking about, because producing it required knowing. Fluency is now free. Polish is now free. We are carrying trust cues that were calibrated for a world where these things were expensive, and applying them to one where they are not.

Nobody else will use it, and that changes nothing

The line I hear most often is that it is only for me.

Usually that is true. Outside a development team, most vibe coded applications really are built by one person for one person, and they stay that way. Sometimes an app spreads, picks up users and quietly becomes a system of record, and that brings its own set of problems. But the single user case is the common one and I want to be careful not to treat it as the safe one, because the reasoning behind that belief is where the actual damage sits.

John thinks that because he is the only user, nothing much is at stake. What is at stake has almost nothing to do with how many people log in.

He has pasted real customer data into it. Named contacts at named companies, deal values, notes about who is unhappy with their current supplier and why. That is personal data about identifiable people and commercially sensitive information about clients, and it is now sitting in an application with no data protection assessment behind it, quite possibly in a hosting account John opened with a personal card, in a jurisdiction nobody chose deliberately, with a database that may or may not be reachable from the open internet and credentials that may or may not be sitting in the repository. There may be no backups. There is almost certainly no retention rule, so it will hold that data until John gets bored of it.

Not one of those exposures requires a second user. The regulator does not ask how many people had accounts. An attacker who finds an open database does not care that it was a personal project. And when John moves to a different role, the data does not leave with him, it just stops having anybody responsible for it.

The audience was never the risk. The data was, and John has been thinking about the wrong variable from the moment he started.

Two different problems that look like one

For development teams, this is an extension of ground we already hold. Secure development practice, threat modelling, code review, dependency management, secrets handling, testing in the pipeline, all of it still applies. Some questions change at the margins, because reviewing code you did not write asks something different of you than reviewing code you did, and because the volume of generated code turns review depth into a genuine resourcing question. But the shape of the answer is familiar and the people involved have the capability to apply it. That work is adaptation.

John is not that problem, and treating him as though he is will fail. He does not need a lighter version of the secure development lifecycle. He will not read it, and if you make him read it he will build the app anyway and not mention it.

Capability, not awareness

Looking at this through the COM-B lens I use for most human risk work, the diagnosis is fairly clear, and it is not a motivation problem.

John has enormous opportunity. The tool sits on his laptop, it costs nothing or nearly nothing, and there is no distance at all between the idea and something running. He has motivation, though it points entirely at speed and at solving the problem in front of him, which is exactly what we have spent a decade telling him to care about. What he lacks is capability, and specifically the capability to know which questions apply to what he is doing. He cannot ask about data residency or retention or access control, because those concepts are not in his head, and enthusiasm will not put them there.

Awareness training does not close a capability gap of that shape. You cannot hand somebody a security architect's instincts in a forty minute module, and most of the people who sit through it will conclude that none of it applied to their little app.

What does work is moving the question earlier and making it answerable by the person actually holding it. John cannot tell you whether his authorisation model is sound. He can tell you three things, if anybody ever asks:

  1. What data is going into this, and would the people it describes be surprised to find it there.

  2. Where does it physically live, and who could reach it if they went looking.

  3. What happens to it when it breaks, and what happens to it when John changes role.

Three questions, all answerable by a salesperson, none of which require John to understand the underlying risk in order to surface it. The third one matters more than people expect. Orphaned applications holding live customer data are one of the more predictable outcomes of all this, and by the time anybody finds them, the person who could explain them left two years ago.

Paved roads beat prohibition

The behavioural evidence here is not ambiguous. Prohibition without a viable alternative produces concealment rather than compliance. Ban it and John still builds the app, he just builds it somewhere you cannot see and says nothing when it goes wrong.

The route that works is a sanctioned path that is genuinely easier than the unsanctioned one. A platform already sitting inside your identity provider, so authentication is not something John has to think about. Templates where the boring protections are present by default and John would have to actively remove them. Environments where data cannot leave your tenancy, so the residency question answers itself. A registration step that takes two minutes and gives John something he actually wants.

Alongside that, an amnesty for what already exists, because it already exists. Making the first act of disclosure a punishment guarantees you only ever hear about the ones that fail publicly.

This is where friction budgeting matters. You get a limited amount of friction to spend before people route around you entirely, and most organisations spend theirs in the wrong place. Spend it at the point where real data first enters an application, not on making John justify a prototype nobody will open twice.

What I actually think

The behavioural debt here is accruing now. Every polished, unregistered application holding real data that got built this quarter is a liability that will surface at some point in the next few years, most likely during a due diligence exercise or a breach investigation, and by then it will be expensive and nobody will remember how it got there.

I am not gloomy about it, because I am living proof of the upside. A company exists because I could take an idea I understood deeply and find out in a few weekends whether it was buildable. That route is now open to people who understand a problem intimately but never learned to code, and they will build things no development team would have thought to build.

The gap we have to close is not technical. It is that we have handed people a set of decisions they do not know they are making. Our job is to make those decisions visible at the moment they occur, and to make the safe version of each one the path of least resistance.

Not to tell John he should have known better. He had no way of knowing better, and that part is on us.