Blocking risky behavior feels decisive, but it breeds the resistance and workarounds it's meant to stop. Here's how calibrated friction governs human risk without the backlash.
Restrictive security policies can make employees doubt the threat they’re meant to contain. That’s the central finding in new research from Duke University’s Aaron Kay and Peter Jin. Across six experiments with more than 2,800 participants, imposed controls provoked resistance, and that resistance led participants to downplay the risk. I co-authored an article with them in Harvard Business Review (HBR) on what the findings mean for security teams. The research is theirs. The framework in this piece is our own application of that research. (Aaron Kay is also a scientific advisor to Nudge Security.)
‍
I see the result of this conundrum in nearly every deployment of our product: the number of AI tools already in use is several times what the security team believed. That gap is created by the realities of modern work, or what we call the Workforce Edge: the place where employees choose, connect, and use the tools that get their jobs done, and where risk decisions get made one at a time. They push it further out of view.
‍
Most modern cyber risk is a human risk problem. That's truer than ever in the age of AI, where the fastest-growing source of exposure isn't a misconfigured firewall or an unpatched server. It's a well-intentioned employee pasting customer data into a chatbot to finish a task faster.
‍
Here's the tension at the heart of it. The entire value proposition of AI is productivity: getting your job done better, faster, with less friction. But every one of those productivity gains carries a risk decision riding shotgun. And right now, the person making that risk decision, your employee, is making it implicitly, in the moment, with no real sense of the tradeoff. The security team, meanwhile, finds out weeks later, if at all.
‍
The instinct is to clamp down. Block the tool. Write the policy. Send the all-hands email warning people not to use unsanctioned AI. It feels decisive. It also tends to make the risk look smaller to the people you're trying to protect, and behavioral science explains why.
‍
In 1966, psychologist Jack Brehm described what he called psychological reactance: when people perceive that a freedom is being threatened or taken away, they're motivated to reassert it. The freedom itself isn't what they crave. It's the loss that's motivating. Tell someone they can't do something, and the forbidden option becomes more attractive, not less. You've felt this yourself. The harder a message pushes ("you must," "you can't," "do this now"), the more you want to push back, even when the underlying advice is sound. Decades of research, summarized in Stephen Rains's 2013 meta-analysis of reactance studies, bear it out: forceful, controlling messaging reliably produces worse outcomes than gentle, autonomy-preserving messaging, and sometimes drives people to do the exact opposite of what you intended.
‍
There's a related and equally important idea. Duke University's Aaron Kay, working with Troy Campbell, documented what they named solution aversion. People don't just resist problems. They resist the solutions attached to problems, and that resistance bleeds backward into denying the problem even exists. The cleanest way to see it: when a proposed fix conflicts with what someone values, they don't grudgingly accept the problem and argue about the fix. They quietly decide the problem was overblown to begin with. The solution is so unappealing that the easiest escape is to stop believing there was anything to solve.
‍
In the HBR article, Kay and Jin's experiments tested this in a security setting. In each, the threat and the requirement stayed the same, and only the way the policy was imposed changed. Participants who read about a firewall that automatically blocked unapproved apps reported more reactance than those who read about an education policy aimed at the same threat, and they were more likely to deny the threat was serious. Mandated cybersecurity training did the same compared with training employees chose to attend. Even inside a fixed mandate, letting people choose the format and timing reduced reactance. Control that feels imposed doesn't just breed workarounds. It changes what employees believe about the risk.
‍
Earlier security research points the same way. Studies of information security policy found that controlling language and invasive monitoring can trigger reactance and the counterproductive behavior the controls were meant to stop, and NIST researchers named the resulting disengagement security fatigue. The throughline is consistent: control that feels imposed produces resistance, not compliance.
‍
So the heavy-handed approach doesn't just fail. It actively breeds the resistance and circumvention it was meant to prevent. You can't lecture your way out of human risk.
‍
If imposed control breeds resistance, the temptation is to give up and just watch. That's also wrong. The real answer is to stop thinking in terms of allow versus block and start thinking in terms of friction: how much resistance you put in front of a risky action, calibrated to how risky that action actually is. Zero friction for the trivial stuff, a hard stop for the genuinely dangerous, and a graduated range in between. Calibrated friction preserves employee autonomy wherever you can afford to, and asserts control only where the risk earns it. There are four responses along that range, from the lightest touch to the heaviest: observe, inform, justify, and escalate. Two more cases sit outside the range entirely, and we'll come to those. The spectrum is ours. The experiments explain why imposed control provokes resistance, but they didn't test these responses.
‍
‍
At the lightest end, you don't intervene at all. You simply see the behavior. An employee signs up for a new AI writing assistant with their work email: no OAuth grant, no sensitive scopes, just an account. You don't intervene. You record it, and you analyze it in aggregate. What tools are people actually reaching for? Where are the data flows? Which patterns repeat across teams?
‍
This is the foundation, and most organizations skip it entirely because they can't see shadow AI in the first place. You can't govern what you can't observe. Aggregate visibility turns gut-feel policy into evidence-based policy, and it costs the employee nothing.
‍
The next response intervenes without stopping anyone. When someone takes a risky action, you surface the implications in the moment, and you offer a preferred alternative. Not "access denied." Instead: "Heads up, this tool stores your prompts and trains on them. Here's a sanctioned option that doesn't."
‍
This is what psychologists Gregory Walton and Timothy Wilson call a wise intervention: a brief, precisely targeted prompt that shifts how someone interprets a situation without dictating what they should conclude. Pull the lens back a little and it's also classic nudge theory, the work Richard Thaler and Cass Sunstein popularized in 2008. You're shaping the choice architecture, making the better option easy and visible, while leaving the final call to the person. Crucially, this largely avoids the trigger for reactance. Nobody's freedom is being threatened. You're adding information, not removing options. And the effect isn't hypothetical: in our 2022 research, 78% of participants said they'd respond to a security nudge, against 32% who said they'd comply with a block, and the blocking scenarios were three times more likely to provoke a negative emotional reaction. Participants didn't just feel better about the gentler intervention. They said they'd be more likely to follow it.
‍
The HBR article makes a related recommendation: explain the risks and the reasons behind a policy, and provide approved tools that are actually useful. That alternative has to be genuinely good. Employees often turn to unapproved tools because the approved ones are slower or weaker.
‍
Justification asks more. Before the action proceeds, the employee has to account for it. A quick prompt: "Why do you need to connect this app to customer records?" Then the decision is theirs to make.
‍
This is the most important step in the range, and it's worth understanding why. Left alone, risk decisions happen implicitly. The employee never consciously weighs the tradeoff because they never registered there was one. Asking for justification activates the risk assessment process. It converts an implicit, automatic choice into an explicit, deliberate one. And explicit decisions are better decisions, because the person is actually thinking about the risk instead of sleepwalking past it. You're not stopping them. You're making them the risk assessor, which is exactly where the assessment belongs. This applies the HBR article's recommendation to preserve meaningful choice within security requirements: the organization sets the limits, and the employee keeps agency inside them. One point of precision for anyone reading this from a regulated seat: the employee is deciding within decision rights the organization has already delegated. Which actions sit at justify and which at escalate is itself your delegation map, written by policy in advance, not by the person in the moment.
‍
And before anyone objects that people will just type "business need" and click through: some will, and it doesn't defeat the purpose. The pause is the intervention, not the prose. Every justification also becomes part of a reviewable record that your governance team can sample, audit, and feed back into policy, so even a rubber stamp leaves a fingerprint. The employee who typed "business need" next to a connection into customer records has still made an explicit, attributable decision, and that changes both the psychology and the accountability.
‍
At the heaviest end, the action stops until another human approves it. Let's be clear about what this is: it's a hard block. For the highest-risk actions, the employee cannot proceed on their own, full stop. This is the same enforcement a control-first security team has always relied on, and there's nothing soft about it.
‍
Yet this is exactly where most organizations start today. The block is the frontline, the first and often only tool in the kit, applied to everything from a genuinely dangerous data flow to a marketing intern trying a new transcription app. That's the mistake. The firewall experiment in the research is this mistake in miniature: the same threat, handled with an automatic block, produced more resistance and more denial than an educational response. The hard block belongs at the far end of the range for a reason: it should be the tool of last resort, reserved for the small set of actions whose risk genuinely warrants stopping a person in their tracks. When you lead with it, you pay the full reactance and solution-aversion cost on every decision, including the vast majority that never needed a block at all, and you train your workforce to see security as the department of no before they've encountered a single real threat.
‍
And when a block is warranted, the experience around it still matters enormously. In most organizations, a hard block is a dead end. The action stops, and that's it. There's no clear path forward, no obvious person to ask, often just an anonymous security inbox that may or may not answer. So the employee does the rational thing: they find a workaround. This isn't a fringe behavior. In our 2022 research at Nudge Security debunking the "stupid user" myth, 67% of participants in the blocking scenario said they would look for a workaround to reach the app that had been blocked, and a 2022 Gartner survey found that 69% of employees had bypassed their organization's cybersecurity guidance in the past year. These aren't bad actors. They're people trying to do their jobs, and the dead-end block all but guarantees they'll find another way.
‍
Worse, when an employee works around a block, you don't just fail to stop the action. You lose sight of it completely, and the actions that slip into that blind spot are the high-risk ones you most needed to see.
‍
A strong block does the opposite of dead-ending. It delegates exceptions through a clear, graduated outlet. Some exceptions resolve automatically through policy: low-risk, pre-approved cases that never need a human at all. Some route to a frontline manager who has the context to make the call. And a small few escalate to a centralized governance or security team for the decisions that truly warrant it. One routing rule matters more than the rest: when a decision carries regulatory weight, or the approver's incentives run parallel to the requester's, it goes to an independent risk or security function rather than up the chain of command. Context and conflict tend to arrive together. The employee always has a path forward, and the organization sends each decision to the right level of scrutiny instead of bottlenecking everything in one queue. The fix is to keep the same enforcement but make it human-centric and real-time: the request routes instantly to the right approver, and the answer comes back fast. That speed is a design requirement, not a hope. An approval that takes two days is a dead end with extra steps, and an approver who waves everything through is a control that exists only on paper. The routing has to be real-time, the approver has to own the outcome of what they approve, and the record of who approved what keeps both sides honest. The enforcement is identical to the traditional block. What changes is its placement (reserved for the risks that earn it) and its experience (a routed decision instead of a dead end). A second set of eyes on a consequential choice becomes the easy path rather than the one people route around.
‍
Everything up to this point assumes one thing: that the employee is a rational actor making a real risk decision, and your job is to shape that decision well. But there's a category where that assumption collapses, and it deserves its own place in the model.
‍
Sometimes the employee isn't taking a risk. They're being targeted. Consent phishing is the clearest example: an attacker sends what looks like a routine OAuth request, "this app would like access to your email and files," and the employee clicks approve because it looks exactly like the dozens of legitimate authorizations they've granted before. There's no faulty risk judgment to correct here. The person has been deliberately deceived, and no amount of informing, justifying, or nudging helps, because they don't understand what they're actually agreeing to. Asking them to justify the connection just gets you a confident, wrong answer.
‍
This is where you protect rather than govern. When the signal points to a threat actor rather than a careless-but-well-meaning employee, the calculus flips entirely. You're not balancing productivity against risk anymore, because there's no legitimate productivity on the other side of the scale. You block, you contain, and you do it fast, the same way you'd expect an immune system to act without asking the body's permission first. Preserving autonomy is the whole point of the other four responses. Protecting someone from an attacker is the point of this one. The two aren't in tension; they're answers to different questions. The spectrum governs the risks your people choose to take. Protection handles the ones being inflicted on them.
‍
There's a second half to the immune system analogy, and it's what keeps the protect layer from turning autoimmune. Immune responses fail in two ways: by misidentifying the target, and by acting invisibly, so the damage compounds before anyone notices. The answer to the first is precision. A false positive, a legitimate vendor blocked as an attacker, is a real cost, and the design consequence is simple: the more aggressive the automatic response, the higher the confidence bar it must clear.
‍
The answer to the second is that when you protect, you also inform. The block comes first, at machine speed. The explanation follows immediately: here's what we stopped, here's why it looked like an attack, here's how to tell us if we got it wrong. Act first, explain always, absent a legal restriction on the explanation itself. Something as simple as: "We blocked this authorization request because it matches the pattern of consent phishing. Here's what to check before granting access next time." That single choice turns an invisible save into visible value, because the employee sees the security team working for them, maybe for the first time. It delivers the most convincing security education they'll ever receive: a real attack, aimed at them, explained in the moment it happened. And it gives the inevitable false positive a recovery path measured in minutes rather than a silent dead end that sends someone hunting for a workaround. Notice the move: the inform response just reappeared inside the protect layer. In the governed spectrum, information arrives before the decision, to shape it. In protection, it arrives right after the action, to explain it. Either way, no one is left staring at an unexplained wall.
‍
The reason to name this separately is that conflating the two is how security teams lose the thread. Treat every block like a threat response and you're back to command-and-control, breeding the reactance we started with. Treat a genuine attack like a routine risk decision and you leave your people exposed to adversaries who are counting on exactly that hesitation. Knowing which situation you're in is the skill.
‍
The escalate response above assumes you have discretion, that a block can be requested, reviewed, and sometimes reversed. There's one important case where you don't. When a compliance requirement forbids a specific data type from reaching a specific provider, say regulated health data, payment details, or material non-public information, the block is absolute. You will stop that action. There's no justify-and-proceed path, because the constraint isn't the organization's risk appetite, it's the law.
‍
It would be easy to assume that a mandatory block is the one place psychology stops mattering. The opposite is true. This is the single most important place to engage the user, not the least. A hard stop with no explanation is exactly what sends a determined employee to their personal device to finish the job, and now the regulated data you were legally required to protect is sitting somewhere you can never audit. The stakes of a workaround are never higher than when the blocked action is the one a regulator will ask you about. So the mandatory block is precisely where the psychological support has to be strongest.
‍
That means the block is never silent. Tell the person clearly why the action was stopped and which requirement drives it, so it reads as a rule that applies to everyone rather than a judgment about them. Offer the compliant way to accomplish what they were actually trying to do, because they still have a job to finish. And give them a human to talk to when the rule seems to be blocking legitimate work. The researchers' training experiments suggest a further step. Even when the requirement is fixed, giving people choice in how they meet it reduces reactance. You're not asking permission to enforce the mandate. You're enforcing it in the one way that doesn't quietly push your most sensitive data beyond your line of sight. Refer back to the escalate response and the principle is the same, only sharper: the enforcement is non-negotiable, so the experience around it has to carry the entire burden of keeping the person from routing around you.
‍
Put the four responses together and a different model of security emerges. One where employees keep autonomy over their own productivity, and the security or governance team still gets the controls it needs to keep risk inside the organization's appetite.
‍
This is the resolution to the tension we started with. You don't have to choose between productivity and control. You don't have to pick between letting people use AI and keeping the company safe. By matching your intervention to the risk, observing the low-stakes stuff, informing and nudging in the middle, requiring justification where it counts, and hard-blocking with real-time human approval only at the top, you govern human risk without triggering the reactance and solution aversion that sink the command-and-control approach. This isn't the abandonment of enforcement. The strongest control in the traditional playbook, the block, is still here. We've simply moved it from the frontline to the last resort, where it belongs, and stopped making it a dead end. Most organizations have it exactly backward, reaching for the block first and wondering why their people work around them. Flip the order, and the same control that used to breed resistance becomes the rare, decisive backstop it was always meant to be. If you're making that move, the researchers' findings on lifted bans matter. Participants who saw a restriction lifted were more likely to conclude the original risk was overstated. Explaining that the risk still stood largely closed that gap. So when you replace blanket blocks with calibrated friction, say why, and say what risk remains.
‍
The payoff a control-first team should care about most: when people stop routing around you, you get your visibility back. Every decision that used to vanish onto a personal device now happens in the open, where you can see it, measure it, and act on it. Even the number you report to the board changes: instead of counting how many actions you blocked, you count how many risk decisions happened in view, and which way they're trending. The HBR article also recommends assessing what people believe about the risk, not just whether they comply. Observe covers behavior. A short, periodic pulse on whether people think the threat is serious, and whether they see security as a partner, covers belief. Governing human risk well isn't the soft option. It's the only version that keeps your riskiest activity in view.
‍
Security doesn't have to be the department of no. The research is consistent: control that feels imposed breeds resistance, and resistance erodes belief in the threat. The organizations that get this right won't be the ones with the strictest blocklists. They'll be the ones that make the secure choice the easy, obvious, and freely made one.
‍
That's what securing the Workforce Edge looks like in practice: governing the everyday decisions your people make about apps, AI, and data without fighting them on every one. To see how Nudge Security puts calibrated friction to work, start a free trial.
‍
Brehm, J. W. (1966). A Theory of Psychological Reactance. Academic Press. The founding work on reactance: when people perceive a freedom is threatened, they push back to reassert it.
‍
Campbell, T., & Kay, A. C. (2014). Solution aversion: On the relation between ideology and motivated disbelief. Journal of Personality and Social Psychology, 107(5), 809–824. The original solution-aversion studies, showing that people resist a problem's evidence when they find the proposed solution objectionable.
‍
Thaler, R. H., & Sunstein, C. R. (2008). Nudge: Improving Decisions About Health, Wealth, and Happiness. Yale University Press. The foundational text on choice architecture and nudging, the basis for the inform response.
‍
Walton, G. M., & Wilson, T. D. (2018). Wise interventions: Psychological remedies for social and personal problems. Psychological Review, 125(5), 617–655. A comprehensive review of brief, precisely targeted interventions that shift how people interpret a situation without dictating the conclusion.
‍
Aaron Kay's forthcoming work extends the solution-aversion findings directly into the cybersecurity domain (unpublished; referenced with the author's permission).
‍
Gartner (2023). Gartner Survey Finds 69% of Employees Have Bypassed Their Organization's Cybersecurity Guidance in the Past 12 Months. Survey of 1,310 employees conducted May–June 2022.
‍
Rains, S. A. (2013). The nature of psychological reactance revisited: A meta-analytic review. Human Communication Research, 39(1), 47–73.
‍
Nudge Security (2022). Debunking the "stupid user" myth in security. https://www.nudgesecurity.com/content/debunking-the-stupid-user-myth-in-security. Our research report on how employees' attitudes and emotions predict security compliance: participants were three times more likely to react negatively to blocking than to security nudges, 78% said they would respond to a nudge versus 32% who said they would comply with a block, and 68% in the blocking scenario said they would look for a workaround.
‍
On the security-specific findings referenced in the text: Lowry, P. B., & Moody, G. D. (2015). Proposing the control-reactance compliance model (CRCM) to explain opposing motivations to comply with organisational information security policies. Information Systems Journal, 25(5), 433–463. A scenario study of 320 working professionals showing that the same security policy triggers more reactance and less compliance when communicated in controlling language. Posey, C., Roberts, T. L., Bennett, R. J., & Lowry, P. B. (2011). When computer monitoring backfires: Invasion of privacy and organizational injustice as precursors to computer abuse. Journal of Information System Security, 7(1), 24–47. Stanton, B., Theofanos, M. F., Prettyman, S. S., & Furman, S. (2016). Security fatigue. IT Professional, 18(5), 26–32. The NIST study that named security fatigue and connected it to risky user shortcuts.
