diff --git a/ai-governance/references/governance-operating-model.md b/ai-governance/references/governance-operating-model.md index 4ea9b8c..a7e0aac 100644 --- a/ai-governance/references/governance-operating-model.md +++ b/ai-governance/references/governance-operating-model.md @@ -106,8 +106,8 @@ confirms the same three-tier pattern for AI: an *enterprise data committee* (executives, meeting quarterly, accountable to the CEO and board) from an *enterprise data council* (senior leaders one to two levels below the C-suite, doing the detailed policy and monitoring work and reporting up to the committee). - For AI this is the AI ethics or AI risk council that brings together legal, risk, - compliance, privacy, security, data, product, and engineering. + For AI this is the AI ethics or AI risk council that convenes compliance, legal, privacy, risk, + security, data, product, and engineering. - **Stewards / operating owners.** The people who run day-to-day controls and drive implementation inside their domains. @@ -174,7 +174,7 @@ There is no single correct answer. The books and the current research converge o principle that the best model is the one that drives progress and maturity for your specific organization, and that most organizations try several arrangements before settling on one. Current research adds that there is no one prescribed AI operating model either: the balance -between a CAIO, a governance council, and a board committee varies, but authoritative +between a CAIO, the governance council, and a board committee is not uniform, but authoritative guidance consistently requires documented roles, clear accountability that reaches the board, and periodic reporting. @@ -185,10 +185,10 @@ Governance Handbook* treats maturity assessment as an annual exercise that measu organization across governance dimensions (using models such as DCAM), gives each dimension a level, surfaces gaps, and reports results up to the executive team and board in aggregate. Current research reinforces the idea for AI: NIST's AI RMF functions (govern, map, measure, -manage) can be read as a maturity ladder — a nascent organization merely identifies its +manage) function like a maturity ladder — a nascent organization merely identifies its systems, while a mature one governs, maps, measures, and manages AI risk continuously and feeds results back into improvement. ISO/IEC 42001 provides a certifiable management-system -structure built on the Plan-Do-Check-Act cycle, which is itself a maturity mechanism. The +structure built around a Plan-Do-Check-Act cycle, which is itself a maturity mechanism. The practical takeaway is that the operating model should include an explicit way to score itself and a roadmap to move up, not a one-time compliance checkbox. (This skill ships the `governance-maturity.py` script to operationalize such a self-assessment.) @@ -233,7 +233,7 @@ adjustments, and current research points to where AI-specific attention is neede oversight. - **Make third-party risk first-class.** Much of an organization's AI footprint is procured, embedded, or inherited through vendors and M&A, so supply-chain diligence and vendor - accountability must be part of the operating model from the start (see + accountability must be embedded in the operating model from the start (see `procurement-third-party-and-board-oversight.md`). - **Extend stewardship to models.** Assign a named owner to every model and dataset, using the same business/technical steward split the books describe for data. diff --git a/ai-governance/references/llm-and-agent-security.md b/ai-governance/references/llm-and-agent-security.md index 2d49c37..e041157 100644 --- a/ai-governance/references/llm-and-agent-security.md +++ b/ai-governance/references/llm-and-agent-security.md @@ -56,15 +56,15 @@ uncompromised. Neither choice is safe by default; each just moves where the boun ## Prompt Injection -Prompt injection is the manipulation of an LLM or agent through crafted inputs so that it ignores -its instructions, leaks data, bypasses policy, or takes actions the operator never intended. It is -the single most consistently ranked risk in OWASP's taxonomy and is widely described as the most -common AI exploit. *The Developer's Playbook* distinguishes the two delivery classes: +Prompt injection steers an LLM or agent using adversarial input — overriding developer +guidance, exposing protected information, circumventing policy, or triggering actions the operator +did not authorize. It ranks at or near the top of OWASP's risk lists and is commonly called the +field's most frequent AI exploit. *The Developer's Playbook* distinguishes the two delivery classes: - **Direct injection** ("jailbreaking"): the attacker controls the input channel, crafting a prompt to override the system prompt or reveal hidden instructions. *Beyond the Algorithm* notes that this can let an attacker target backend systems the LLM can reach. -- **Indirect injection**: malicious instructions are planted in content the model reads as part of +- **Indirect injection**: malicious instructions are hidden inside content the model ingests as part of its task — a retrieved document, a web page, a tool's output. This is the more dangerous variant for agents, because the untrusted material often arrives through a channel the system trusts, and it can be invisible to humans when only the model processes the text. @@ -126,12 +126,12 @@ than an output bug, and breaks it into three forms: what the application requires. The mitigations center on **least agency**, the agentic counterpart to least privilege: scope each -agent's tools and permissions narrowly, require human approval for high-impact actions, isolate -agents so a compromised one cannot move laterally, and log and monitor decisions and tool calls so -misuse is detectable. "current research": the OWASP GenAI LLM Top 10 2026 ranks excessive agency -third, and in May 2026 a Five Eyes group of national cybersecurity agencies (CISA, NSA, and allied -cyber bodies) issued their first joint guidance on adopting agentic AI, recommending cautious -adoption with identity, access, and monitoring controls. +agent's tools and permissions narrowly, require human sign-off for high-impact actions, keep +agents isolated so a takeover cannot spread across the fleet, and log tool use and decisions so +abuse leaves a trail. "current research": the OWASP GenAI LLM Top 10 2026 ranks excessive agency +third, and in mid-2026 the Five Eyes nations' cyber agencies (CISA, NSA, and counterparts) published +their first joint guidance on agentic AI, urging measured rollout backed by identity, access, and +monitoring safeguards. ## Denial of Service and Unbounded Consumption @@ -172,9 +172,9 @@ configuration-file attacks that alter model behavior without touching the model ## Red-Teaming LLM and Agentic Systems -Red-teaming is a structured, adversarial evaluation that probes an AI system for failures — -prompt injection, jailbreaks, data leaks, unsafe outputs, bias, and unintended tool use — before an -attacker finds them. *Beyond the Algorithm* describes it as crafting prompts that trigger harmful +A red team carries out a structured, adversarial evaluation that probes an AI system for failures — +prompt injection, jailbreaks, data leaks, unsafe outputs, bias, and misuse of tools — before a real +attacker exploits them. *Beyond the Algorithm* describes it as crafting prompts that trigger harmful or revealing behavior and notes it is creative and resource-intensive. The playbook adds that a red team simulates realistic attacks and drives improvements, and it is complementary to traditional penetration testing: a pen test is a point-in-time assessment of exploitable weaknesses, while red @@ -182,23 +182,22 @@ teaming is an ongoing, creative effort to probe AI-specific behaviors that autom red team exercises areas like hallucination triggers, bias, excessive agency, and injection with an external, adversarial perspective that internal teams focused on functionality often lack. -Practitioners caution that red-teaming is necessary but not sufficient: because it tends to find -known vulnerability classes, it can create a false sense of security against novel attacks, -especially as models and agent architectures change quickly. Effective programs combine red-teaming -with layered prompt-injection defenses, least-agency design, monitoring and incident response, and -continuous re-evaluation rather than treating a single pass as a safety certification. "current -research": government bodies have institutionalized this practice — the U.K. AI Security Institute -and the U.S. AI Safety Institute (now NIST's Center for AI Standards and Innovation, or CAISI) both -perform technical adversarial evaluation of models and agents, and OWASP maintains a red-teaming -taxonomy as a companion to its Top 10. +Practitioners warn that red-teaming alone is not a guarantee: it mostly surfaces known classes of +weakness, so passing a red-team round can breed overconfidence about novel attacks, especially as +models and agents evolve. Strong programs pair red-teaming with layered injection defenses, +least-privilege agency design, active monitoring, and continuous re-evaluation, rather than treating +one session as proof of safety. "current research": government bodies have institutionalized this +practice — the U.K. AI Security Institute and its U.S. counterpart, the AI Safety Institute (now +NIST's Center for AI Standards and Innovation, or CAISI) both run technical adversarial evaluations, +and OWASP ships a red-teaming taxonomy alongside its Top 10. ## The Current OWASP Top 10 (verified) OWASP's Top 10 for LLM Applications is the default risk checklist for the field, but its ranking is -volatile between editions — the research note and the books both stress that treating any published -list as a fixed checklist is unsafe. This section is "current research" verified against the OWASP +volatile between editions — the research note and the books both stress that no published +ranking should be treated as a frozen checklist. This section is "current research" verified against the OWASP GenAI Security Project's release, which moved from expert-vote-only ranking to blending expert -judgment with thousands of documented incidents. The ordering below is the OWASP GenAI LLM Top 10 +judgment with thousands of documented incidents. The ordering below follows the OWASP GenAI LLM Top 10 2026 and should be re-checked before it is asserted as current; earlier editions differed, and later ones will again. @@ -226,7 +225,7 @@ improper output handling. - **`privacy-and-data-governance.md`** — the data-protection controls (exposure, retention, PETs) that security defends. - **`ai-lifecycle-governance.md`** — where security reviews and red-teaming sit in the stage gates. -- **`risk-management-and-frameworks.md`** — NIST AI RMF and its Generative AI Profile, into which +- **`risk-management-and-frameworks.md`** — NIST AI RMF, including its Generative AI Profile, into which the OWASP categories map. - **`regulatory-landscape.md`** — current law that turns some of these risks into legal duties. diff --git a/ai-governance/references/privacy-and-data-governance.md b/ai-governance/references/privacy-and-data-governance.md index e4a3783..024382a 100644 --- a/ai-governance/references/privacy-and-data-governance.md +++ b/ai-governance/references/privacy-and-data-governance.md @@ -191,7 +191,7 @@ The core PETs the book and current practice converge on include: | Technique | What it does | Typical use | |---|---|---| | Differential privacy (DP) | Adds calibrated noise so that including or excluding any one record barely changes outputs, bounding what an adversary can infer | Training and query-time privacy; measured by epsilon (ε) | -| K-anonymity | Groups records so each is indistinguishable from at least k−1 others on identifying attributes | Publishing or sharing structured data | +| K-anonymity | Groups records so no row is alone: each is one of at least k−1 peers on identifying attributes | Publishing or sharing structured data | | Anonymization / pseudonymization | Removes or replaces identifiers; pseudonymization is reversible with a key, anonymization is not | Pre-processing before sharing or analysis | | Encryption / access control | Protects data and model weights in storage and transit; restricts who can reach them | Model storage and access privacy | | Federated learning | Trains on distributed data without centralizing raw records, exchanging only model updates | Keeping data local while still learning | diff --git a/ai-governance/templates/board-ai-governance-report.md b/ai-governance/templates/board-ai-governance-report.md index 40b6e9a..5129a2b 100644 --- a/ai-governance/templates/board-ai-governance-report.md +++ b/ai-governance/templates/board-ai-governance-report.md @@ -106,4 +106,4 @@ Give the board a clear, bounded set of asks so the meeting produces decisions ra To complete this report: fill every labeled field, prepare the executive summary with the trended metric set that backs each claim, populate the inventory and tiering view from the registry, list material risks and incidents with severity and status, report compliance obligations and audit findings honestly, summarize the third-party and supply-chain posture including concentration, describe the state of governance operations, and chart progress against the board-approved goals. End with a bounded set of decisions or escalations for the board. Management must own and be accountable for the report's accuracy; the board reviews, asks questions, and challenges the answers. Rebuild the report on the fixed cadence you set and whenever a material incident or change warrants a special briefing. -> **Synthesized from** `references/procurement-third-party-and-board-oversight.md`, which draws on *The AI Product Manager's Handbook* and *Developing Cybersecurity Programs and Policies in an AI-Driven World*, together with `research-org-board-governance.md` (current to August 2026). Fillable artifact of the `ai-governance` skill; educational context, not legal advice. +> **Synthesized from** `references/procurement-third-party-and-board-oversight.md`, which draws on *The AI Product Manager's Handbook* and *Developing Cybersecurity Programs and Policies*, together with `research-org-board-governance.md` (current to August 2026). Fillable artifact of the `ai-governance` skill; educational context, not legal advice. diff --git a/ai-governance/templates/governance-charter.md b/ai-governance/templates/governance-charter.md index a529ba2..ce082b3 100644 --- a/ai-governance/templates/governance-charter.md +++ b/ai-governance/templates/governance-charter.md @@ -31,7 +31,7 @@ State, in one to three sentences, why the council exists and what outcomes it is ## Membership -List the representative roles and named individuals. A cross-functional council should bring together legal, risk, compliance, privacy, security, data, product, and engineering. Note alternates so the body is never blocked by a single person's absence. +List the representative roles and named individuals. A cross-functional council should bring together legal, compliance, risk, privacy, security, data, product, and engineering. Note alternates so the body is never blocked by a single person's absence. | Role | Representative | Alternates | Term / rotation | |---|---|---|---| diff --git a/ai-governance/templates/model-card.md b/ai-governance/templates/model-card.md index 153cf06..83ab8e2 100644 --- a/ai-governance/templates/model-card.md +++ b/ai-governance/templates/model-card.md @@ -47,7 +47,7 @@ Document what the model was trained on and what it consumes in production, so it ## Performance And Evaluation -Record how the model was evaluated, on what data, and how it performed — broken out by relevant subgroups so the spread across groups is visible rather than hidden in a single average. +Record how the model was evaluated, on what data, and how it performed — broken out by relevant subgroups so the spread across groups is visible rather than being collapsed into one average. - Evaluation procedure: - Primary performance metrics and thresholds: diff --git a/ai-governance/templates/model-risk-assessment.md b/ai-governance/templates/model-risk-assessment.md index 513331e..9ed1f3b 100644 --- a/ai-governance/templates/model-risk-assessment.md +++ b/ai-governance/templates/model-risk-assessment.md @@ -1,6 +1,6 @@ # Model Risk Assessment & Tiering Worksheet -> **Confidentiality:** A completed assessment records inherent and residual risk, mitigations, and a tiering decision for a specific model. Store it with access controls appropriate to governance and board-oversight information. This template implements the NIST AI Risk Management Framework (AI RMF) functions — Govern, Map, Measure, Manage — and the model risk tiering discipline described in `references/risk-management-and-frameworks.md`. It is a working worksheet, not a legal opinion; framework details should be confirmed against current NIST and ISO releases at use time. +> **Confidentiality:** A completed assessment records inherent and residual risk, mitigations, and a tiering decision for a specific model. Store it with access controls appropriate to governance and board-oversight information. This template implements the NIST AI Risk Management Framework functions — Govern, Map, Measure, Manage — and the model risk tiering discipline described in `references/risk-management-and-frameworks.md`. It is a working worksheet, not a legal opinion; framework details should be confirmed against current NIST and ISO releases at use time. ## When To Use @@ -49,7 +49,7 @@ Describe what trains and feeds the model. Sensitive, high-volume, or personal da Classify how much the model decides and how consequential its output is. This is a principal driver of the inherent risk tier. -- Level of autonomy: +- Level of autonomy: - Decision type: - Decision impact: - Opportunity for human override: diff --git a/ai-governance/templates/third-party-due-diligence.md b/ai-governance/templates/third-party-due-diligence.md index 0529167..07dbfa3 100644 --- a/ai-governance/templates/third-party-due-diligence.md +++ b/ai-governance/templates/third-party-due-diligence.md @@ -105,4 +105,4 @@ Weigh how deep this diligence must go and who must sign off, driven by inherent To complete this questionnaire: fill every labeled field, classify the engagement and assign a provisional risk tier, characterize the provider and its jurisdiction, enumerate the data flows and the vendor's handling commitments, review the model's provenance and capabilities, record the security and privacy evidence you actually obtained, confirm the incident, reliability, and exit terms, and route the outcome to the reviewing authority named above. Obtain the required approvals and record the decision as the source-of-record that every later onboarding, monitoring, and audit step calibrates against. Revisit the questionnaire whenever the system, the vendor, its subprocessors, or the surrounding risk profile changes materially. -> **Synthesized from** `references/procurement-third-party-and-board-oversight.md`, which draws on *The AI Product Manager's Handbook* and *Developing Cybersecurity Programs and Policies in an AI-Driven World*, together with `research-org-board-governance.md`. Fillable artifact of the `ai-governance` skill; educational context, not legal advice. +> **Synthesized from** `references/procurement-third-party-and-board-oversight.md`, which draws on *The AI Product Manager's Handbook* and *Developing Cybersecurity Programs and Policies*, together with `research-org-board-governance.md`. Fillable artifact of the `ai-governance` skill; educational context, not legal advice. diff --git a/ai-governance/templates/use-case-intake-form.md b/ai-governance/templates/use-case-intake-form.md index 00973ed..6b032b2 100644 --- a/ai-governance/templates/use-case-intake-form.md +++ b/ai-governance/templates/use-case-intake-form.md @@ -46,7 +46,7 @@ Describe the data that trains and feeds the system. Sensitive, high-volume, or p Classify how much the system decides and how consequential its output is. This drives the tier. -- Level of autonomy: +- Level of autonomy: - Decision type: - Decision impact: - Scale of exposure: