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

Replacing overly permissive security group rules becomes straightforward when actual traffic data drives the decisions. sg tightener analyzes real network flow logs to identify which specific IP addresses genuinely communicate with your resources, then replaces broad CIDR blocks with precise, evidence based rules that reflect observed behavior rather than assumptions, meaningfully reducing attack surface without disrupting legitimate traffic.

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, and 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, since 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, and 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, and 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 reliably reduce the likelihood of account compromise, and it can push users towards predictable password changes and insecure workarounds without delivering the security benefit organisations assume. 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, and 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, and 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. The villain does not have to be an attacker: it can be a mistake, a failure or an unintended action. An agent can destroy data without anyone attacking it, and badly designed automation can cause real harm on its own, but you still have to name it. 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 SP 800-30, Guide for Conducting Risk Assessments) 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, and 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, but 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, but 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, and 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, and 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, and 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. Security teams fixate on sudo timeouts: how long before we move someone out of sudo. That is a completely benign question. The one that matters is what are you doing with sudo, and that is precisely the question the timeout does not answer. The irrelevant question is easier to manage than the real one, so it gets managed instead. Answering the real question needs proper real time tooling that can inspect what commands are actually being run under sudo and react when something looks wrong. Frustrating developers with ever shorter timeouts just needs a config change.

6. Security vibes have a cost

The problem isn’t merely that pointless controls don’t work. They consume organisational attention, and 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, and otherwise bad controls don’t merely fail to improve security, they can make people less receptive to the good controls.

Not every control is a sacrifice. Some genuinely earn their place, and it is worth showing what that looks like rather than only what it doesn’t. Most enterprise AWS security groups trust an entire corporate /16 because someone assumed the datacenter needed access, years ago, and nobody ever went back to check which of those addresses actually connect. Narrowing that rule properly means reading the VPC flow logs, working out exactly which source addresses genuinely talk to the resource, and replacing the broad range with the tightest CIDR blocks the observed traffic supports. I did that analysis, built it into a tool called sg-tightener, and open sourced it rather than keeping the method to myself. The rule did not get narrowed because narrow sounded safer. It got narrowed because someone did the forensic work to find out what was actually there, and published it so other people could check their own assumptions instead of taking mine on faith.

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, because controls are not free, and they rarely get removed once installed, since removing a control feels riskier than adding one, even when nobody can say what it does.

There is an accountability asymmetry behind that. Adding a restriction is easy to defend: we were being cautious. Removing one requires someone to stand up and say I understand this risk well enough to accept it. The first needs almost no technical judgement. The second needs knowledge, and the willingness to own the outcome, and that is why controls accumulate in large organisations. They have authors, but almost never have undertakers.

Agentic systems genuinely introduce new and important risks, and 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, and 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.