Signals Weekly Briefing

SIGNAL: Week 36 - Humans in the Loop

31 August 2026 · 8 min read · Andy
← All Signals briefings

31 August 2026 · An 8-minute read

The research world handed us a gift this week. SOUPS, the usable security community's annual gathering, met in Hannover just as SANS released its eleventh annual look at the state of security awareness, and together they tell one story from opposite ends. Industry data indicate that AI has become the thing keeping human risk professionals awake at night. The academic work says the oldest questions in our field, how people feel, decide and cope under pressure, matter more than ever, precisely because machines are now in the middle of everything. This week is about keeping humans meaningfully in the loop, in both senses.

AI is now the second biggest human risk we manage, says SANS

The SANS 2026 Security Awareness and Culture Report, published on 27 August, draws on responses from more than 1,700 security awareness practitioners worldwide, making it one of the larger recurring snapshots of our profession. The headline: AI has climbed from fourth place to second among the human risks practitioners worry about, behind only social engineering. Three flavours of concern stand out. Unauthorised use of generative AI tools, amateur "vibe coding" by people who are not developers, and AI agents taking actions nobody reviews.

There is a mirror-image finding too. Three-quarters of awareness teams are themselves using AI to build and run their programmes. And the perennial resourcing story has sharpened into something you can quote: SANS puts the threshold for genuine behaviour change at a minimum of three dedicated staff and three to five years of sustained effort, with lasting culture change needing four or more staff and five to ten years. Most programmes surveyed sit below those staffing levels.

The usual caveat applies. This is a self-report survey of practitioners, so it measures what our profession believes, not what attackers do. That is still valuable, and eleven years of trend data gives it weight.

What does this mean for me? Two things worth acting on. First, if AI use is not yet an explicit topic in your programme (covering tool policy, data handling, and what "reviewed by a human" actually means), the field has now moved past you. Second, the staffing and timescale figures are ready-made benchmarking material for your next budget conversation. Boards respond to independent numbers, and "SANS says culture change takes four people and five years" lands differently than a plea for headcount.

Source: SANS 2026 Security Awareness and Culture Report (practitioner survey, n>1,700). Announcement with key figures here.

Nobody asks the AI for secure code

If you want a concrete picture of what "unreviewed AI output" looks like in practice, a study presented at SOUPS this week delivers it. Researchers ran 15 professional software engineers through realistic coding tasks with an AI assistant, thinking aloud as they worked, and conducted in-depth interviews. The striking result: not one participant included security requirements in their initial prompts, even though the same people spoke fluently about security concerns when interviewed. Security thinking had not disappeared; it had migrated from the moment of creation to the moment of review. The authors call this a shift from preventive to reactive security.

Worse, seniority did not save anyone. Experience level and AI familiarity did not reliably predict who would catch the vulnerabilities the tasks quietly contained, and developers applied roughly the same level of trust to routine code and security-critical code alike. It is a small qualitative sample, fifteen people, so treat it as a rich description of a mechanism rather than a population estimate. But the mechanism rings true well beyond software teams.

What does this mean for me? This is the behavioural anatomy of the "vibe coding" risk SANS flagged, and it generalises to any AI-assisted work: drafting contracts, writing policy, analysing data. The habit to build is specifying your requirements up front (security, confidentiality, accuracy) rather than hoping to spot problems on the way out, because review under time pressure is exactly where human attention fails. If you run secure development training, the prompt is now a teachable moment. Consider adding "what did you ask for?" alongside "what did you check?".

Source: From Preventive to Reactive: How AI Coding Assistants Transform Developers' Security Awareness, peer-reviewed at SOUPS 2026 (qualitative study, n=15).

The NCSC wants a named human minding every AI agent

Ten days ago, the UK's National Cyber Security Centre published blog guidance on managing the cyber risk of agentic AI, and it is, in effect, a human risk document. The NCSC sets out three oversight models (human-in-the-loop approving actions, human-on-the-loop monitoring with the power to intervene, and fully autonomous operation) and advises keeping humans in the loop wherever unintended activity would have significant consequences. The organisational asks are refreshingly specific: assign named individuals responsible for AI activities, treat AI agent activity as a form of user activity in monitoring and incident response, start with office-hours testing before letting agents run overnight, and maintain the ability to shut an agent down immediately.

What does this mean for me? Do not let this guidance live solely with the architecture team. Every one of those recommendations is a human performance question: whether the named individual actually understands what their agent does, whether the person "on the loop" stays vigilant when the agent is right 99 times out of 100, whether anyone rehearses hitting the off switch. Automation complacency is a fifty-year-old finding from aviation psychology, and it is about to become a mainstream security problem. If your organisation is deploying agents, ask who owns the oversight roles and offer to help design them. This is our field's territory.

Source: Managing the cyber risk of agentic AI, NCSC blog, 20 August 2026 (government guidance).

Not clicking felt risky too: the emotional life of a phishing attack

My favourite finding of the week comes from a SOUPS paper with a wonderful title taken from a participant: "I didn't know I would be this excited not to be scammed." Researchers from Aalto University and CISPA observed 41 participants receiving a phishing message during a simulated workday, combining observation, interviews and questionnaires to capture what people actually felt and did in the moment.

Three findings deserve attention. People who did not detect the phish mostly experienced it as an annoying interruption to real work, which is exactly the mental state in which scrutiny collapses. Detection, when it happened, ran on intuition and gut feel far more than on the analytical checklists we teach. And, most tellingly, several participants worried that not responding to the message could appear rude or have reputational consequences. Ignoring an email from an apparent colleague or authority figure felt socially risky. The pull we fight is not only curiosity; it is politeness and professional conscientiousness, some of the very traits we hire for.

What does this mean for me? Give people explicit social permission to pause. A line like "you will never be criticised here for delaying a reply to verify it" costs nothing and directly counters the fear this study surfaced. It also argues for measuring and marketing the emotional side of reporting: celebrate reports, respond warmly to false alarms, and never let a simulation programme shame the conscientious. And since intuition did the heavy lifting, exposure-based practice that trains gut feel (lots of varied examples, fast feedback) may serve better than another rules poster. Small sample, lab-adjacent setting, but the design is careful, and the insight is actionable.

Source: Exploring Emotional and Behavioral Responses During Phishing Attacks, peer-reviewed at SOUPS 2026 (qualitative study, n=41).

Social anxiety cuts both ways in social engineering

Also at SOUPS, a University College London team examined how social anxiety shapes vulnerability to social engineering, using a survey of 42 people to map real-world tactics and then role-playing interviews with 20 participants comparing higher and lower social anxiety. The finding worth sitting with: anxiety is not simply a vulnerability. Some anxiety-linked traits, like heightened caution and a tendency to double-check, protected people against certain attacks, while other attack styles, particularly those applying social pressure, hit anxious participants harder. Which way it cut depended on the tactic.

What does this mean for me? Most susceptibility models in our industry implicitly assume one axis of "risky user". This research says vulnerability is textured: different people are open to different manipulations, sometimes for the same underlying reason. Practically speaking, that argues against shame-based or one-size-fits-all interventions and for variety in your simulations and scenarios, so that everyone eventually encounters the tactic that works for them in a safe setting. It is also a prompt to think about psychological diversity when designing reporting channels; a phone-a-human verification step is a very different ask for an anxious colleague than a one-click button. Small samples again, so treat this as direction of travel rather than settled fact.

Source: Anxious and Aware: Social Anxiety and Social Engineering Resilience, peer-reviewed at SOUPS 2026 (survey n=42, interviews n=20).


That's the week. A field survey telling us AI is now core human risk territory, a government agency writing organisational psychology into technical guidance, and researchers reminding us that the moment of the click is emotional before it is rational. Keep the humans in the loop, and keep the loop humane.

Until next Monday,

The CyBehave Team

Get Signals in your inbox

Subscribe and choose the Signals weekly briefing to receive each edition the morning it publishes.