Security Vibing: Why Cyber Teams Keep Sacrificing to the Risk Gods Instead of Managing Real Risk

Cyber teams sacrifice features and add approvals to feel safer when facing uncertain risks like agentic AI, performing security rituals instead of quantifying actual threats. This security vibes approach provides emotional comfort but bypasses disciplined risk management, leaving organizations with false confidence and no measurable reduction in danger.

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, and a capability gets removed. Another approval step gets inserted into the process, or someone quietly 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, and what happens if it gets manipulated? What data can it see, and 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 SP 800 63B, Digital Identity Guidelines) The practice that was meant to defeat attackers instead trained users to defeat the policy. The same guidance also drops mandatory composition rules such as forced mixtures of upper case, lower case, numbers and symbols, for much the same reason.

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, or 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. Many of those answers can be discovered, inferred or socially engineered in a few minutes of searching. A control designed to defeat attackers has produced a written password and a set of answers a stranger could piece together 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. (Bruce Schneier, The Psychology of 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, or 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, Risk Assessment guidance)

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, AI Agent Security Cheat Sheet)

The difficult bit is not finding controls. The difficult bit is understanding the system well enough to know which controls matter.

None of this means security teams should wait for perfect understanding before acting. Sometimes the right call is to restrict something before you have completed the analysis. If you discover an unfamiliar capability with access to production credentials, “leave it enabled until we’ve finished the threat model” is itself poor risk management.

The distinction that matters is between temporary containment and permanent restriction dressed up as risk management. A temporary restriction is perfectly rational when the consequences could be severe and the system is not yet understood. The problem begins when that temporary precaution quietly becomes the permanent control, and nobody ever finishes the analysis that was meant to justify it. “Disable this while we establish whether X can cause Y” is risk management. “Disable this because it feels dangerous” is security vibing.

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, AI Agent Security Cheat Sheet)

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, isolate the execution environment, reduce the tool’s permissions, remove credentials, require approval at a meaningful boundary, monitor the action, and test whether the attack still works. Those are controls connected to a mechanism.

Compare that with: we made passwords expire every quarter. That might be useful, might be completely irrelevant, or might be actively counterproductive. You cannot know until you name the threat.

The same test applies the moment somebody raises a concern about agentic desktop agents doing bad things. Take the time to understand what the agent can actually reach, and you end up somewhere useful: production assets are walled off entirely, the agent only ever touches read only databases, and destructive actions require a human to approve them first. That is real work, and it closes a real gap.

Or you skip that work and reach for the checkbox instead. Disable the Fable model. Switch off some other capability at random. Nobody writes down what risk it solves, because nobody worked that out before disabling it. It just felt safer, so it got turned off.

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 so much competing vendor security software had been loaded onto it, each product a separate sacrifice to the risk gods, that a huge chunk of CPU and memory was consumed instantly on startup. Nobody could tell you what each product actually did or show you a design for how they were meant to work together. 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. (Stanton et al., Security Fatigue)

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 seven questions:

1. What exact undesirable event are we trying to prevent?
2. What attack path leads to it?
3. Where in that path does this control intervene?
4. How much does it reduce likelihood or impact?
5. How will we know whether it worked?
6. What risk or cost does the control itself introduce?
7. What evidence would cause us to remove it?

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.

Questions six and seven matter as much as the first five. Controls are not free, and they rarely get removed once installed, because removing a control feels riskier than adding one, even when nobody can say what it does.

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.