CyberAI Field Guide

A open-source text collection for student consultants, practitioners, and clinical educators bridging cybersecurity, artificial intelligence, and public interest technology. Written for the course-based Cybersecurity Clinic at UNC Charlotte, but adaptable for almost anyone's program or curriculum.

By Dr. Cori Faklaris (with a lot of help from Gemini to summarize sources and format the text).

1. Interviewing for Impact: A Field Guide for Student Consultants

In a CyberAI Clinic, technical expertise is only half the equation. You can deploy the sharpest vulnerability scanners or evaluate the most sophisticated Large Language Model (LLM) architectures, but if you don't understand the human, organizational, and operational realities of your client, your technical recommendations will end up gathering dust on a shelf.

Interviewing for Impact is the practice of moving beyond rigid, checklist-driven audits to conduct empathetic, context-aware discovery sessions. It transforms client interviews from administrative interrogations into collaborative, trust-building strategic dialogues.

1.1 The Mindset Shift: Auditor vs. Impact Consultant

To conduct impactful interviews, you must pivot from an auditor mindset to a clinic consultant mindset.

Dimension The Auditor Mindset The Impact Consultant Mindset
Primary Goal Finding compliance gaps and technical flaws. Understanding workflow realities and organizational constraints.
Stance Evaluative, top-down, and interrogative. Curious, collaborative, and grounded in partnership.
Question Type Closed ("Yes/No") checklist items. Open-ended, scenario-based, and human-centered.
Focus What software/security controls exist. How people interact with tools, trade off risks, and adapt under pressure.
Client Reaction Defensive, cautious, formal. Transparent, engaged, candid.
💡 Core Clinic Insight: Organizations rarely fail to implement security or AI safety because they lack awareness—they fail because security controls conflict with their core mission, timeline pressure, or budget limits.

1.2 The 3-Phase Framework for Impactful Interviews

Phase 1: Contextual Prep • Power Dynamics & Scope • Semi-Structured Protocol • Cultural Humility & Context Phase 2: Empathic Execution • Active Listening & Probing • Plain-Language Translation • Uncovering Workarounds Phase 3: Strategic Synthesis • Human Needs to Roadmaps • Root Cause Analysis • Prioritized Recommendations
Figure 1. The 3-Phase Framework for Impactful Student-Client Engagements. A linear methodology guiding CyberAI student consultants through pre-interview contextual preparation, empathetic execution during discovery, and strategic post-interview synthesis.

1.3 Rewording Questions for Impact: A Cheat Sheet

When preparing your interview guide, use this reframing guide to convert closed technical questions into impact-driven prompts:

2. Qualitative Interview Moderating: A Field Guide for Student Consultants

📌 Credit & Attribution: This section is adapted for student consulting teams based on the foundational principles established in Meta Research's article, Qualitative Interview Moderating Phrase Toolkit.

As a student consultant, qualitative interviews—whether with executives, technical staff, or frontline end-users—are your primary channel for gathering authentic field data. However, conducting a discovery interview isn't just about reading questions off a script; it's about moderation.

Moderation is the art of steering the conversation, digging past surface-level assumptions, managing time, and remaining completely neutral—all while keeping your participant comfortable.

2.1 Setting the Stage: Building Rapport & Permission

When interviewing experienced industry professionals, you may encounter a perceived authority gap. Bridge this immediately by establishing clear roles: they are the subject-matter experts, and you are the neutral researchers.

2.2 Probing: Digging Past Surface Answers

Participants often default to buzzwords or high-level generalizations (e.g., "Communication is bad" or "The interface is confusing"). Your job is to extract concrete behavior without asking leading questions.

Participant Says... Avoid Asking (Leading) Use This Moderating Phrase
"The software is unusable." "Did it crash a lot?" "Can you walk me through the last time you tried to use it?"
"Our team lacks alignment." "Is leadership bad at communicating?" "What does 'alignment' look like when a project is going well vs. when it isn't?"
"The system is too slow." "Did you have to wait minutes?" "When you say 'slow,' what is happening on your screen during that time?"

2.3 Steering: Managing Time & Tangents

Consulting interviews run on strict schedules. When an executive goes on a long tangent, regain control politely without dismissing their input.

2.4 Clarifying: Validating Without Influencing

Always avoid feeding your consulting hypotheses directly to the participant. Echo their points back to confirm accuracy without shaping their response.

2.5 Navigating Silence & Awkward Moments

Silence feels uncomfortable, but in qualitative research, silence is often when the deepest reflection occurs.

2.6 The Golden Wrap-Up Questions

Conclude every interview session with open-ended probes to unlock unscripted insights:

2.7 Quick Reference Moderator Cheat Sheet

=== STUDENT MODERATOR FIELD CHEAT SHEET ===
[01. DON'T LEAD] âž” "Tell me about..." NOT "Did you like..."
[02. BE SPECIFIC] âž” "Walk me through the last time..."
[03. USE SILENCE] âž” Count to 5 before asking the next question.
[04. PIVOT GENTLY] âž” "In the interest of time, let's look at..."
[05. BLINDSPOTS] âž” "What question should I have asked today?"

3. Demystifying Algorithmic Dependencies: A CyberAI Clinic Field Guide

When a client tells you, "We built an internal AI customer support tool," it is easy to imagine a single, self-contained box. The reality is almost always a complex web. Modern AI and cybersecurity tools depend on open-source libraries, cloud-hosted foundation models, vector databases, and third-party APIs.

3.1 The Anatomy of an Algorithmic Dependency

An algorithmic dependency exists whenever a client’s technology relies on an external algorithm, model, service, or dataset to make decisions, transform data, or execute security functions.

Client System ⚠️ Enters PII Middleware Layer ⚠️ Hardcoded Keys Vendor API ⚠️ Logs & Retains Data Foundation Model ⚠️ Silent Model Updates
Figure 2. Anatomy of an Implicit Algorithmic Dependency Chain. Architectural breakdown demonstrating how client data moves from internal environments through middleware orchestration layers to third-party vendor APIs and foundation models.

3.2 Algorithmic and API Dependency Risk Framework

Risk Category Key Vulnerability Question Real-World Clinic Impact
Data Privacy & Terms Do vendor Terms of Service (ToS) permit data retention or model training? Sensitive customer PII sent to a third-party LLM endpoint becomes part of the vendor's training pipeline.
Authentication & Keys Are API keys hardcoded in frontend code or stored securely in secret managers? An attacker decompiles a web app, steals the client's API key, and runs up thousands of dollars in unauthorized usage.
Fallback & Redundancy What happens if a third-party API goes offline or responds with invalid JSON? A security dashboard silently stops ingesting threat alerts because an external API rate limit was hit.
Model Drift & Evasion How does the system handle unexpected model behavior or prompt injection? A client-facing customer service bot is manipulated via prompt injection to divulge internal system instructions.

Table 1. Algorithmic and API Dependency Risk Taxonomy.

4. Problem Diagnosis and Reframing: A Field Guide

When a client walks into a CyberAI Clinic project, they rarely hand you the real problem. Instead, they hand you either a symptom or a premature solution. Problem Diagnosis and Reframing is the art of looking past surface-level requests to uncover root technical and human vulnerabilities.

4.1 The Iceberg Model of Problem Diagnosis

Stated Request (Above Water): "Build an AI Security Chatbot"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Underlying Root Causes (Below Water): Unstructured Data & Noise • Fragile Access Controls • Workflow Bottlenecks • Governance Gaps

4.2 Diagnostic Matrix for Student Teams

Client's Stated Request Diagnosed Root Cause Reframed Project Scope
"We need a penetration test on our internal web app." The app was built by volunteers on outdated open-source libraries with zero patch management. Dependency & Vulnerability Audit: Audit open-source libraries, establish an automated patching workflow, and train staff.
"We want to train an internal LLM on our past client intake files." Unstructured intake data contains unencrypted PII, and the team lacks cloud infrastructure to host local models. Data Governance & Privacy Scoping: Build a PII masking pipeline, evaluate vendor API privacy terms, and establish safe data-handling standards.
"Employees keep ignoring our required annual cybersecurity training." Policies are written in dense legalese and conflict with daily operational deadlines. Human-Centered Security Review: Conduct workflow interviews, streamline password/MFA friction, and co-design realistic guidelines.

5. How to Inventory Cybersecurity and AI Assets

Before an organization can assess risks, enforce security policies, or ensure regulatory compliance, it must answer a foundational question: What assets do we actually own and run?

5.1 Categorizing Cybersecurity vs. AI Assets

Asset Domain Asset Category Examples
Traditional Cybersecurity Hardware & Endpoints Laptops, servers, mobile devices, IoT devices, routers.
Software & Infrastructure Operating systems, SaaS platforms, databases, cloud storage buckets (e.g., AWS S3).
AI & Machine Learning Data Assets Raw training data, evaluation benchmarks, vector embeddings, synthetic datasets.
Model Assets & Dependencies Model weights, checkpoint files, fine-tuned LLMs, third-party APIs (OpenAI, Anthropic).

5.2 Real-World Standards & Frameworks

6. Technical Threat Modeling Meets Socio-Technical Risk Identification

Traditional threat modeling answers a critical question: "How could a malicious actor break our system?" In a CyberAI Clinic environment, algorithms interact with human workflows, organizational incentives, and historical biases. Socio-technical risk identification expands traditional threat modeling to bridge software security with human impact.

6.1 The Integrated 4-Step Threat Modeling Workflow

1 Map Boundaries • System DFDs & APIs • Human & User Roles • Decision Points 2 Brainstorm Vectors • STRIDE Threat Cases • Operational Misuse • Bias & Harm Scenarios 3 Evaluate Impact • Technical Severity • Societal & User Harm • Likelihood Scoring 4 Co-Design Fixes • Technical Controls • Policy & Guidelines • Training & Feedback
Figure 3. The Integrated 4-Step Socio-Technical Threat Modeling Workflow. A comprehensive assessment lifecycle bridging traditional software threat modeling (STRIDE) with human-centric risk identification.

6.2 STRIDE Meets Socio-Technical Risk

STRIDE Category Socio-Technical Expansion Combined CyberAI Risk Example
Spoofing Trust & Authority Exploitation Users over-relying on an automated AI advisor, treating output as authoritative truth without validation.
Tampering Data Pollution & Bias Amplification Training data skewed by historical operational bias, causing systemic discrimination against marginalized clients.
Repudiation Governance & Accountability Vacuum Unclear human ownership when an automated triage system mistakenly denies services to an applicant.
Information Disclosure Privacy Breaches & Consent Violations Sensitive user data processed by third-party APIs in violation of client privacy policies or community trust.
Denial of Service Operational Friction & Burnout Overly complex MFA or AI guardrails that cause staff to bypass security controls entirely to meet job deadlines.
Elevation of Privilege Power Asymmetry & Disempowerment System design that deprives frontline workers or end-users of a mechanism to appeal automated decisions.

Course Acknowledgments & Credits

This course has been designed based on materials made available through:

For Fall 2026, modifications include the Consortium of Cybersecurity Clinics’ AI Risk Management (AIRM) Pilot materials and Faklaris and Ramesh’s 2026–28 Participatory AI Risk Assessment course curriculum project.

We acknowledge and are grateful for the generous support of the Mozilla Foundation, the Mellon Foundation, the Consortium of Cybersecurity Clinics and its member sites, and Bank of America.