Security Vibing: Why Cyber Teams Keep Sacrificing to the Risk Gods Instead of Managing Real Risk
Cyber teams sacrifice features to risk gods because disabling a checkbox provides immediate psychological relief from uncertainty. Real risk management requires understanding the system's architecture, permissions, and attack paths to identify controls that actually break a specific threat chain. That analytical work is harder, so rituals persist.
Something interesting happens inside large organisations when a new technology appears and nobody is quite sure how dangerous it is.
People start sacrificing things.
A feature gets disabled. A setting gets locked down. A capability gets removed. Another approval step gets inserted into the process. Someone updates a policy. Everyone feels slightly safer, and nobody can really explain why.
Welcome to security vibes.
1. The ritual
This is particularly visible with agentic AI.
Give an AI system the ability to read files, write code, execute commands, browse information or interact with other systems and, quite reasonably, security people start asking questions. What can this thing do? What happens if it gets manipulated? What data can it see? What credentials can it reach? What happens if it makes a mistake, or if somebody deliberately gets it to do something malicious?
These are excellent questions. Unfortunately, answering them is hard. It requires understanding the architecture, tracing permissions, identifying trust boundaries, thinking through attack paths and deciding what consequences actually matter.
Turning off a checkbox is much easier. So the checkbox gets turned off, and somewhere in a risk register, somebody gets to write:
Mitigation implemented.
The gods have received their goat.
2. Mandatory password rotation is a useful example
Plenty of organisations still force users to change their password every 30, 60 or 90 days, layered with complexity rules demanding a mix of upper case, lower case, numbers and symbols.
There are perfectly legitimate reasons to have some password policy. Weak, default or reused credentials are a genuine vector for account takeover, and that risk is real.
But imagine the actual concern behind mandatory rotation is something vaguer: “we look more secure if passwords change often.” Forcing a change every quarter doesn’t answer that question. The interesting security properties are elsewhere.
NIST’s own digital identity guidance has moved away from mandating periodic password changes for years now, on the basis that forced rotation tends to push users towards predictable patterns, small incremental tweaks and reused variants, rather than towards genuinely stronger credentials. (NIST Computer Security Resource Center) The practice that was meant to defeat attackers instead trained users to defeat the policy.
And the second order effect is worse than the first. Faced with a new password every quarter that they cannot possibly remember, people write it down. On a sticky note under the keyboard. In a phone notes app. In an unencrypted spreadsheet called “passwords”. Or they simply get locked out, ring the call centre, and get asked five security questions to prove who they are: mother’s maiden name, first school, favourite pet, place of birth, first car. Every one of those answers is sitting in public view on social media, or obtainable with a few minutes of searching. A control designed to defeat attackers has produced a written password and a set of answers a stranger could recite from a LinkedIn profile.
What actually reduces account takeover risk sits elsewhere. Is multi factor authentication enforced? Are breached credentials checked against known leaked password lists? Is there monitoring for anomalous login behaviour? Are default and shared credentials eliminated? Is there a fast, low friction path to reset a password the moment compromise is suspected?
Those are much closer to the actual risk surface. But they take more work to design than a rotation policy that can be switched on in an identity management console in an afternoon.
So enforcing rotation might satisfy an auditor’s checklist. It does not magically reduce the likelihood of account compromise, and it can quietly make things worse by pushing users towards weaker, more predictable passwords. That distinction matters.
3. Security and the feeling of security are not the same thing
Bruce Schneier made essentially this observation years ago in his work on the psychology of security. There is the reality of being secure, and there is the feeling of being secure. They are related, but they can diverge dramatically. People can feel safe while being exposed to significant risk, or feel unsafe when the actual risk is comparatively small. (Schneier on Security)
Large organisations are made of people, so organisations develop the same pathology. Something new appears, people feel uncomfortable, an action is demanded, and a visible restriction produces relief.
That psychological relief can very easily be mistaken for risk reduction. This is how we get controls whose most important property is not that they interrupt an attack, but that they demonstrate that something was done.
4. A control needs a villain
There is a surprisingly simple test for this. For every security control, ask: what bad thing does this stop?
Not “what sounds safer?” Not “what did another bank disable?” Not “what will make the governance committee comfortable?” And definitely not “what can we switch off before Friday?”
Describe the bad event. An attacker obtains X. A malicious document convinces the agent to do Y. The agent can access credential Z. A compromised dependency can execute A. Sensitive information can leave through B.
Then explain precisely how your proposed control breaks that chain.
This isn’t some radical new approach to security. It is basically risk assessment. NIST’s guidance describes risk assessment in terms of identifying threats, vulnerabilities and consequences so that organisations can make informed decisions about how to respond to risk. (NIST Computer Security Resource Center)
And the emerging guidance for agentic AI is heading in exactly the same direction. OWASP’s Agentic Security Initiative explicitly describes its work as a threat model based approach to agent risks and mitigations. (OWASP Gen AI Security Project)
The difficult bit is not finding controls. The difficult bit is understanding the system well enough to know which controls matter.
5. Agents make this problem worse
Traditional software makes this kind of fuzzy thinking relatively easy to hide. Agentic software makes it dangerous.
An AI coding agent is interesting precisely because it can perform sequences of actions. It reads something, reasons about it, chooses a tool, takes an action, observes the result, and then does something else.
The risk therefore rarely lives in a single feature. It lives in the combination of inputs, permissions, tools, credentials, network access and autonomy. OWASP’s current material on AI agents highlights risks including prompt injection, tool abuse, privilege escalation and data exfiltration. (OWASP Cheat Sheet Series)
That is where the useful security conversation starts. For example: untrusted content reaches the agent, the content manipulates its instructions, the agent has access to a powerful tool, the tool has unnecessary privileges, and the agent performs an unwanted action.
Now we have something we can work with. We can restrict the input. We can isolate the execution environment. We can reduce the tool’s permissions. We can remove credentials. We can require approval at a meaningful boundary. We can monitor the action. We can test whether the attack still works.
Those are controls connected to a mechanism.
Compare that with: we made passwords expire every quarter. Maybe useful. Maybe completely irrelevant, or actively counterproductive. You cannot know until you name the threat.
6. Security vibes have a cost
The problem isn’t merely that pointless controls don’t work. They consume organisational attention. Every restriction has a cost: engineering effort, user friction, support tickets, exceptions, slower workflows and eventually pressure to route around the controls.
I once worked somewhere that made this concrete. A MacBook Pro was barely usable because the cyber vibe team had loaded so much competing vendor software onto it that a huge chunk of CPU and memory was consumed instantly on startup. Nobody could tell you what each product actually did. Nobody could show you a design. Nothing was ever decommissioned or rationalised, because doing so carried “risk” and fell foul of “reg”. Which risks. Which regs. Nobody knew.
There is research behind that effect too. NIST researchers studying “security fatigue” found resignation, loss of control and decision avoidance among users overwhelmed by security decisions. (NIST Computer Security Resource Center)
Security friction therefore isn’t free. If we’re going to make thousands of employees jump through a hoop, that hoop should be doing something useful. Otherwise bad controls don’t merely fail to improve security. They can make people less receptive to the good controls.
7. The risk god test
Before approving a security restriction, try five questions:
- What exact undesirable event are we trying to prevent?
- What attack path leads to it?
- Where in that path does this control intervene?
- How much does it reduce likelihood or impact?
- How will we know whether it worked?
If nobody can answer those questions, don’t immediately implement the control. You may be looking at a sacrifice to the risk gods, and the arrival of AI agents means we are going to see a lot more of them.
Agentic systems genuinely introduce new and important risks. We should take those risks seriously enough to understand them. Because disabling random features is not caution. Adding arbitrary friction is not governance. And making software harder to use is not evidence that you’ve made it safer.
Every control should have a villain. If you can’t name the villain, explain the attack and show where your control stops it, you’re probably not managing risk.
You’re managing vibes.