Risks looking good.

Author: robmoffat

cue/gemara/README.md .dev/cue/gemara/README.mdcue/gemara/README.md renamed to .dev/cue/gemara/README.md

@@ -0,0 +1,137 @@
+
+# GOVERN — Organizational risk governance
+
+## GOVERN 1 — Risk management policies and processes exist
+
+* **1.1** Legal/regulatory AI requirements are understood and documented.
+* **1.2** Trustworthy-AI characteristics are embedded into org policies and practices.
+* **1.3** Required level of AI risk management is determined by risk tolerance.
+* **1.4** Transparent risk-management procedures and controls are established.
+* **1.5** Ongoing monitoring, review cadence, and responsibilities are defined.
+* **1.6** AI system inventory exists and is resourced by risk priority.
+* **1.7** Safe decommissioning/phase-out procedures are defined.
+
+➡ **Theme:** institutionalize lifecycle AI risk governance.
+
+---
+
+## GOVERN 2 — Accountability structures
+
+* **2.1** Roles, responsibilities, and reporting lines for AI risk are documented.
+* **2.2** Personnel and partners receive AI risk-management training.
+* **2.3** Executive leadership is accountable for AI risk decisions.
+
+➡ **Theme:** governance must reach the C-suite.
+
+---
+
+## GOVERN 3 — Workforce diversity & inclusion in risk
+
+* **3.1** Diverse, interdisciplinary teams inform AI risk decisions.
+* **3.2** Human-AI oversight roles and responsibilities are clearly defined.
+
+➡ **Theme:** socio-technical risk requires diverse perspectives.
+
+---
+
+## GOVERN 4 — Risk-aware organizational culture
+
+* **4.1** Safety-first and critical-thinking culture is embedded.
+* **4.2** AI risks and impacts are documented and communicated.
+* **4.3** Testing, incident detection, and information-sharing practices exist.
+
+➡ **Theme:** culture is a control surface.
+
+---
+
+## GOVERN 5 — External engagement
+
+* **5.1** Feedback from affected stakeholders is collected and integrated.
+* **5.2** Adjudicated external feedback informs system design and updates.
+
+➡ **Theme:** legitimacy requires stakeholder input.
+
+---
+
+## GOVERN 6 — Third-party & supply-chain risk
+
+* **6.1** Policies address third-party IP, data, and AI risks.
+* **6.2** Contingency plans exist for third-party failures/incidents.
+
+➡ **Theme:** AI supply chain = risk multiplier.
+
+---
+
+# MAP — Context and risk identification
+
+## MAP 1 — Context establishment
+
+* **1.1** Intended use, impacts, laws, users, and assumptions documented.
+* **1.2** Diverse interdisciplinary context-setting participation ensured.
+* **1.3** Organizational mission/goals for AI documented.
+* **1.4** Business value/use context defined or re-evaluated.
+* **1.5** Risk tolerance determined and documented.
+* **1.6** Socio-technical system requirements defined.
+
+➡ **Theme:** risk begins with context clarity.
+
+---
+
+## MAP 2 — AI system categorization
+
+* **2.1** Tasks/methods (e.g., generative, classifier) defined.
+* **2.2** Knowledge limits, human oversight, and usage constraints documented.
+* **2.3** Scientific integrity and TEVV considerations documented.
+
+➡ **Theme:** know what kind of AI you built.
+
+---
+
+## MAP 3 — Capabilities, benefits, and costs
+
+* **3.1** Expected benefits documented.
+* **3.2** Expected harms and non-monetary costs documented.
+* **3.3** Application scope specified.
+* **3.4** Operator proficiency requirements defined.
+* **3.5** Human-oversight processes defined.
+
+➡ **Theme:** capability ≠ acceptability.
+
+---
+
+## MAP 4 — Component-level risk mapping
+
+* **4.1** Legal/technical risks of components and third-party assets mapped.
+* **4.2** Internal controls for components documented.
+
+➡ **Theme:** decompose the system to see risk.
+
+---
+
+## MAP 5 — Impact characterization
+
+* **5.1** Likelihood and magnitude of impacts identified.
+* **5.2** Continuous stakeholder engagement mechanisms exist.
+
+➡ **Theme:** quantify harm before deployment.
+
+---
+
+# MEASURE — Risk analysis and validation
+
+## MEASURE 1 — Metrics and methodologies
+
+* **1.1** Metrics selected for highest-priority risks.
+* **1.2** Metric effectiveness and controls regularly reassessed.
+* **1.3** Independent/internal/external experts participate in assessment.
+
+➡ **Theme:** measurement must be credible.
+
+---
+
+## MEASURE 2 — Trustworthiness evaluation
+
+* **2.1** Test sets, metrics, and tools documented.
+* **2.2** Human-subject evaluations meet protections/requirements.
+
+➡ **Theme:** TEVV formalizes AI assurance.

cue/gemara/base.cue .dev/cue/gemara/base.cuecue/gemara/base.cue renamed to .dev/cue/gemara/base.cue

@@ -0,0 +1,64 @@
+
+# OWASP Top 10 for Agentic Applications — brief summaries
+
+## ASI01 — Agent Goal Hijack
+
+Attackers manipulate an agent’s **objectives, plans, or decision paths** through prompt injection, malicious artifacts, deceptive tool output, or poisoned data.
+Unlike classic prompt injection that changes one response, this redirects **multi-step autonomous behavior** toward harmful outcomes. 
+
+---
+
+## ASI02 — Tool Misuse and Exploitation
+
+Agents misuse **legitimate tools within their permissions**—for example deleting data, over-invoking APIs, or exfiltrating information—due to unsafe delegation, injection, or ambiguity.
+The danger lies in **unsafe application of authorized capability**, not privilege escalation. 
+
+---
+
+## ASI03 — Identity and Privilege Abuse
+
+Dynamic delegation, cached credentials, and cross-agent trust allow attackers to **escalate access or impersonate identities**, bypassing least-privilege controls and executing unauthorized actions.
+This reflects an architectural gap between **human-centric IAM and autonomous agents**. 
+
+---
+
+## ASI04 — Agentic Supply-Chain Vulnerabilities
+
+Third-party models, tools, prompts, agents, registries, or datasets may be **malicious, compromised, or tampered with**, especially because agentic systems load components **dynamically at runtime**, expanding the attack surface. 
+
+---
+
+## ASI05 — Unexpected Code Execution (RCE)
+
+Generated or injected code can be **executed by the agent**, leading to remote code execution, sandbox escape, persistence, or host compromise—often bypassing traditional controls because execution is **agent-driven and real-time**. 
+
+---
+
+## ASI06 — Memory & Context Poisoning
+
+Attackers corrupt stored **memory, embeddings, summaries, or RAG context**, causing persistent bias, unsafe reasoning, or data leakage across sessions and agents.
+This is **long-term contamination**, not a one-time prompt attack. 
+
+---
+
+## ASI07 — Insecure Inter-Agent Communication
+
+Weak authentication, integrity, or confidentiality in **agent-to-agent messaging** enables interception, spoofing, replay, or semantic manipulation, compromising coordination across distributed agent systems. 
+
+---
+
+## ASI08 — Cascading Failures
+
+A single hallucination, poisoned input, or compromised component can **propagate across autonomous agents**, amplifying into system-wide failure because agents plan, persist, and delegate without human checkpoints. 
+
+---
+
+## ASI09 — Human-Agent Trust Exploitation
+
+Attackers exploit **human trust, authority bias, or anthropomorphism** to manipulate users into approving harmful actions, disclosing secrets, or making unsafe decisions—while the agent’s role remains hard to trace. 
+
+---
+
+## ASI10 — Rogue Agents
+
+Agents that become **malicious, misaligned, collusive, or self-propagating** deviate from intended behavior and sabotage workflows, leak data, or manipulate systems—even if individual actions appear legitimate. 

cue/gemara/layer-2.cue .dev/cue/gemara/layer-2.cuecue/gemara/layer-2.cue renamed to .dev/cue/gemara/layer-2.cue

@@ -0,0 +1,86 @@
+# OWASP Top 10 for LLM Applications 2025 — brief summaries
+
+## LLM01 — Prompt Injection
+
+Malicious or unintended inputs manipulate model behavior, bypass safeguards, expose data, trigger tool use, or alter decisions—even when hidden in external content or multimodal inputs.
+Mitigation relies on constrained behavior, strict validation, filtering, least-privilege access, and human approval for high-risk actions. 
+
+---
+
+## LLM02 — Sensitive Information Disclosure
+
+LLMs may reveal **PII, credentials, proprietary data, or training information** through outputs or model behavior, causing privacy or IP breaches.
+Defenses include sanitization, strict access control, privacy-preserving learning, transparency, and secure configuration. 
+
+---
+
+## LLM03 — Supply Chain
+
+Risks arise from **third-party models, datasets, libraries, fine-tuning adapters, or cloud infrastructure**, which may be vulnerable, poisoned, tampered, or malicious.
+Mitigation centers on provenance, red-teaming, SBOMs, patching, licensing governance, and integrity verification. 
+
+---
+
+## LLM04 — Data and Model Poisoning
+
+Attackers manipulate **training, fine-tuning, or embedding data** to introduce bias, backdoors, or degraded behavior—potentially creating sleeper-agent-style triggers.
+Controls include dataset provenance tracking, validation, sandboxing, anomaly detection, versioning, and adversarial testing. 
+
+---
+
+## LLM05 — Improper Output Handling
+
+Unsanitized LLM outputs passed into downstream systems can enable **XSS, SQL injection, SSRF, privilege escalation, or remote code execution**.
+Secure design treats model output as untrusted input, enforcing validation, encoding, parameterization, monitoring, and zero-trust handling. 
+
+---
+
+## LLM06 — Excessive Agency
+
+Granting LLMs **too much autonomy, functionality, or permission** enables damaging real-world actions triggered by hallucination, injection, or ambiguity.
+Mitigation focuses on minimizing extensions, permissions, and autonomy, enforcing authorization externally, and requiring human approval for critical actions. 
+
+---
+
+## LLM07 — System Prompt Leakage
+
+System prompts may expose **secrets, permissions, architecture, or filtering logic**, enabling attackers to bypass controls or escalate privileges.
+Security must not rely on hidden prompts; sensitive data and enforcement should reside outside the LLM. 
+
+---
+
+## LLM08 — Vector and Embedding Weaknesses
+
+Weaknesses in **RAG pipelines, embeddings, or vector stores** can enable data leakage, poisoning, or retrieval manipulation that corrupts model grounding and outputs.
+Securing retrieval infrastructure and validating embedded data are key defenses. 
+
+---
+
+## LLM09 — Misinformation
+
+LLMs can generate **incorrect, biased, or fabricated information** that influences users or decisions, creating reputational, legal, or operational harm.
+Mitigation requires validation, provenance, monitoring, and human oversight of high-impact outputs. 
+
+---
+
+## LLM10 — Unbounded Consumption
+
+LLM usage may cause **excessive resource consumption, denial-of-wallet costs, or uncontrolled scaling**, expanding traditional DoS into economic and operational risk.
+Controls include rate limiting, quotas, monitoring, and resource governance. 
+
+---
+
+# Structural insight (useful for your Risk-First framing)
+
+Compared with the **Agentic Top 10**, this list focuses more on:
+
+* **Model- and data-centric vulnerabilities**
+* **Application-level security failures**
+* **Resource and information risks**
+
+— whereas agentic risks emphasize **autonomy, delegation, and systemic behavior**.
+
+This distinction is useful for framing:
+
+➡ **LLM risk = information & pipeline security**
+➡ **Agentic risk = autonomous action & system control**

cue/gemara/mapping.cue .dev/cue/gemara/mapping.cuecue/gemara/mapping.cue renamed to .dev/cue/gemara/mapping.cue

@@ -0,0 +1,74 @@
+#!/bin/bash
+# Validate Gemara front matter against CUE schema
+# Usage: ./.dev/scripts/validate.sh
+
+set -e
+
+cd "$(dirname "$0")/../.."
+
+# Check dependencies
+command -v cue >/dev/null 2>&1 || { echo "❌ CUE not installed. Run: brew install cue"; exit 1; }
+command -v yq >/dev/null 2>&1 || { echo "❌ yq not installed. Run: brew install yq"; exit 1; }
+
+ERRORS=0
+
+validate_file() {
+  local file="$1"
+  local schema="$2"
+  
+  # Extract front matter and get gemara as JSON
+  frontmatter=$(awk '/^---$/{if(p)exit;p=1;next}p' "$file")
+  gemara_yaml=$(echo "$frontmatter" | yq '.gemara' 2>/dev/null)
+  
+  if [ "$gemara_yaml" = "null" ] || [ -z "$gemara_yaml" ]; then
+    echo "  ⚠ $file - no gemara front matter"
+    return 0
+  fi
+  
+  # Write gemara YAML to temp file for validation
+  tmpfile=$(mktemp).yaml
+  echo "$gemara_yaml" > "$tmpfile"
+  
+  if cue vet "$tmpfile" ./.dev/cue/gemara/*.cue -d "$schema" 2>/dev/null; then
+    echo "  ✓ $file"
+    rm -f "$tmpfile"
+    return 0
+  else
+    echo "  ❌ $file - validation failed"
+    cue vet "$tmpfile" ./.dev/cue/gemara/*.cue -d "$schema" 2>&1 | head -5 | sed 's/^/    /'
+    rm -f "$tmpfile"
+    return 1
+  fi
+}
+
+echo "🔍 Validating risk files against #Threat schema..."
+for file in risks/*.md; do
+  if [ -f "$file" ]; then
+    validate_file "$file" "#Threat" || ERRORS=$((ERRORS + 1))
+  fi
+done
+
+echo ""
+echo "🔍 Validating practice files against #Control schema..."
+for file in practices/*.md; do
+  if [ -f "$file" ]; then
+    validate_file "$file" "#Control" || ERRORS=$((ERRORS + 1))
+  fi
+done
+
+echo ""
+echo "🔍 Validating capability files against #Capability schema..."
+for file in capabilities/*.md; do
+  if [ -f "$file" ]; then
+    validate_file "$file" "#Capability" || ERRORS=$((ERRORS + 1))
+  fi
+done
+
+echo ""
+if [ $ERRORS -eq 0 ]; then
+  echo "✅ All validations passed!"
+  exit 0
+else
+  echo "❌ $ERRORS validation error(s) found"
+  exit 1
+fi

cue/gemara/metadata.cue .dev/cue/gemara/metadata.cuecue/gemara/metadata.cue renamed to .dev/cue/gemara/metadata.cue

@@ -22,4 +22,4 @@ jobs:
           sudo chmod +x /usr/local/bin/yq
 
       - name: Validate Gemara front matter
-        run: ./scripts/validate.sh
+        run: ./.dev/scripts/validate.sh