AI Security and Governance: Strategy and Leadership

Track outline from the bookExecutive and program leadership22 modules · 7 parts

The 22 modules below follow the book's chapters. Each opens with the chapter's executive takeaway. Video and workshop production has not started.

Who it is for. Executives and boards, CISOs and Chief AI Officers, heads of AI security, architects, security operations, risk and audit professionals, procurement, privacy and legal leaders, and public-sector technology leaders.

Part I: Leadership, Strategy, and Enterprise Context

Module 1: Why AI Security Is a Leadership Discipline

Executive takeaway. AI has moved from isolated models to enterprise AI systems that connect probabilistic components to real business actions through retrieval, tools, identities and workflows. Existing security disciplines remain essential, but they were not designed for systems whose outputs vary, whose instructions and data share one channel, and whose agents can act. The hardest questions are not technical: what AI may decide or do, how much autonomy it receives and under whose delegation, what evidence proves it is safe enough, and who owns the outcome. Security can advise on these questions and challenge the answers, but only accountable executives can settle them. Organizations that treat AI security as an enabler build trusted pathways that make safe adoption faster than unsafe adoption. This book offers an operating philosophy for doing so: Discover, Govern, Build, Prove, Observe, Respond and Improve.

Module 2: Building an Enterprise AI Security Strategy

Executive takeaway. Every material AI initiative needs two plans: a value plan that says what outcome justifies the system, and a trust-and-security plan that says what the system may do, with what data, under whose authority, and on what evidence. The enterprise AI security strategy makes both plans mandatory and consistent. It sets a vision and mission, fifteen principles that each map to controls, a risk appetite written as enforceable tolerances, eight measurable outcomes and explicit planning assumptions for 2026-2029. It is funded as one transformation portfolio covering experimentation, security, data and workforce, not as a security tax on projects. It is refreshed every year and whenever a signal it names fires. A strategy that cannot answer "may this team deploy this agent?" is not yet a strategy.

Module 3: Leadership, Accountability, and Decision Rights

Executive takeaway. AI security needs a governance structure in which every consequential decision has a named owner, a defined evidence standard and a clear escalation path. An Executive AI Governance Board sets risk appetite, reserves Tier 3 and Tier 4 decisions, and decides material exceptions. A federated hub-and-spoke model lets a central AI Security Office set policy, baselines, platforms and assurance expectations while mission and product teams build and operate within them. The governing rule is simple and non- negotiable: security advises and challenges; the official who owns the outcome accepts the residual risk. Decision rights must cover the full lifecycle, from use-case approval and agent permission grants through suspension, restart and retirement. Emergency stop authority must be pre-delegated, and restart authority must be deliberately separated from it. The same rules apply to AI used by the security function itself.

Part II: Governance and Portfolio Control

Module 4: AI Portfolio, Inventory, and Classification

Executive takeaway. The organization cannot secure, govern or report on AI it cannot see, so the AI portfolio is the first control and the one every other control depends on. "AI asset" must be defined broadly, from built systems and embedded software-as-a-service (SaaS) features to agents, Model Context Protocol (MCP) servers, coding assistants, experiments and evaluation assets. Discovery must combine independent signals such as procurement, OAuth grants, gateway telemetry, code, endpoints and cloud accounts, because intake alone finds only the people who already follow the rules. Every discovered asset gets a named owner, a record and a risk tier from Tier 0 (prohibited) to Tier 4 (critical), and that tier sets the minimum governance. Mandatory escalation triggers and a defined list of material changes keep the tier honest as systems evolve. Shadow AI is best treated as unmet demand: find it, contain the exposure, and offer a sanctioned path that is faster than the workaround.

Module 5: The AI Governance Operating Model

Executive takeaway. AI governance is an operating system, not a committee. It has to route every AI request by risk within days, apply a pre-defined control baseline to each risk tier, and add profile-specific controls for generative AI (GenAI), retrieval-augmented generation (RAG), agents, Model Context Protocol (MCP) servers and other system types without redesigning the process each time. Exceptions must be rare, time-limited, compensated and owned by the official who carries the risk. Every decision must leave evidence in one repository that auditors, regulators and executives can trust. A small set of forums, each with a defined purpose, chair, cadence and decision right, carries escalation from engineering teams to the Executive AI Governance Board, and an annual management review tests whether the whole arrangement still fits. Leaders should measure governance velocity by tier as deliberately as they measure risk: slow, opaque governance produces the shadow AI it is meant to prevent.

Module 6: Enterprise AI Risk Management

Executive takeaway. AI risk management works only when risks are written as concrete scenarios with named owners: who or what fails, through which component, doing what it should not, to whom, with what consequence. Threat labels such as "prompt injection" do not meet that standard. No single framework is enough, and none substitutes for another. The National Institute of Standards and Technology (NIST) AI Risk Management Framework (AI RMF) supplies the risk structure, its Generative AI Profile the generative AI overlay, CSF 2.0 and SP 800-53 the cybersecurity controls, ISO/IEC 42001 the management system, and MITRE and the OWASP lists the threat detail. Ratings must account for how autonomous a system is, how reversible and detectable its failures are, and how far they spread. Treatment is decided by the official who owns the outcome, not by security, and suspending or retiring a system is a legitimate treatment. AI risk must roll up into the enterprise risk register, and obligations should be met once, through shared control domains and reusable evidence.

Part III: Threats, Architecture, and Engineering

Module 7: Threat Modeling AI Systems

Executive takeaway. Threat modeling is how an organization decides, before release, which AI failures it will prevent, which it will detect, and which it will accept. For AI systems it must cover nine layers, from the mission and the humans in the loop down to infrastructure and the supply chain, because the most damaging attack paths cross several of them. Public frameworks help but work at different altitudes: the National Institute of Standards and Technology (NIST) supplies the taxonomy, MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) the adversary techniques, MITRE SAFE-AI the link to control catalogs, and the Open Worldwide Application Security Project (OWASP) the application-level risk lists. The organization should require a current threat model for every Tier 3 and Tier 4 system, at least a lightweight one for every Tier 2 system, and a revisit after every material change. Each critical threat must become at least one pre-release test and one runtime signal, or the threat model is documentation rather than a control. Leaders should ask for the residual-risk statement and the name of the person who accepted it.

Module 8: Secure AI Reference Architecture

Executive takeaway. A secure AI architecture separates what a model suggests from what the enterprise does. Every consequential action must pass through a policy enforcement point that the model cannot bypass, and it must carry an identity that traces back to an accountable human or system principal. Agents need their own non-human identities and narrowly delegated, short-lived credentials. They must never borrow a person's session or share a service account, because that one shortcut defeats least privilege, separation of duties and forensic attribution at once. Leaders should fund a small set of shared control points: an AI gateway, a tool and Model Context Protocol (MCP) gateway, an identity and token-exchange service, and an observability and evidence pipeline. These make secure delivery the fast path for product teams. Containment must be designed in advance: safe-mode levels, credential revocation and meaningful human approval are architecture decisions, not incident-day improvisations.

Module 9: Data, Model, and Supply-Chain Security

Executive takeaway. Data and models shape AI behavior more than code does, so the enterprise must govern them as security-critical assets: classified, minimized, traceable to their origin, integrity-protected and kept free of secrets. Every model, adapter and dataset entering the enterprise should pass a model intake review that records its source, license, version, hash, signature and evaluation status. That approval to acquire is separate from any approval to deploy it in a particular system, because a model's risk depends on where it is used. The AI supply chain now spans models, datasets, adapters, agent frameworks, skills, Model Context Protocol (MCP) servers, evaluation sets, hosting and sub-processors, and attackers target each of them. A scanner finds unsafe code in a file, and a signature proves who published it. Neither proves the model behaves safely; only trigger-oriented evaluation of the actual artifact in its actual use addresses that. Leaders should fund one shared intake path, one approved-model catalog and one AI Bill of Materials (AIBOM) practice, so that the secure route is also the fast one.

Module 10: Secure Retrieval-Augmented Generation

Executive takeaway. Retrieval-augmented generation grounds AI answers in enterprise content, but it does not remove prompt injection. It imports untrusted text into the model's instruction channel, and public guidance states that no reliable prevention for prompt injection exists today [R04, R55]. The organization must therefore secure RAG as a data-flow architecture, not as a model feature. Content is scanned, sanitized, labeled with provenance and classified before it is indexed. Retrieval enforces the source system's permissions for the person asking, never for the service account that runs the index. Retrieved text is kept segmented from instructions and can never, by itself, trigger a consequential action. Every retrieval leaves telemetry that the security operations center (SOC) can use to detect poisoning and misuse. Leaders should ask one question of every RAG system connected to a tool: if a single document in the corpus were hostile, what is the worst thing this system could do, and what independent control stops it?

Module 11: Agentic AI and Multi-Agent Security

Executive takeaway. Agents are privileged workloads that take instructions from untrusted content, so they must be governed like non-human identities with bounded, delegated authority, not like software features. The organization should bind every agent to an approved goal, give it a unique and revocable identity, limit its tools, data, memory, time, transactions and spending, and separate its planning from the execution of consequential actions. Memory is a write path into future decisions and needs the same validation, provenance and expiry as any other system of record. In multi-agent systems the orchestrator, the peer agents and the shared context are new trust boundaries, and required validation steps must be technically impossible to skip. Autonomy should be granted on an explicit ladder (observe, recommend, prepare, execute with approval, bounded autonomous execution), using the book's A0-A4 autonomy levels, with evidence-based entry criteria for each rung and automatic demotion when limits are crossed. Leaders own three decisions above all: which actions may never be autonomous, who accepts residual risk for each rung of autonomy, and how fast an agent can be stopped.

Module 12: MCP and Tool Ecosystem Security

Executive takeaway. MCP standardizes how AI applications connect to tools and data, so it standardizes a new attack surface as well. Every MCP server is third-party code whose tool descriptions enter the model's context and whose credentials reach real systems. The current specification (revision 2026-07-28) gives a sound authorization baseline: OAuth 2.1-based flows, discovery through protected resource metadata, tokens bound to a single MCP server, issuer validation, and a flat prohibition on token passthrough. That baseline does not answer the questions that matter most in an enterprise: which servers are allowed, whether a tool's description changed overnight, and what a local server on a developer laptop can reach. Company A should require an approved MCP registry and an MCP gateway for production and developer use, treat tool descriptions as code under change control, and keep the ability to revoke a server, client or token within minutes. The test for any MCP deployment is simple: if this server turned malicious tomorrow, what could it reach, and how fast would we know?

Part IV: Secure Delivery and Assurance

Module 13: The Secure AI Development Lifecycle

Executive takeaway. A secure AI development lifecycle is the existing secure software lifecycle, extended to govern prompts, policies, models, datasets, retrieval configurations, tool definitions and agent configurations as first-class, versioned, reviewed and signed artifacts. The book organizes it into nine stages, from intake to retirement, with six gates whose rigor scales with the system's risk tier. NIST's Secure Software Development Framework and its generative AI profile provide the baseline practices, and CISA and the UK NCSC provide the design-to-operation structure [R06, R07, R20]. The pivotal idea is the release unit: the model, prompt, policy, retrieval configuration, tool definitions and agent configuration are versioned and promoted together, so the evidence behind a release decision describes what actually runs. Material changes to any part of that unit must route back through the right gate, not around it. AI coding assistants and agents are now contributors to the codebase, and their output must be treated like any untrusted contribution, with dependency verification, because they can invent package names that attackers then register [R165]. Leaders should fund the pipeline controls once, on a shared paved road, rather than paying for manual reviews on every project.

Module 14: Evaluation, Assurance, and Red Teaming

Executive takeaway. Assurance is the evidence that a specific AI system, not a model in the abstract, is fit for its purpose, and it must be produced before and after release. Public benchmarks and vendor model cards are useful inputs, but they are not proof that the organization's own prompts, data, permissions and tools behave safely together. The organization should set pass thresholds before testing begins, judge findings by severity and exploitability rather than by pass counts, and require independent evaluators and a red team for Tier 3 and Tier 4 systems. Every confirmed weakness should become a permanent regression test, and every material change should trigger retesting. Tools help scale this work, but no tool covers the whole attack surface, and none replaces a threat model or human judgment. Leaders should expect a release recommendation that states what was tested, what was not, what remains, and what will be watched in production.

Module 15: Production Authorization and Guardrails

Executive takeaway. Production authorization is a recorded decision by the official who owns the outcome, not a security sign-off. For Tier 3 systems the Mission Owner approves and accepts the residual risk, the AI Security Office recommends and may formally object, and an objection escalates the decision to the Executive AI Governance Board, which also authorizes every Tier 4 system. The decision has six options (approve, approve with conditions, pilot only, redesign, suspend and reject), and most consequential systems should launch with conditions, monitoring thresholds and an expiry on any exception. Guardrails are layered runtime controls at the input, retrieval, output, tool and action, and session and budget layers. They reduce risk but never eliminate it, so they must be tested for bypass and backed by identity, least privilege and human approval for destructive actions. Anything a model generates, especially commands, queries and code, is untrusted input until a deterministic control validates it. The evidence chain, from requirement to threat, control, test, result, decision and monitoring, is what makes a release decision defensible after the fact.

Part V: Operations, Detection, Incident Response, and Resilience

Module 16: AI Observability and AI-SecOps

Executive takeaway. Leaders cannot govern, defend or answer for AI systems they cannot see. Every Tier 2-4 AI system should emit telemetry that lets the organization reconstruct who or what initiated an interaction, which model, prompt and policy versions applied, what was retrieved, which tools were called under whose authority, what humans approved, and what happened as a result. That telemetry must feed the existing SOC through a catalog of AI-specific detections, not sit in an engineering dashboard nobody monitors. Prompts, outputs and tool arguments are sensitive data, so the design must capture content selectively, redact and tokenize it, hold it in a restricted evidence store, and let investigators reach it only through controlled, logged access with defined retention. The OpenTelemetry conventions for generative AI give a common vocabulary, but they are still at "Development" stability, so the organization must pin versions and fill the gaps they leave. The target is a working AI-SecOps capability within roughly nine months, growing into agent detection and response as agent autonomy grows.

Module 17: AI Incident Response and Operational Resilience

Executive takeaway. AI incidents are security and operational incidents, and they must run through the same enterprise incident-response process, command structure and notification machinery as any other incident, aligned to National Institute of Standards and Technology (NIST) Special Publication (SP) 800-61 Rev. 3 and the functions of the NIST Cybersecurity Framework (CSF) 2.0 [R08, R05]. What is different is the set of containment levers: disabling a single tool or Model Context Protocol (MCP) server, revoking an agent's tokens, isolating an agent, quarantining memory or a retrieval source, rolling back a model, prompt or policy, and switching the system into a pre-authorized safe mode. Each lever must be built, tested and owned before it is needed, and each must capture the evidence it would otherwise destroy. Leaders should require an eight-category AI incident classification, a severity matrix that accounts for continuing autonomous action, the twenty playbooks indexed in Appendix J, and exercises that include legal, privacy, communications and the model provider. Recovery restores autonomy in stages and only after the system passes re-evaluation. Every incident should end with a changed threat model, a new regression test and a closed corrective action.

Part VI: The Enterprise Ecosystem

Module 18: Third-Party AI, Procurement, and Contracting

Executive takeaway. Third-party AI is a primary control domain, not a procurement formality, because most enterprise AI capability is acquired rather than built. Leaders should tier AI vendors by the risk of the systems they support, the data they touch, the actions they can take and how hard they are to replace, and scale diligence and contract terms to that tier. Due diligence covers eight areas: provider, model, data, security, responsible AI, supply chain, contract and operational integration. It uses a standard questionnaire (Appendix K) supported by the CSA AI Controls Matrix [R27], and it validates vendor claims with independent evidence and the organization's own evaluations. Before signature, contracts must settle training use, model-change notice and version pinning, retention and deletion, sub-processors, incident notification, evidence access and exit. After signature, vendors are monitored continuously, and every provider model change is handled as a potential material change to the systems that depend on it. An exit plan that has never been tested is an assumption, not a control.

Module 19: Responsible AI, Privacy, Ethics, and Human Oversight

Executive takeaway. Security, privacy, responsible AI, legal, safety and civil rights share one set of facts about each AI system but reach different conclusions, and they should work from a single context record with separate sign-offs. Human oversight counts as a control only when the reviewer has authority, understandable evidence, time to act before the consequence, a workload that permits real review, training against automation bias, and a way to record disagreement that the system learns from. A nominal human step that disguises automated decisions is worse than none, because it hides the risk. Consequential systems need an impact assessment started at design, a contestability and remedy path that works for affected people, transparency proportionate to the decision, and privacy engineering across every place personal data flows: prompts, retrieval, training, outputs, memory, logs and providers. Public-sector and regulated decisions add binding obligations, including the Office of Management and Budget (OMB) memorandum M-25-21's minimum practices for high-impact AI at U.S. federal agencies and the EU AI Act's high-risk regime, which, as amended in July 2026, applies to Annex III systems from 2 December 2027. Leaders should fund these as engineering work with measurable outcomes, not as review paperwork.

Part VII: Building the AI Security Organization

Module 20: Workforce, Roles, and Operating Culture

Executive takeaway. The AI Security Office should be a small, senior, multidisciplinary core that owns standards, high-risk assurance, reusable controls and program direction, extended by partner teams and embedded champions rather than replacing them. Staff it for the work that cannot be delegated: architecture patterns, agent and MCP security, independent evaluation evidence and program coordination come first, and scarce capabilities such as red teaming and research are borrowed until volume justifies a permanent hire. Define every role by mission, responsibilities, competencies and interfaces, and map it to the NIST NICE Framework (Workforce Framework for Cybersecurity) so that hiring, training and career paths use a shared language, while recognizing that NICE treats AI security as a competency area across roles rather than a single job. Treat public job descriptions as dated evidence of how the market is organizing this work, not as standards. Size the team from demand drivers such as Tier 3 and Tier 4 volume, agent footprint and paved-road maturity, and revisit that sizing every quarter. Above all, build a culture in which people are safe to raise concerns and stop weak ideas, while every decision still has one named owner.

Module 21: Communication, Training, and Stakeholder Mobilization

Executive takeaway. AI security is adopted, not installed. The organization needs a deliberate engagement system: a stakeholder map, messages tailored to each audience, a role-based curriculum from awareness to specialist depth, and recurring channels (office hours, clinics, lunch- and-learns, a community of practice, champions) that make security advice early, cheap and local. Every review must end in written feedback that states the decision, the rationale, the required action, the owner, the date and the retest criteria. Repeated friction must be converted into patterns, automation and training rather than argued case by case. Leaders own the change: they set incentives that reward early risk disclosure, protect people who raise concerns, and treat developer backlash as data about the program's design. The measure of success is not attendance. It is whether teams engage earlier, repeat fewer findings and choose the paved road because it is faster.

Module 22: Metrics, Maturity, Roadmap, and the Next Three Years

Executive takeaway. Measure outcomes and risk reduction, not activity, and segment every measure by risk tier so that a strong Tier 1 fast lane cannot hide a weak Tier 4 system. Report through a layered architecture, from a weekly operational pulse to a quarterly board brief and an annual management review, in which every report states the decision it requires. Judge the program against a five-level maturity model (Ad hoc, Defined, Operational, Measured, Adaptive), and set a risk-differentiated target: Level 4 for the enterprise and Level 4-5 for critical AI platforms and security operations within 24-36 months. Execute through a phased roadmap: establish control, build reusable capabilities and operationalize in the first 90 days, then standardize by month six, operationalize by month twelve, and scale and mature through month thirty-six. Six executive decisions cannot wait, and funding must treat shared controls as one multi-year portfolio. Keep a dated watch list of the standards, laws and protocols that will change during those three years, because several of them will.