Human security

2026-07-09T00:00:00.000Z · complete

Every session so far has looked at a technical mechanism and asked how it fails: a memory layout (Session 3), a cache (Session 4), an access-control boundary (Session 5). This session steps outside the machine entirely. The mechanisms in an organization are people — their passwords, their clicks, their judgment about a suspicious email or an AI-generated answer — and no amount of ASLR or SELinux policy fixes a person clicking a phishing link. The lecture reframes the whole problem: stop asking only “how do we keep attackers out?” and start asking “given that some of them will get in, how does the organization stay standing?”

Part A — Research: Cyber Resilience, Culture & AI Risk

Based on the class lecture by Dr. Keri Pearlson (Principal Research Scientist, MIT Sloan School of Management) [1]

Cybersecurity is a bigger problem than “stealing data”

The lecture opens by widening the frame beyond credit-card theft. Modern cyber threats target an organization in at least four distinct ways: malware for direct profit, ransomware to disrupt operations until a payment is made, supply-chain attacks that use your systems as a stepping stone into your customers’, and IP or asset theft carried out by nation-states. The headline point: “it’s not going away, and full recovery is not always possible” — which is exactly why the rest of the lecture is about resilience rather than pure prevention [1].

From protection to resilience

Why can’t we be protected enough? The NIST Cybersecurity Framework lays out six functions — Govern, Identify, Protect, Detect, Respond, Recover — but MIT’s research finds most organizations spend roughly 80% of their time and budget on protection and only 20% on response and recovery [2]. Attacks still succeed anyway, because no protection layer is perfect and a lopsided investment leaves the organization slow and unpracticed exactly when it matters most: after the breach has already happened.

This motivates a reframing:

Formally: resilience is the ability to anticipate a shock, experience it, absorb it without significant loss, and then respond in a way that brings the organization back to an equivalent or higher level of performance [3]. Plotted over time, a resilient organization’s performance still dips on shock — but the dip is shallower and the recovery faster than a non-resilient one, across four phases:

The stated goal for a fully resilient organization is ambitious but concrete: when an attack happens, there is zero damage — no impact on operations, financial health, data integrity, or reputation [1].

Mechanisms that build cyber resilience

MIT’s research identifies six concrete mechanisms an organization can invest in beyond pure technical protection [4]:

For governance, MIT built a Balanced Scorecard for Cybersecurity Resilience that gives boards a structured way to assess Financial, Technological, Organizational, and Supply Chain readiness, feeding into an overall Resilience Assessment — designed to move the board conversation from “are we protected?” to “how resilient are we?” [5].

Building a culture of cybersecurity

People remain the most common entry point. People use poor passwords, click on links, fall for phishing, share company assets casually, and run business processes without considering security. Training and awareness campaigns alone have not been enough to close this gap [1] — which is why the lecture treats culture as its own mechanism, not a training checkbox.

Definition: a cybersecurity culture is the beliefs, values, and attitudes that drive cybersecure behaviors in an organization [1].

The Cybersecurity Culture Model. Two categories of upstream input shape an organization’s values, attitudes, and beliefs, which in turn drive behavior (behavior also feeds back and reinforces belief) [6]:

Crucially, values/attitudes/beliefs and behaviors are each modeled at three levels at once — leadership, group, and individual — because a culture that only exists at the leadership level (top management priority, participation, knowledge) never reaches the individual behaviors (employee self-efficacy, policy awareness, general threat awareness) without the group layer (community norms, teamwork, IT/business collaboration) carrying it there [6].

Maturity is a five-stage progression, not a one-time initiative:

Where does that leave you or your organization right now? The self-assessment below maps 8 short questions — half about your own habits, half about your organization’s mechanisms — onto these same five stages, not an invented score:

MAPS is MIT’s effectiveness-measurement model for that culture, organized around four quadrants: Management/leadership (ownership — culture leader, resilience plans, supervisor involvement), Attitudes/values/beliefs (the unwritten rules — individual empowerment, responsibility, team support), Policies and practices (rules and procedures — training, compliance, rewards/consequences), and Strategy (goals and plans — group collaboration, just-in-time learning, funding for culture initiatives) [7]. MIT’s research group is actively testing this measurement approach.

Case study — Yahoo. Pearlson’s own reporting on how Yahoo built a culture of cybersecurity is cited as a worked example of changing organizational values as the path to changing behavior, rather than trying to mandate behavior directly [8].

Using AI securely

The temptation is overwhelming. AI is delivering real productivity gains across the enterprise, vendors are embedding it into every product, and workers see the seductive upside immediately — the lecture’s own example is a NYC subway ad for an AI tool promising “one prompt, job done.” Conventional risk management sees only the visible part of that iceberg — productivity, new capabilities, efficiency — while hidden human and cultural risks sit below the waterline, and training/awareness activities alone are not enough to address them [1].

LLMs have many attack surfaces, spanning the entire pipeline rather than one weak point: prompt injection and data disclosure at the prompt; insecure output handling, data leaks, permission issues, and hallucinations at the response; over-reliance and model theft at the model itself, plus copyright, bias, and feedback-poisoning risk during build/train/test; training-data poisoning at the training data stage; excessive agency and malicious/insecure plugins at the API/plugin/human boundary; and denial-of-service and supply-chain attacks that can hit the whole system [9].

The MIT AI Risk Repository organizes these into a broader taxonomy of seven categories: discrimination & toxicity, privacy & security, misinformation, malicious actors & misuse, human-computer interaction, socioeconomic & environmental harms, and AI system safety/failures/ limitations [10]. Narrowed to the human dimension, AI specifically amplifies six risk factors organizations must manage: hallucinations & wrong decisions, data leakage & privacy violations, inherent bias, employee deskilling, deepfakes & misinformation, and data poisoning [1]. Deskilling is worth pausing on — it is the one risk that grows silently: nothing breaks visibly while a team’s own judgment atrophies from disuse.

The threat landscape is also changing on the attacker’s side. AI does not just create new victim-side risks — it upgrades the attacker’s toolkit directly:

AI governance

Because AI risk is structurally different from conventional IT risk, the lecture argues it needs its own governance layer, built on three pillars — structures, processes, and principals — to ensure AI is used responsibly, safely, and in alignment with organizational values [1]. Good governance does three things: assigns clear responsibility and ownership, ensures fair/transparent/ethical use, and mitigates the risk of biased decisions, privacy violations, ethical lapses, and misuse — while the common obstacles are a lack of expertise, collaboration issues, and fragmented data.

MIT’s five-part framework for what “good governance” concretely includes [11]:

Governance feeds directly back into the Cybersecurity Culture Model from earlier: it acts as an additional force shaping the organization’s values, attitudes, and beliefs — the same loop that produces behavior, now with AI-specific inputs [1].

Current research: what people actually believe about AI risk

MIT’s ongoing research asks two questions: what do employees actually know about the risks and vulnerabilities of using GenAI, and how can organizations build a culture of AI security to manage those risks specifically [1]? Preliminary results from 40 respondents in the MIT xPro AI class (March 2026) are revealing:

The gap between personal mitigation and organizational expectation is the most interesting part of the data. People mostly self-regulate through manual effort — fact-checking outputs (78%), removing sensitive data before prompting (75%), seeking out training on their own initiative (64%) — while what organizations formally ask for lags behind: only 43% report a mandatory training requirement, and 15% report their organization has no formal AI policy at all [1]. That gap is itself a culture-maturity signal: it looks like Stage 1 (“Adhoc”) behavior on the five-stage model above, even inside organizations that believe they are further along.

Action plan: build cyber and AI resilience

The lecture closes with four concrete moves, explicitly tying the culture model and the resilience model together [1]:

1. Find ways to personally step up — model the behaviors necessary to keep your organization, your family, and yourself secure; be visibly part of the solution.
2. Make heroes of the people who do cybersecure behaviors — recognition is what creates the values, attitudes, and beliefs that drive a cybersecure culture; others follow what gets celebrated, not what gets mandated.
3. Implement AI with risk management in mind — make sure skills are not lost to over-reliance and AI outputs are not followed blindly.
4. Create resilience in addition to protection — build the processes to respond and recover quickly, and practice, practice, practice.

Part B — Reflection: Class 6 Homework

The homework for this session is not a hands-on lab — it is a set of written reflection questions, which fits the topic: culture and resilience are organizational practices, not commands to run. Each question below maps directly onto the frameworks from Part A (the resilience/protection distinction, the Cybersecurity Culture Model, and the AI-specific risk material).

01Cyber resilience vs. protection

To me, cyber resilience is an organization’s ability to keep operating, or get back to operating quickly, after something goes wrong — not the ability to prevent anything from going wrong in the first place. Traditional protection and security bet everything on the perimeter: firewalls, access control, hardening — everything Sessions 1–5 of this course have covered. That bet is necessary but, as Part A shows, structurally incomplete: it assumes that if the design is good enough, the attacker never gets in. Resilience starts from the opposite premise — the attacker will get in eventually, through a bug, a human who clicked the wrong link, or a leaked credential — and the question that actually matters is how fast I detect that, contain the damage, and get back to normal operation.

a. One concrete thing I can do to build cyber resilience. In my own stack (the AI lab’s FastAPI/Django services, Postgres/Mongo/Firestore databases), the most concrete and actionable move is a tested backup-and-restore procedure, not just a configured one. It isn’t enough to have automated backups running silently; I need to run a full restore drill at least once a semester to confirm that if a database is corrupted or ransomware-encrypted, I can bring the service back in hours, not days. A backup that has never been restored is, in practice, an unverified promise.

b. What gets in the way. In an academic environment like mine, the most real obstacle is that cybersecurity isn’t the institution’s central mission — budget, team time, and leadership attention go almost entirely to teaching and research, and security ends up as “something we do if there’s time left over.” This matches exactly the statistic that opens the lecture: 80% of effort goes to protection (something visible and finishable, like installing a firewall) and almost none to practicing response, because practicing response requires dedicated time that competes directly with day-to-day priorities.

c. Why resilience is an effective response to human-centric vulnerabilities specifically. Because no amount of training or technical control eliminates human error completely — people will keep using weak passwords, clicking links, and sharing information without thinking about security, exactly as the lecture’s own list describes. If my strategy depends 100% on no human ever making a mistake, I’m designing to fail. Resilience accepts human error as a constant of the system, not an exception to correct, and builds the organizational capacity to absorb that error and recover fast — which is far more realistic than trying to make people infallible.

02Behaviors, values, and mechanisms for a cybersecurity culture

a. 2–3 behaviors I’d want people to adopt.

• Verify before acting: confirm through a second channel before clicking a link, opening an attachment, or transferring sensitive information, instead of trusting the message’s urgency.
• Report suspected phishing, a compromised credential, or odd system behavior immediately and without fear — even if the report turns out to be a false alarm.
• In my specific development context: never commit credentials, API keys, or .env files to a repository, and treat any AI-generated code as a draft that gets reviewed before merging, not as a finished deliverable.

b. The values, attitudes, and beliefs those behaviors need. What sustains those three behaviors is the belief that security is shared responsibility, not the systems team’s exclusively — and, tied to that, real psychological safety: that reporting a mistake or a suspicion carries no personal cost or judgment, and that double-checking before acting fast is seen as good work, not slowness. The self-efficacy belief from Pearlson’s model matters here too: that my individual action — checking a link, not committing a key — actually matters to the collective outcome, instead of assuming “IT will handle that.”

c. The mechanisms I’d actually use.

• Visible recognition, not just consequences. When someone reports a real phishing attempt or catches an exposed credential, make it public and thank them — exactly Pearlson’s recommendation to “make heroes of the people who do cybersecure behaviors,” because others follow what gets celebrated.
• Blameless postmortems when something goes wrong, focused on which mechanism was missing, not who made the mistake — this is what makes reporting genuinely cost-free.
• Build verification into the workflow itself, not a separate training. For example, automated secret-scanning on every pull request that blocks the merge if it finds a key, and a mandatory human code review — not just an AI one — before deploying to production. This makes the desired behavior the path of least resistance, instead of depending on people remembering it on their own.
• Leadership that models the behavior. If I, as the person running the lab, follow the same rules (MFA, code review, no password reuse), the policy becomes credible instead of aspirational.

03Human-centric risks of GenAI tools

Risk 1 — Leakage of confidential or proprietary data through prompts. Every time someone pastes information into an AI chat to ask for help, that information leaves the organization’s boundary toward a third party — and, depending on the service tier, may be stored or even used for training. This was the second most-reported risk in the lecture’s survey (77%), and it makes sense: it’s the easiest one to commit without realizing it, because it feels like “I’m just asking for debugging help,” not “I’m sharing a secret.”

Example: a student or collaborator in the AI lab pastes a code snippet containing the full Postgres connection string — user, password, host — into a GenAI chat to ask for help debugging a connection error, without realizing they just exposed a production credential to an external service they don’t control.

Behavior that would minimize the risk: sanitize any data before pasting it into an AI tool — replace credentials, real names, and identifying data with generic placeholders — and treat any general-purpose AI as a public channel, never a confidential one.

Mechanism: a concrete, written AI-use policy stating what can and can’t be pasted, reinforced with a low-friction technical control — a hook or linter that detects credential patterns (connection strings, API keys, JWT tokens) before a commit or prompt goes out — plus an institutionally approved list of AI tools with appropriate data agreements for sensitive work.

Risk 2 — Over-reliance on AI output without verification (hallucinations and skill erosion). This was the most-reported risk in the lecture’s survey (85%), and the lecture ties it to a related phenomenon: when people stop verifying because the AI “sounds confident,” their own judgment atrophies over time — deskilling. The risk isn’t just the one-off error; it’s the progressive loss of the ability to catch it.

Example: when evaluating executive summaries of student projects for Expo Ibero, or reviewing an AI-assisted authentication flow for a FastAPI service, accepting the AI’s output without checking it against the source or without a security review — an endpoint with a subtly wrong permission check, or an invented fact or citation in a summary — that makes it into production or gets approved because “the AI already checked it.”

Behavior that would minimize the risk: treat all AI output as a first draft requiring explicit human verification before use — human code review, not just another AI’s, before merging, and manual verification of any factual claim or citation before citing or grading it.

Mechanism: make human verification a formal, non-optional step in the process — for example, require that any pull request with AI-generated code carry an explicitly marked human review before the merge is approved, and make sure performance evaluation doesn’t reward delivery speed alone, to avoid creating the perverse incentive to skip verification just to go faster.

What stays with me most from this lecture is the gap between what people say they fear about GenAI and what they actually do about it — 85% fear hallucinations, but only 78% fact-check outputs, and just 43% work somewhere with an actual mandatory training requirement [1]. That gap is exactly the blind spot the culture model points at: fear alone isn’t a mechanism, it’s an attitude with no sustained behavior behind it. If I take one thing from this session back to my own lab, it’s that writing an AI-use policy doesn’t do much unless it’s tied to a concrete mechanism — a checkpoint built into the workflow, not just a document people sign once.

It also lands close to home in a specific way: at IDIT and in the classroom at IBERO Puebla, the “human” in human security is not an abstract employee population in a case study — it’s literally students and colleagues I work with directly. That changes which mechanisms actually make sense. A blameless postmortem or a public thank-you for reporting a phishing attempt works completely differently in a small academic lab than in a large company, and the resilience/culture framing from Part A gives me a vocabulary for that difference instead of just an intuition about it.

Tools & references

1. Dr. Keri Pearlson (Principal Research Scientist, MIT Sloan School of Management), “Managing Human Security Cybersecurity and AI Risks: Create Resilience” — lecture slides · Fab Futures Cybersecurity 2026 · 9 Jul 2026
2. Framework for Improving Critical Infrastructure Cybersecurity · National Institute of Standards and Technology (NIST), 2018 — the Govern/Identify/Protect/Detect/Respond/Recover framework referenced in the lecture
3. An Action Plan for Cyber Resilience · Michael Coden, Martin Reeves, Keri Pearlson, Stuart Madnick, Cheryl Berriman · MIT Sloan Management Review · 4 Jan 2023
4. Cyberattacks Are Inevitable. Is Your Company Prepared? · Keri Pearlson, Brett Thorson, Stuart Madnick, Michael Coden · Harvard Business Review · 9 Mar 2021
5. A Tool to Help Boards Measure Cyber Resilience · Keri Pearlson · Harvard Business Review · 4 Oct 2023
6. Pearlson, K. — Cybersecurity Culture Model (External Influences + Managerial Mechanisms → Values/Attitudes/Beliefs → Behaviors, at Leadership/Group/Individual levels) · MIT Sloan cybersecurity culture research programme
7. Pearlson, K. — MAPS: Cyber Culture Effectiveness Measurement Model (Management, Attitudes/Values/Beliefs, Policy and Practices, Strategy) · MIT Sloan cybersecurity culture research programme
8. How Yahoo Built a Culture of Cybersecurity · Keri Pearlson, Sean Sposito, Masha Arbisman, Josh A. Schwartz · Harvard Business Review · 30 Sep 2021
9. LLM attack-surface diagram (Prompt, Response, Model, Training Data, API/Plugin/Human) — slide sourced to Etay Maor, cited in Pearlson lecture materials, 2026
10. The MIT AI Risk Repository · MIT, 2025 — 7-category AI risk taxonomy: discrimination & toxicity, privacy & security, misinformation, malicious actors & misuse, human-computer interaction, socioeconomic & environmental harms, AI system safety/failures/limitations
11. MIT xPRO — Components of Good Governance of AI for Organizations (Executive Oversight, Governance Policies, Controls for Risk/Use/Impact, Design/Develop/Deployment Guidelines, Monitoring & Management Processes) · cited in Pearlson lecture materials, 2026