# AI Security Risks Explained: From Deepfakes to Prompt Injection

> A SecTor briefing on prompt injection, poisoned data, deepfakes, shadow AI, explainability, and accountable AI deployment.

[Canonical HTML page](https://trustcyber.ca/insights/ai-security-risks-deepfakes-prompt-injection/)

- Author: Junior Williams
- Type: Insight film
- Published: 2026-08-20
- Modified: 2026-08-20
- Topics: AI security, Cybersecurity risk, AI governance

## What this examines

In this SecTor briefing, Junior Williams moves from a practical definition of generative AI to the risks that appear when models meet enterprise data, identities, workflows, and decision authority. The talk connects prompt injection and data poisoning with multimodal deception, shadow AI, explainability, deployment choices, and the controls needed to keep accountability human.

## Why it matters

Organizations do not encounter AI risk as one isolated model problem. The exposure spans inputs, training data, generated content, unsanctioned tools, cloud boundaries, access decisions, and the people asked to trust the output. Treating those elements as one operating system makes governance and security controls easier to place.

## Key ideas

- Prompt injection manipulates model inputs and instructions; training-data poisoning corrupts behaviour further upstream.
- Deepfakes and other multimodal outputs weaken verification methods that rely on familiar voices, faces, or polished presentation.
- Shadow AI creates unmanaged data, compliance, recovery, and access risk even when employees are trying to work more effectively.
- Data validation, continuous monitoring, human oversight, transparency, and stakeholder education form a practical trust layer.
- Explainability must be designed for the people making or receiving the decision, then validated as the model and context change.
- Accountability is the central test: tools and providers can change, but ownership of the decision cannot disappear.

## The risk is a system, not a model

The talk starts by separating the broad idea of artificial intelligence from machine learning, neural networks, and generative models. That framing matters because the security boundary is wider than the model. It includes the data entering the system, the software and identities surrounding it, the generated output, the workflow that consumes it, and the person or process authorized to act.
Once text, sound, images, and video share the same model ecosystem, a control designed for one modality cannot carry the whole load. AI security becomes an architecture and operating-model problem rather than a single product setting.

## Prompt injection and poisoned data

Prompt injection and training-data poisoning attack different points in the lifecycle. Injection tries to redirect behaviour through crafted inputs or instructions. Poisoning changes what the model learns by introducing malicious or misleading material into its training or adaptation data.
- Constrain what the model can retrieve, call, disclose, and change; do not depend on instruction text as the only boundary.
- Treat external content and retrieved documents as untrusted input, especially when they can carry instructions into an agent workflow.
- Track the provenance, approval, and integrity of training, fine-tuning, and retrieval data so corrupted inputs can be identified and removed.

## Multimodal deception and shadow AI

The deepfake example makes the verification problem concrete: a familiar voice or convincing image is no longer sufficient proof of identity or intent. Verification has to move toward independent channels, stronger identity controls, transaction context, and escalation when a request is unusual.
The same section treats shadow AI as a risk of inaction. When sanctioned tools do not meet a real need, people route work through consumer services or unsanctioned software. The result can be fragmented workflows, regulatory exposure, unrecoverable data, intellectual-property loss, or a path into more consequential systems.

## Trust needs operating controls

Trust is not a label applied after deployment. The talk proposes a practical control set: validate data, monitor model behaviour, preserve human oversight, communicate how systems are developed and used, and educate both technical and non-technical stakeholders about capabilities and limits.
- Validate source quality, relevance, duplication, and potential bias before the data becomes operational evidence.
- Monitor performance and drift continuously rather than assuming a model that passed once remains reliable.
- Keep a human accountable for high-impact decisions and make escalation possible when evidence is weak or conflicting.
- Explain the system at the level needed by operators, executives, affected people, auditors, and regulators.

## Explainability has an audience

The medical-diagnosis example shows why explainability is contextual. A clinician needs a decision aid at the moment of care, a patient needs an understandable reason, and a regulator needs evidence that can be audited. One explanation cannot serve every audience equally well.
A useful explainability practice defines the decision, audience, and required level of detail; selects an appropriate explanation method; puts the explanation into the workflow; validates it against real outcomes; and refines it as the model and environment change.

## Deployment is an architecture choice

The talk contrasts local automation, on-premises AI platforms, and cloud productivity systems to make a larger point: deployment choices determine where data travels, who can administer the system, which identities can reach it, and what evidence is available when something goes wrong.
A responsible design starts with the workload and data classification, then applies identity and access management, segmentation, retention, monitoring, and recovery controls appropriate to that boundary. The question is not simply on-premises or cloud; it is whether the chosen architecture makes authority and data movement explicit.

## Red-team the safeguards

The live demonstration shows a model refusing a harmful request and then producing equivalent code after the request was obfuscated. The durable lesson is not the bypass technique. It is that a refusal message is not proof of containment.
Teams should test alternate encodings, indirect instructions, tool-mediated paths, retrieval content, and multi-step transformations. Results should feed back into permissions, monitoring, evaluation, and incident response rather than remaining an isolated model benchmark.

## The one-word test: accountability

The presentation distills its governance checklist to one word: accountability. Governance and regulation, privacy and security, transparency and explainability, fairness and bias, skills, and operationalization all depend on knowing who owns the decision and who can intervene.
That remains the practical test for an AI initiative: identify the accountable owner, the evidence they receive, the authority the system holds, the limits it cannot cross, and the mechanism that stops or corrects it when reality diverges from expectation.

## Evidence note

This page is based on the public YouTube video, its chapter list, and an auto-generated English transcript. The recording date (October 24, 2024), YouTube upload date (June 6, 2025), and 41:01 runtime come from the video page. Transcript wording was treated as supporting evidence rather than a verbatim record where captions were ambiguous. References to standards, products, and the AI threat landscape reflect the talk’s 2024 context.

## Resources

- [Watch the complete SecTor talk on YouTube](https://www.youtube.com/watch?v=8eWLbkqh6mk)
- [Embedded video](https://www.youtube-nocookie.com/embed/8eWLbkqh6mk)

## Practice with TryHackMe

- [LLM Security: Practical, Answer-Free Walkthrough](https://trustcyber.ca/tryhackme/llm-security/index.md): A practical, answer-free TryHackMe LLM Security walkthrough covering data, model, system, and user threats through the room’s guided demonstrations.
- [Jailbreaking: Practical, Answer-Free Walkthrough](https://trustcyber.ca/tryhackme/jailbreaking/index.md): An answer-free TryHackMe Jailbreaking walkthrough covering model safety boundaries, classic techniques, multi-turn conditioning, and defensive lessons.
