From bc1f2ff71353b912c1808301b1189f418da470e5 Mon Sep 17 00:00:00 2001 From: Daniel Smith Date: Tue, 12 May 2026 15:09:45 -0700 Subject: [PATCH] Add consolidated Agentic AI Security curriculum articles to personal site Publish six long-form articles sourced from ClawQL security-best-practices modules, with a generator script and committed pillar bodies. Optional LinkedIn URL and syndication footer support home and article pages. --- personal-site/package.json | 1 + .../generate-agentic-security-pillars.mjs | 185 ++++++++++++++++++ .../src/app/articles/[slug]/page.tsx | 36 ++-- personal-site/src/app/page.tsx | 27 ++- ...ecurityCurriculumPillarBodies.generated.ts | 17 ++ personal-site/src/lib/articles.ts | 2 +- personal-site/src/lib/site.ts | 127 +++++++++++- 7 files changed, 372 insertions(+), 23 deletions(-) create mode 100644 personal-site/scripts/generate-agentic-security-pillars.mjs create mode 100644 personal-site/src/lib/agenticSecurityCurriculumPillarBodies.generated.ts diff --git a/personal-site/package.json b/personal-site/package.json index dc4ba3f..f64c244 100644 --- a/personal-site/package.json +++ b/personal-site/package.json @@ -5,6 +5,7 @@ "scripts": { "dev": "next dev", "build": "next build", + "generate:agentic-security-pillars": "node scripts/generate-agentic-security-pillars.mjs", "start": "next start", "lint": "tsc --noEmit", "test": "vitest run", diff --git a/personal-site/scripts/generate-agentic-security-pillars.mjs b/personal-site/scripts/generate-agentic-security-pillars.mjs new file mode 100644 index 0000000..4b7cb36 --- /dev/null +++ b/personal-site/scripts/generate-agentic-security-pillars.mjs @@ -0,0 +1,185 @@ +/** + * Concatenates ClawQL security-best-practices-series modules into six long-form + * bodies for the personal site. Run from repo root or personal-site: + * + * CLAWQL_ROOT=/path/to/ClawQL node personal-site/scripts/generate-agentic-security-pillars.mjs + * + * Default CLAWQL_ROOT: ../../ClawQL relative to personal-site (sibling repo). + */ +import fs from 'node:fs' +import path from 'node:path' +import { fileURLToPath } from 'node:url' + +const __dirname = path.dirname(fileURLToPath(import.meta.url)) +const personalSiteRoot = path.resolve(__dirname, '..') +const defaultClawql = path.resolve(personalSiteRoot, '../../ClawQL') +const CLAWQL_ROOT = process.env.CLAWQL_ROOT || defaultClawql +const seriesDir = path.join( + CLAWQL_ROOT, + 'docs/security/security-best-practices-series', +) + +const DOCS_HUB = 'https://docs.clawql.com/security/best-practices' + +const pillars = [ + { + slug: 'agentic-ai-security-supply-chain-and-admission', + title: + 'Agentic AI Security, Part 1: Supply Chain, Golden Images, and Admission Control', + intro: `This long-form article merges **modules 1–3** of the [Agentic AI Security Curriculum](${DOCS_HUB}) into one place: why digest pinning and private mirrors matter for agent and MCP platforms, how golden images and CI signing reduce drift, and how admission controllers enforce policy before workloads run. Each section links to the original module on ClawQL Docs for deeper diagrams and commands.`, + modules: [ + '01-supply-chain-pinning-mirror-registry.md', + '02-golden-images-distroless-pipelines.md', + '03-cluster-admission-control-signing-policy.md', + ], + }, + { + slug: 'agentic-ai-security-identity-zero-trust', + title: + 'Agentic AI Security, Part 2: Identity, Least Privilege, and Zero Trust', + intro: `**Modules 4–6** cover scoped identities for agents and tools, zero-trust networking and policy basics, and advanced patterns (Vault, HSMs, provenance) that matter when LLMs orchestrate sensitive APIs. Consolidated here with links to each canonical module.`, + modules: [ + '04-least-privilege-scoped-identities.md', + '05-zero-trust-fundamentals.md', + '06-advanced-zero-trust-vault-hsm-provenance.md', + ], + }, + { + slug: 'agentic-ai-security-mesh-sandbox-mcp', + title: + 'Agentic AI Security, Part 3: Service Mesh, Sandboxing, and MCP Runtime Protection', + intro: `**Modules 7–9** address enforcing identity and policy in the mesh (RBAC, mTLS, Istio), choosing sandbox boundaries (Kata, gVisor, and tradeoffs), and hardening MCP-style runtimes with gateways and runtime protection. Read end-to-end here, then open any module on docs for the full detail.`, + modules: [ + '07-rbac-mtls-istio-service-mesh.md', + '08-sandboxing-kata-gvisor-tradeoffs.md', + '09-mcp-runtime-protection-panguard-atr.md', + ], + }, + { + slug: 'agentic-ai-security-data-models-observability', + title: + 'Agentic AI Security, Part 4: Data Classification, Model Integrity, and Runtime Monitoring', + intro: `**Modules 10–12** tie data handling (classification, PII, logs), model supply chain and weight verification, and runtime monitoring together—the stack teams need when agents read documents, call tools, and leave rich audit trails.`, + modules: [ + '10-data-classification-pii-redaction-logs.md', + '11-model-integrity-verifying-weights.md', + '12-runtime-monitoring-observability.md', + ], + }, + { + slug: 'agentic-ai-security-operations-and-production', + title: + 'Agentic AI Security, Part 5: Incident Response, Automation, GPU, Workstations, and Production', + intro: `**Modules 13–17** span automated containment, IR and recovery (PICERL), GPU abuse controls, secure workstation and local development practices, and production deployment patterns for full agent stacks.`, + modules: [ + '13-automated-response-containment.md', + '14-incident-response-recovery-picerl.md', + '15-gpu-resource-protection.md', + '16-workstation-local-development-security.md', + '17-production-deployment-secure-full-stack.md', + ], + }, + { + slug: 'agentic-ai-security-governance-and-owasp-agentic', + title: + 'Agentic AI Security, Part 6: Threat Modeling, OWASP Agentic Top 10, and Quarterly Review', + intro: `**Modules 18–20** focus on STRIDE-style threat modeling for agentic systems, mitigations aligned with the OWASP Agentic Top 10, and a practical quarterly security review checklist you can adapt to your org.`, + modules: [ + '18-threat-modeling-stride-agentic-ai.md', + '19-owasp-agentic-top-10-mitigations.md', + '20-quarterly-security-review-checklist.md', + ], + }, +] + +function stripFrontmatter(md) { + if (!md.startsWith('---')) { + return md.trimStart() + } + const end = md.indexOf('\n---\n', 3) + if (end === -1) { + return md.trimStart() + } + return md.slice(end + 5).trimStart() +} + +function moduleDocUrl(filename) { + const base = filename.replace(/^\d+-/, '').replace(/\.md$/, '') + return `${DOCS_HUB}/${base}` +} + +function parseModule(filePath, filename) { + const raw = fs.readFileSync(filePath, 'utf8') + const body = stripFrontmatter(raw) + const lines = body.split('\n') + let title = 'Section' + if (lines[0]?.startsWith('# ')) { + title = lines[0].slice(2).trim() + lines.shift() + while (lines[0] === '') { + lines.shift() + } + } + const rest = lines.join('\n').trim() + const docUrl = moduleDocUrl(filename) + return { title, body: rest, docUrl } +} + +function buildPillarBody(pillar) { + const sections = pillar.modules.map((fn) => { + const fp = path.join(seriesDir, fn) + if (!fs.existsSync(fp)) { + throw new Error(`Missing module file: ${fp}`) + } + const { title, body, docUrl } = parseModule(fp, fn) + return [ + `## ${title}`, + '', + `*Original module on ClawQL Docs: [${title}](${docUrl}).*`, + '', + body, + ].join('\n') + }) + return [ + pillar.intro, + '', + sections.join('\n\n---\n\n'), + ].join('\n') +} + +function main() { + if (!fs.existsSync(seriesDir)) { + console.error( + `Series directory not found:\n ${seriesDir}\nSet CLAWQL_ROOT to your ClawQL checkout.`, + ) + process.exit(1) + } + + const entries = pillars.map((p) => { + const body = buildPillarBody(p) + return ` ${JSON.stringify(p.slug)}: ${JSON.stringify(body)},` + }) + + const out = `/* eslint-disable */ +/** + * Generated by scripts/generate-agentic-security-pillars.mjs — do not edit by hand. + * Regenerate after curriculum updates: CLAWQL_ROOT=… node scripts/generate-agentic-security-pillars.mjs + */ + +export const agenticSecurityCurriculumPillarBodies = { +${entries.join('\n')} +} as const + +export type AgenticSecurityCurriculumPillarSlug = + keyof typeof agenticSecurityCurriculumPillarBodies +` + + const outPath = path.join( + personalSiteRoot, + 'src/lib/agenticSecurityCurriculumPillarBodies.generated.ts', + ) + fs.writeFileSync(outPath, out, 'utf8') + console.log(`Wrote ${outPath} (${pillars.length} pillars)`) +} + +main() diff --git a/personal-site/src/app/articles/[slug]/page.tsx b/personal-site/src/app/articles/[slug]/page.tsx index 040ccf9..3ed27d8 100644 --- a/personal-site/src/app/articles/[slug]/page.tsx +++ b/personal-site/src/app/articles/[slug]/page.tsx @@ -40,17 +40,31 @@ export default async function LinkedInArticlePage({ params }: Props) { return ( -

- Original thread (comments, reactions, and any media):{' '} - - View on LinkedIn - -

+ {post.linkedInUrl ? ( +

+ Original thread (comments, reactions, and any media):{' '} + + View on LinkedIn + +

+ ) : post.syndicationSource ? ( +

+ Canonical curriculum and module-by-module versions:{' '} + + {post.syndicationSource.label} + +

+ ) : null} {post.extraLinks?.length ? (

diff --git a/personal-site/src/app/page.tsx b/personal-site/src/app/page.tsx index baa3c5e..7c8ff2f 100644 --- a/personal-site/src/app/page.tsx +++ b/personal-site/src/app/page.tsx @@ -85,14 +85,25 @@ function Article({ article }: { article: ArticleWithSlug }) { {article.description} {linkedInPost ? (

- - View post on LinkedIn - + {linkedInPost.linkedInUrl ? ( + + View post on LinkedIn + + ) : linkedInPost.syndicationSource ? ( + + {linkedInPost.syndicationSource.label} + + ) : null} {linkedInPost.extraLinks?.length ? (

{linkedInPost.extraLinks.map((link, i) => ( diff --git a/personal-site/src/lib/agenticSecurityCurriculumPillarBodies.generated.ts b/personal-site/src/lib/agenticSecurityCurriculumPillarBodies.generated.ts new file mode 100644 index 0000000..00c10ff --- /dev/null +++ b/personal-site/src/lib/agenticSecurityCurriculumPillarBodies.generated.ts @@ -0,0 +1,17 @@ +/* eslint-disable */ +/** + * Generated by scripts/generate-agentic-security-pillars.mjs — do not edit by hand. + * Regenerate after curriculum updates: CLAWQL_ROOT=… node scripts/generate-agentic-security-pillars.mjs + */ + +export const agenticSecurityCurriculumPillarBodies = { + "agentic-ai-security-supply-chain-and-admission": "This long-form article merges **modules 1–3** of the [Agentic AI Security Curriculum](https://docs.clawql.com/security/best-practices) into one place: why digest pinning and private mirrors matter for agent and MCP platforms, how golden images and CI signing reduce drift, and how admission controllers enforce policy before workloads run. Each section links to the original module on ClawQL Docs for deeper diagrams and commands.\n\n## Supply Chain Security: Why Pinning Versions and Running Your Own Mirror Registry Matters\n\n*Original module on ClawQL Docs: [Supply Chain Security: Why Pinning Versions and Running Your Own Mirror Registry Matters](https://docs.clawql.com/security/best-practices/supply-chain-pinning-mirror-registry).*\n\nThe software supply chain is the single largest and most dangerous attack surface in any production-grade agentic AI and MCP platform. A single compromised dependency, container image, or model weight can give an attacker persistent access to your cluster, your documents, your Memory 2.0 knowledge graph, and your users’ sensitive data.\n\nThis module explains why relying on public registries without controls is unacceptable for production deployments that include LLM agents, tools, and sensitive data and shows exactly how to build a secure, mirrored, and verifiable supply chain using Harbor, Cosign, Trivy, Syft, and strict pinning.\n\n### The Supply Chain Threat Landscape\n\nSupply-chain attacks have become sophisticated and frequent:Dependency confusion attacks, where attackers publish malicious packages with the same name as your internal ones.\nTyposquatting and name collisions with popular packages.\nCompromised official base images on Docker Hub or GitHub Container Registry.\nModel weight poisoning through malicious Ollama or Hugging Face models containing hidden triggers.\nLiving-off-the-land persistence once inside a container.\n\nIn an MCP-based or tool-calling agentic system, the impact is amplified. A compromised tool can execute arbitrary code in the sandbox, access the full document pipeline (Tika → Presidio → Paperless), or exfiltrate data through the intelligent gateway.\n\n**Core conclusion**: You cannot outsource trust to the public internet. You must control every artifact from source to running pod.\n\n### Harbor as the Single Trust Root\n\nA common enterprise pattern is to designate a private registry (for example Harbor, ECR with pull-through cache, or ACR) as the single source of truth for all artifacts: container images, Helm charts, model weight manifests, SBOMs, and Cosign signatures.\n\nHarbor provides a private registry with replication, pull-through caching, built-in vulnerability scanning, and native support for SBOM storage. All production workloads should be configured to pull exclusively from that internal registry.\n\n**Key Harbor configuration principles**:\n\nAllowlist-only resolution enabled.\nReplication rules to mirror only approved upstream artifacts.\nAll images and manifests must be signed before being accepted.\n\n### Allowlist-Only Resolution and Version Pinning\n\nThis is the foundational control.Never do this in production:Pulling directly from Docker Hub, npm, PyPI, or GitHub.\nUsing floating tags such as :latest or :main.\nAllowing version ranges like ^1.2.0.\n\nAlways do this:Use exact digest pinning (e.g., nginx@sha256:abc123…).\nOr use a pinned version combined with mandatory Cosign signature verification.\n\nHelm umbrella charts, GitOps, or an in-cluster operator often enforce equivalent rules through configuration flags such as:\n\n```yaml\nsecurity:\n supplyChain:\n registryMirror: \"registry.internal.example\"\n allowlistOnly: true\n requireDigest: true\n requireCosign: true\n```\n\n### Scanning, SBOM Generation, and Signing\n\nEvery artifact that enters Harbor must be scanned and accompanied by a Software Bill of Materials (SBOM).\n\n**Tools commonly used in hardened CI/CD pipelines**:\n\nTrivy: OS and language vulnerability scanning.\nOSV-Scanner: Ecosystem-specific vulnerability checks.\nSyft: SBOM generation (SPDX and CycloneDX formats).\nCosign: Keyless signing via Sigstore (no long-lived keys to manage or steal).\n\n**Typical CI pipeline step**:\n\n```bash\ntrivy image --exit-code 1 --severity CRITICAL,HIGH $IMAGE:latest\nsyft packages $IMAGE:latest -o spdx-json > sbom.spdx.json\ncosign sign --keyless $IMAGE@${DIGEST}\n```\n\nAll SBOMs are stored alongside their images in Harbor for long-term forensic and compliance needs.\n\n### Credential Leak Prevention\n\nEven the best registry is useless if secrets enter the repository.Strong pipelines often use a two-layer defense:Gitleaks as a mandatory pre-commit hook plus CI gate.\nTruffleHog for full historical repository scans on every push or pull request.\n\nThese tools block AWS keys, Vault tokens, database credentials, and other secrets before they ever reach the main branch.\n\n### Practical implementation checklist\n\nMirror only approved upstream artifacts into Harbor on a nightly schedule.\nEnforce allowlist-only resolution and digest pinning everywhere in Helm charts and the Operator.\nRequire Cosign keyless signing on all images and manifests.\nScan every build with Trivy + OSV-Scanner and block merges on critical findings.\nStore SBOMs with every release for full traceability months later.\n\nAutomate as many of these controls as possible in your charts, operators, or policy-as-code repos.\n\n### Key Takeaways\n\nPublic registries represent an unacceptable risk for production agentic platforms.\nA private mirror registry (Harbor) with allowlist-only resolution is the foundation of all other security layers.\nStrict pinning, SBOMs, and Cosign signing turn every artifact into a verifiable, tamper-evident unit.\nCredential scanning prevents the most common initial compromise vector.\n\nThis supply chain foundation is the prerequisite for every subsequent module in this curriculum.\n\n**Next module:** Building Golden Images – Automated Scanning, Hardening, and Distroless Pipelines.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [NIST SP 800-218 (SSDF)](https://csrc.nist.gov/publications/detail/sp/800-218/final)\n- [SLSA supply-chain levels](https://slsa.dev/spec/)\n- [OpenSSF Scorecard](https://scorecard.dev/)\n- [Sigstore / Cosign](https://docs.sigstore.dev/cosign/overview/)\n- [CycloneDX (SBOM)](https://cyclonedx.org/)\n- [SPDX](https://spdx.dev/)\n- [Trivy (scanner)](https://trivy.dev/latest/)\n- [OSV-Scanner](https://google.github.io/osv-scanner/)\n- [CNCF Harbor](https://goharbor.io/docs/)\n\n---\n\n## Building Golden Images: Automated Scanning, Hardening, and Distroless Pipelines\n\n*Original module on ClawQL Docs: [Building Golden Images: Automated Scanning, Hardening, and Distroless Pipelines](https://docs.clawql.com/security/best-practices/golden-images-distroless-pipelines).*\n\nOnce you have secured your supply chain with a private mirror registry (Module 1), the next critical layer is building **golden images** — minimal, hardened, immutable container images that form the foundation of every production agent or platform workload. This module explains how to create, scan, sign, and deploy golden distroless images with read-only root filesystems and full provenance.\n\n### Why Golden Distroless Images Matter\n\nMost container images are far larger than necessary and contain unnecessary tools that increase the attack surface. A compromised package manager or shell in a running pod gives attackers easy persistence and lateral movement options.\n\nA sensible hardening philosophy is simple: make images as small as possible.\nRemove everything that is not required at runtime.\nMake the root filesystem read-only.\nVerify every image before it ever runs.\n\nThis approach dramatically reduces the blast radius if a container is compromised.\n\n### Core Hardening Principles\n\n**1. Distroless Base Images** \nUse Google’s official distroless images or Chainguard distroless as the foundation. These contain only the bare runtime (e.g., glibc, ca-certificates, and your application binary) with no shell, no package manager, and no unnecessary utilities.**2. Read-Only Root Filesystem** \nSet securityContext.readOnlyRootFilesystem: true on every pod. Combined with distroless, this prevents attackers from writing new binaries, installing tools, or modifying system files even if they achieve code execution.**3. Multi-Stage Builds** \nTypical hardened pipelines use multi-stage Dockerfiles:dockerfile\n\n# Stage 1: Builder\n\nFROM golang:1.24-alpine AS builder\nWORKDIR /app\nCOPY . .\nRUN go build -ldflags=\"-s -w\" -o /clawql-api ./cmd/api\n\n# Stage 2: Golden Runtime\n\nFROM gcr.io/distroless/static-debian12\nCOPY --from=builder /clawql-api /usr/local/bin/clawql-api\nUSER 65532:65532\nENTRYPOINT [\"/usr/local/bin/clawql-api\"]\n\n**4. Minimal Attack Surface**\n\nNo shell (sh, bash)\nNo package managers (apt, apk, yum)\nNo debug tools (curl, wget, strace)\nStatic binaries where possible\n\n### Automated Scanning and Signing\n\nEvery golden image goes through a mandatory pipeline before being promoted to Harbor:**Build** → Multi-stage Dockerfile\n**Scan** → Trivy (critical/high vulnerabilities blocked) + OSV-Scanner\n**Generate SBOM** → Syft (stored alongside the image)\n**Sign** → Cosign keyless signing via Sigstore\n**Push** → Only to internal Harbor with allowlist enforcement\n\n**Example CI pipeline snippet**\n\n```yaml\n- name: Build Golden Image\n run: |\n docker build -t $IMAGE:$TAG .\n trivy image --exit-code 1 --severity CRITICAL,HIGH $IMAGE:$TAG\n syft packages $IMAGE:$TAG -o spdx-json > sbom.spdx.json\n cosign sign --keyless $IMAGE@${DIGEST}\n docker push $IMAGE:$TAG\n```\n\n### Golden image standards (checklist)\n\nProduction services should follow these rules:Base: gcr.io/distroless/static-debian12 or chainguard/static\nNon-root user (UID 65532)\nRead-only root filesystem enforced in Helm charts and Kyverno policies\nNo writable layers except explicitly mounted volumes (e.g., /tmp if absolutely required, mounted as tmpfs)\nFull SBOM and Cosign signature required\n\nThe clawql-full-stack Helm chart includes these defaults under security.goldenImages.\n\n### Kyverno Policy Enforcement\n\nA cluster-wide Kyverno policy enforces golden image standards at admission time:\n\n```yaml\napiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n name: require-golden-images\nspec:\n validationFailureAction: Enforce\n rules:\n - name: check-distroless-and-readonly\n match:\n resources:\n kinds: [\"Pod\"]\n validate:\n message: \"All pods in scope must use golden distroless images with read-only root filesystem\"\n pattern:\n spec:\n securityContext:\n readOnlyRootFilesystem: true\n containers:\n - image: \"registry.internal.example/*@sha256:*\"\n```\n\n### Key Takeaways\n\nGolden distroless images with read-only root filesystems are one of the most effective ways to limit attacker capabilities.\nMulti-stage builds, automated scanning, SBOM generation, and Cosign signing ensure every image is minimal and verifiable.\nThese images form the foundation for all subsequent controls (admission policies, sandboxing, and runtime protection).\nNever run images with shells or package managers in production MCP workloads.\n\nThis module builds directly on Module 1 (Supply Chain) and is the prerequisite for Module 3 (Cluster Admission Control).\n\n**Next module:** Cluster Admission Control – Enforcing Image Signing and Policy at Deploy Time.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Google distroless](https://github.com/GoogleContainerTools/distroless)\n- [Chainguard Images (overview)](https://www.chainguard.dev/chainguard-images)\n- [NSA / CISA Kubernetes Hardening Guide](https://media.defense.gov/2022/Mar/23/2002965772/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220315.PDF)\n- [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes)\n- [Kyverno policies](https://kyverno.io/docs/)\n\n---\n\n## Cluster Admission Control: Enforcing Image Signing and Policy at Deploy Time\n\n*Original module on ClawQL Docs: [Cluster Admission Control: Enforcing Image Signing and Policy at Deploy Time](https://docs.clawql.com/security/best-practices/cluster-admission-control-signing-policy).*\n\nWith a secure supply chain and golden distroless images in place (Modules 1 and 2), the next layer is preventing non-compliant workloads from ever starting. Cluster admission controllers act as the final gatekeeper, rejecting unsigned, unverified, or insecure images before they are scheduled.\n\nThis module focuses on Kyverno as an admission controller and shows how to enforce image signing, golden image standards, and runtime policies at deploy time.\n\n### Why Admission Control Is Essential\n\nEven with strong supply chain practices, misconfigurations or human error can still introduce risky workloads. Admission webhooks provide a last-line defense by inspecting pod specs in real time and rejecting them if they violate policy.In hardened deployments, this ensures:Only images from your private Harbor registry are allowed.\nEvery image must be Cosign-signed and digest-pinned.\nModel weight verification and golden image rules are enforced.\nNo pod can run with excessive privileges or writable root filesystems.\n\n### Kyverno verifyImages Admission Policies\n\nKyverno is a common choice as the primary admission controller. It supports cryptographic verification of container images and model artifacts.\n\n**Core Policy: Require Signed Images**\n\n```yaml\napiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n name: enforce-signed-images\nspec:\n validationFailureAction: Enforce\n background: false\n rules:\n - name: verify-cosign-signature\n match:\n resources:\n kinds: [\"Pod\"]\n validate:\n message: \"All containers must be signed with Cosign and pulled from Harbor\"\n imageVerify:\n - imageReferences: [\"registry.internal.example/**\"]\n verify:\n - type: \"cosign\"\n keyless:\n issuer: \"https://token.actions.githubusercontent.com\"\n subject: \"https://github.com/clawql/*\"\n```\n\nThis policy rejects any pod using unsigned images or images from external registries.\n\n### Extending Verification to Model Weights\n\nModel weights are a common blind spot. This module extends admission control to verify them via init containers:\n\n```yaml\n# Example init container pattern enforced by policy\ninitContainers:\n - name: verify-weights\n image: registry.internal.example/clawql/weight-verifier:latest\n command:\n - cosign\n - verify-blob\n - --key\n - /etc/signing-keys/cosign.pub\n - --signature\n - /weights/manifest.sig\n - /weights/manifest.json\n volumeMounts:\n - name: model-weights\n mountPath: /weights\n```\n\nA dedicated Kyverno policy ensures every inference pod includes this verification step.\n\n### Cluster-Wide vs Namespace Exemptions\n\nMany teams apply a **cluster-wide default-deny** posture with limited exemptions:openclaw and clawql namespaces: strict enforcement.\nTemporary exemption namespaces (e.g., for debugging) require explicit approval and short TTL.\nAll exemptions are logged and reviewed quarterly.\n\n### Integration with Golden Images and Supply Chain\n\nThe admission policies work together with Guides 1 and 2:Only images built through the golden pipeline (distroless + read-only root) are allowed.\nDigest pinning and SBOM presence are validated.\nNon-compliant pods are rejected before scheduling, preventing drift.\n\n**Helm Chart Defaults**\n\nThe clawql-full-stack chart enables these policies automatically when security.fullBundle: true.\n\n### Key Takeaways\n\nAdmission controllers like Kyverno provide the final enforceable gate before any workload runs.\nCryptographic verification (Cosign) combined with allowlist policies eliminates unsigned or tampered images.\nExtending policies to model weights closes a critical gap missed by traditional container scanning.\nCluster-wide enforcement with minimal exemptions maintains a strong, auditable security posture.\n\nThis module completes the build-time and deploy-time foundations. All later runtime protections (sandboxing, zero trust, MCP proxying) build on top of these admission guarantees.\n\n**Next module:** Principle of Least Privilege – Scoped Identities and Limiting Blast Radius.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Kyverno verifyImages](https://kyverno.io/docs/writing-policies/verify-images/)\n- [OPA Gatekeeper](https://open-policy-agent.github.io/gatekeeper/website/docs/)\n- [Kubernetes admission control overview](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)\n- [Ratify (artifact ratification)](https://ratify.dev/)", + "agentic-ai-security-identity-zero-trust": "**Modules 4–6** cover scoped identities for agents and tools, zero-trust networking and policy basics, and advanced patterns (Vault, HSMs, provenance) that matter when LLMs orchestrate sensitive APIs. Consolidated here with links to each canonical module.\n\n## Principle of Least Privilege: Scoped Identities and Limiting Blast Radius\n\n*Original module on ClawQL Docs: [Principle of Least Privilege: Scoped Identities and Limiting Blast Radius](https://docs.clawql.com/security/best-practices/least-privilege-scoped-identities).*\n\nEven with perfect supply chain security and admission control, a compromised workload or agent can still cause significant damage if it has excessive permissions. The Principle of Least Privilege (PoLP) ensures every identity — human, service, or agent — can do only what is strictly necessary, and nothing more.\n\nThis module shows how to implement least privilege across Kubernetes, MCP tools, and agent sessions to minimize blast radius.\n\n### Least Privilege in Theory and Practice\n\nLeast privilege means granting the minimum permissions required for a task and only for the duration needed. In agentic systems this is critical because agents can chain tools in unexpected ways.Apply least privilege at multiple layers:Kubernetes workloads\nHuman operators\nAgent/MCP tool calls\nSession-scoped claims\n\n### Per-Workload Identities with Kubernetes RBAC and ServiceAccounts\n\nEvery component should run with its own dedicated ServiceAccount and tightly scoped Role/RoleBinding.\n\n**Example for the API gateway:**\n\n```yaml\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n name: clawql-api\n namespace: clawql\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n name: clawql-api-role\nrules:\n - apiGroups: [\"\"]\n resources: [\"configmaps\", \"secrets\"]\n verbs: [\"get\", \"list\", \"watch\"] # no create/update/delete\n - apiGroups: [\"apps\"]\n resources: [\"deployments\"]\n verbs: [\"get\", \"list\"] # read-only for status\n```\n\nNo production pod should run with cluster-admin or overly broad permissions. Your GitOps or operator pattern should manage these bindings declaratively.\n\n### YubiKey Requirement for High-Impact Changes\n\nAny change to production Helm charts for the control plane or critical CRDs requires hardware-backed Git signing with a YubiKey.This ensures that even if a developer workstation is compromised, an attacker cannot push malicious chart changes without physical hardware access. Treat production Helm upgrades as signed, reviewed changes.\n\n### Explicit MCP Tool Scoping and ATR Claims\n\nOne of the most powerful least-privilege controls in agent stacks is **ATR (Agent Task Request)** scoping at the MCP layer. Every tool call is validated against the user’s session claims. Agents can only invoke tools explicitly allowed for their role and vertical.\n\n**Example ATR-bound tool registration:**\n\nMortgage underwriters can call lending-specific tools but not blockchain or healthcare tools.\nSandbox execution is restricted to approved Kata-isolated namespaces.\nCross-vertical memory recall requires elevated memory.cross_vertical: true claim.\n\nA synchronous MCP gateway or policy proxy can enforce these scopes synchronously on every clawql_execute call.\n\n### Limiting Blast Radius\n\nCombining these controls means that:A compromised pod cannot reach most cluster resources.\nA compromised agent cannot call dangerous tools.\nA compromised developer cannot deploy malicious changes without hardware keys.\nEven full container escape is contained by Kata sandboxing (covered in Module 8).\n\n### Key Takeaways\n\nLeast privilege turns potential catastrophic breaches into limited incidents.\nDedicated ServiceAccounts, narrow RBAC roles, and hardware-backed changes form the foundation.\nATR scoping at the MCP gateway provides fine-grained, per-task control that traditional RBAC cannot achieve alone.\nEvery identity and every tool must be explicitly authorized — implicit access is forbidden.\n\nStrong least privilege is the bedrock of zero trust, which is covered next.\n\n**Next module:** Zero Trust Fundamentals – Assume Compromise and Verify Everything.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Kubernetes RBAC good practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/)\n- [NIST SP 800-207 (Zero Trust)](https://csrc.nist.gov/publications/detail/sp/800-207/final)\n- [OWASP API Security Top 10](https://owasp.org/www-project-api-security/)\n\n---\n\n## Zero Trust Fundamentals: Assume Compromise and Verify Everything\n\n*Original module on ClawQL Docs: [Zero Trust Fundamentals: Assume Compromise and Verify Everything](https://docs.clawql.com/security/best-practices/zero-trust-fundamentals).*\n\nWith supply chain security, golden images, admission control, and least privilege in place, organizations typically shift to a full Zero Trust posture. This module introduces the core philosophy that underpins resilient architectures: never trust, always verify, and assume breach at all times.\n\n### Zero Trust Defined for Agentic Systems\n\nTraditional perimeter security (firewalls, VPNs, “inside the cluster is safe”) fails in agentic MCP environments. Agents can call tools, process documents, and interact with external systems in unpredictable ways. Once any component is compromised, lateral movement can be rapid.\n\nA Zero Trust model for agentic systems treats every request, every pod, every agent session, and every tool call as potentially malicious until proven otherwise.\n\n### The Three Governing Principles\n\nThis module is built on these explicit principles from the Defense-in-Depth guide:**Secure the capabilities, not the language** \nPrompt injection and clever jailbreaks are inevitable. Instead of trying to filter natural language, effective platforms restrict what an agent can actually _do_ through ATR-scoped MCP tools and Panguard enforcement.\n**Every trust assumption is explicit and verified** \nNo implicit trust in containers, model weights, sessions, secrets, or logs. Everything carries cryptographic provenance (Cosign signatures, Merkle roots, JWT ATR claims).\n**Containment over prevention** \nAssume breach will happen. Design so that when it does, damage is limited, forensic evidence is preserved (WORM + Merkle), and recovery is fast.\n\n### Core Zero Trust controls to implement\n\n**Continuous verification**: Every MCP tool call validates JWT ATR claims, every image is verified at admission, every model weight is checked before inference.\n**Least privilege by default**: Covered in Module 4 — narrow RBAC, scoped ServiceAccounts, and per-task tool authorization.\n**Micro-segmentation**: Istio mTLS + AuthorizationPolicy (Module 7) ensures pods can only talk to explicitly allowed services.\n**Default-deny posture**: NetworkPolicy, egress allowlists, and Kyverno policies reject anything not explicitly permitted.\n**Assume breach mindset**: Kata Containers for MCP workloads, automated quarantine with Talon, tamper-evident WORM logs.\n\n### Shift from Prevention to Containment\n\nTraditional security focuses heavily on blocking attacks. Well-designed platforms invest equally in containment and recovery:If a pod is compromised → Kata isolation + Talon auto-quarantine.\nIf an agent goes rogue → Panguard blocks the tool call and logs the full session.\nIf logs are tampered → Merkle roots and WORM storage make it detectable.\n\nThis mindset changes how you design, deploy, and operate the platform.\n\n### Key Takeaways\n\nZero Trust is not a tool — it is an operating philosophy: assume compromise and verify everything, every time.\nIn agentic systems, securing _capabilities_ through ATR scoping and MCP proxy enforcement is far more effective than trying to secure natural language.\nEvery layer (supply chain, admission, identity, network, runtime) must independently verify and contain.\nPrevention alone is insufficient; strong containment and forensic readiness are mandatory.\n\nThis module sets the stage for the advanced Zero Trust controls in the next module.\n\n**Next module:** Advanced Zero Trust – Multi-Sig Vault, HSM, Tamper-Proof Logging, and Cryptographic Provenance.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [NIST SP 800-207 (Zero Trust Architecture)](https://csrc.nist.gov/publications/detail/sp/800-207/final)\n- [NIST AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework)\n- [ENISA Multilayer Framework for Good Cybersecurity Practices for AI](https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai)\n\n---\n\n## Advanced Zero Trust: Multi-Sig Vault, HSM, Tamper-Proof Logging, and Cryptographic Provenance\n\n*Original module on ClawQL Docs: [Advanced Zero Trust: Multi-Sig Vault, HSM, Tamper-Proof Logging, and Cryptographic Provenance](https://docs.clawql.com/security/best-practices/advanced-zero-trust-vault-hsm-provenance).*\n\nBuilding on Zero Trust fundamentals (Module 5), this module covers the advanced cryptographic and secret-management controls that make trust assumptions explicit and verifiable across the entire platform.\n\n### Dynamic Secrets with Short TTL\n\nTeams often use HashiCorp Vault for all secrets (database credentials, API keys, mTLS certificates, etc.).Key practices:Secrets are issued dynamically per workload with short TTLs (minutes to hours).\nAutomatic revocation on pod termination.\nNo long-lived static secrets anywhere in the cluster.\n\nVault Agent sidecars handle token renewal and secret injection. The Operator monitors lease counts and alerts on orphaned credentials.\n\n### JWT ATR Session Tokens\n\nEvery agent session receives a short-lived JWT containing ATR (Agent Task Request) claims. These claims define exactly what tools, verticals, and data the agent may access.Panguard and the intelligent MCP gateway validate the JWT signature and claims on every clawql_execute call. Agents cannot escalate their own privileges or forge claims.\n\n### Merkle Trees and Cryptographic Provenance\n\nEvery critical artifact carries tamper-evident provenance:Documents after Presidio redaction\nMemory 2.0 graph entities and edges\nWorkflow definitions\nProxy dispatches and tool call results\n\nA Merkle root is computed and recorded for each operation. Roots are stored in WORM volumes and a Git-backed, Cosign-signed repository. Any silent modification is immediately detectable on read.\n\n### WORM Storage and Tamper-Proof Logging\n\nAll security-relevant logs (prompts, tool calls, decisions) are written to WORM (Write Once, Read Many) storage.Presidio redaction runs in the Fluent Bit pipeline before logs reach Loki.\nMerkle roots link logs to the broader audit trail.\nNo deletions or modifications are possible after write.\n\nThis ensures forensic integrity even if an attacker reaches the logging infrastructure.\n\n### Cosign Blob Signing for Model Weights\n\nModel weights (the largest unverified artifact in most AI stacks) are protected with:Signed manifests stored in Harbor\nInit-container verification before inference starts\nSHA-256 hash checking combined with Cosign verification\n\nThis closes the “model-in-the-middle” attack vector that container image scanning cannot detect.\n\n### Key Takeaways\n\nDynamic secrets with short TTLs and automatic revocation eliminate standing credentials.\nJWT ATR tokens enforce explicit, verifiable capabilities at the MCP layer.\nMerkle trees and WORM storage provide cryptographic proof that nothing has been silently altered.\nEvery trust assumption — from model weights to audit logs — is made explicit and independently verifiable.\n\nThese advanced controls turn Zero Trust from a philosophy into enforceable, auditable reality across the platform.\n\n**Next module:** RBAC, mTLS, and Istio Service Mesh – Network-Level Zero Trust.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [HashiCorp Vault security model](https://developer.hashicorp.com/vault/docs/internals/security)\n- [NIST SP 800-57 (key management)](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final)\n- [WORM / immutability (SNIA overview)](https://www.snia.org/education/what-is-worm-storage)", + "agentic-ai-security-mesh-sandbox-mcp": "**Modules 7–9** address enforcing identity and policy in the mesh (RBAC, mTLS, Istio), choosing sandbox boundaries (Kata, gVisor, and tradeoffs), and hardening MCP-style runtimes with gateways and runtime protection. Read end-to-end here, then open any module on docs for the full detail.\n\n## RBAC, mTLS, and Istio Service Mesh: Network-Level Zero Trust\n\n*Original module on ClawQL Docs: [RBAC, mTLS, and Istio Service Mesh: Network-Level Zero Trust](https://docs.clawql.com/security/best-practices/rbac-mtls-istio-service-mesh).*\n\nWith identity-level least privilege and advanced cryptographic controls established (Modules 4–6), this module extends Zero Trust to the network layer. It covers how RBAC, mutual TLS, and Istio Service Mesh work together to enforce micro-segmentation and default-deny networking across the cluster.\n\n### Istio mTLS and AuthorizationPolicy\n\nIstio provides automatic mutual TLS between all pods in the mesh. Every pod-to-pod connection is encrypted and authenticated using short-lived certificates.\n\n**AuthorizationPolicy examples** in a reference stack:\n\nThe API gateway can only call specific backend services (documents, memory, vertical plugins).\nMCP sandbox pods can only reach the Kata runtime and isolated NATS JetStream topics.\nVertical plugins are blocked from direct communication with each other — all cross-vertical traffic must route through the intelligent gateway.\n\nThis eliminates east-west lateral movement even if a pod is compromised.\n\n### ServiceEntries as FQDN Lockdown\n\nIstio **ServiceEntries** explicitly whitelist allowed external destinations:\n\n- Only approved external APIs (GitHub, document stores, oracles, etc.).\n- No arbitrary outbound traffic to the internet.\n- EgressGateway routes all external calls through inspected paths.\n\nThis replaces the need for a separate WAF for FQDN control and is reviewed quarterly alongside STRIDE modeling.\n\n### Default-Deny NetworkPolicy\n\nA cluster-wide default-deny NetworkPolicy ensures no pod can talk to any other pod or external endpoint unless an explicit allow rule exists.\n\nCombined with Istio, this creates layered defense: NetworkPolicy at the Kubernetes level and AuthorizationPolicy + mTLS at the service mesh level.\n\n### Traffic Baselining and Anomaly Detection with Kiali\n\nKiali visualizes the service mesh topology while Prometheus alerts on unexpected connection patterns. The security team maintains a baseline of normal east-west traffic. Any new or anomalous flow triggers investigation.\n\n### Helm Chart Integration\n\nThese controls are enabled by default when deploying with:\n\n```yaml\nsecurity:\n fullBundle: true\n istio:\n enabled: true\n mTLS: strict\n egressAllowlist: true\n```\n\n### Key Takeaways\n\nNetwork-level Zero Trust requires encryption (mTLS), authentication, and explicit authorization for every connection.\nDefault-deny policies combined with ServiceEntries provide strong egress and east-west control.\nMicro-segmentation limits blast radius: a compromised component can only reach what it is explicitly allowed to reach.\nContinuous baselining with Kiali turns the mesh into an active security sensor.\n\nThis network foundation enables safe sandboxing and runtime protection in the following modules.\n\n**Next module:** Sandboxing Options and Trade-offs – Kata, gVisor, Seatbelt, Docker, and Cloudflare Workers.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Istio security (mTLS)](https://istio.io/latest/docs/concepts/security/)\n- [Kubernetes NetworkPolicies](https://kubernetes.io/docs/concepts/services-networking/network-policies/)\n- [NIST SP 800-204B (micro-segmentation with service mesh)](https://csrc.nist.gov/publications/detail/sp/800-204b/final)\n\n---\n\n## Sandboxing Options and Trade-offs: Kata, gVisor, Seatbelt, Docker, and Cloudflare Workers\n\n*Original module on ClawQL Docs: [Sandboxing Options and Trade-offs: Kata, gVisor, Seatbelt, Docker, and Cloudflare Workers](https://docs.clawql.com/security/best-practices/sandboxing-kata-gvisor-tradeoffs).*\n\nWith network-level Zero Trust established (Module 7), the next critical layer is runtime isolation for the highest-risk workloads — especially MCP tool execution and agent code running. This module compares sandboxing technologies and explains why many security-focused platforms default to Kata Containers for MCP workloads.\n\n### Why Strong Sandboxing Is Non-Negotiable\n\nAgentic systems routinely execute untrusted or dynamically generated code. Container namespaces alone are insufficient when an agent has access to tools like sandbox_exec, document processing, or external API calls. A breakout must be extremely difficult and contained.\n\n### Isolation Technologies Compared\n\n| Technology | Isolation Type | Performance Overhead | Attack Surface Reduction | Typical high-trust agent usage |\n| ------------------ | ------------------------- | -------------------- | ------------------------- | ------------------------------ |\n| Docker (default) | Namespace + cgroups | Low | Low | Never in production |\n| gVisor | Userspace kernel | Medium | High | Acceptable for non-MCP |\n| Seatbelt | macOS sandbox profiles | Low | Medium | Local dev only |\n| Kata Containers | Lightweight VM (hardware) | Medium-High | Very High | Default for all MCP workloads |\n| Cloudflare Workers | V8 isolates / edge | Very Low | High (for edge functions) | Optional for lightweight tools |\n\n### Kata Containers as default for high-risk MCP workloads\n\nKata provides a full hardware VM boundary per pod using lightweight VMs (QEMU/KVM or Firecracker).\n\n**Key Advantages:**\n\nKernel-level isolation: even if the container is fully compromised, the attacker cannot escape the VM.\nStrongest protection for MCP tool execution and sandboxed code.\nEnforced via Kyverno RuntimeClass policy and Helm defaults.\n\n**Kyverno Enforcement Example:**\n\n```yaml\napiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n name: enforce-kata-for-mcp\nspec:\n validationFailureAction: Enforce\n rules:\n - name: require-kata\n match:\n resources:\n kinds: [\"Pod\"]\n namespaces: [\"openclaw\", \"clawql\"]\n validate:\n message: \"MCP and sandbox workloads must use Kata runtime\"\n pattern:\n spec:\n runtimeClassName: \"kata\"\n```\n\n### When to Use Lighter Options\n\n**gVisor**: Acceptable for general non-execution workloads where Kata overhead is undesirable. Provides syscall interception without a full VM.\n**Seatbelt / macOS Sandbox**: Used only for local developer workstations.\n**Cloudflare Workers**: Suitable for lightweight, stateless edge functions that do not need full cluster access.\n**Plain Docker**: Strictly forbidden for any production MCP or agent execution path.\n\nThe Operator and Helm chart automatically apply the correct RuntimeClass based on workload type when security.kata.enabled: true.\n\n### Key Takeaways\n\nKata Containers deliver the strongest isolation for agentic MCP workloads by using hardware VM boundaries.\nWeaker options like gVisor or standard Docker are insufficient when agents can execute arbitrary code.\nRuntimeClass enforcement via Kyverno ensures the correct sandbox is always used.\nChoose isolation strength based on workload risk — never default to convenience over security.\n\nStrong sandboxing completes the foundational runtime protection. The next modules focus on protecting the MCP interface itself.\n\n**Next module:** MCP Runtime Protection – Panguard, ATR Rules, and Agentic Threat Mitigation.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Kata Containers](https://katacontainers.io/docs/)\n- [gVisor](https://gvisor.dev/docs/)\n- [NIST Application Container Security Guide](https://csrc.nist.gov/publications/detail/sp/800-190/final)\n\n---\n\n## MCP Runtime Protection: Panguard, ATR Rules, and Agentic Threat Mitigation\n\n*Original module on ClawQL Docs: [MCP Runtime Protection: Panguard, ATR Rules, and Agentic Threat Mitigation](https://docs.clawql.com/security/best-practices/mcp-runtime-protection-panguard-atr).*\n\nThe MCP interface is the highest-risk attack surface in any agentic platform. Agents interact with tools, memory, documents, and external systems through natural language, making traditional prompt-based defenses insufficient. This module details how to protect the MCP runtime using Panguard, ATR scoping, and layered governance.\n\n### Panguard AI as the Synchronous Chokepoint\n\nPanguard sits directly in front of the intelligent MCP gateway (clawql-api) and acts as the primary real-time intercept layer.\n\n**Key Capabilities:**\n\nSub-50ms latency per tool call\nReal-time ATR (Agent Task Request) rule evaluation\nBlocking of malicious or out-of-scope requests\nCoverage of OWASP Agentic Top 10 risks\nFull session auditing\n\nAll clawql_execute calls, native vertical tools, and proxy plugin dispatches flow through Panguard before any downstream execution.\n\n### ATR Rules and Explicit Tool Scoping\n\nInstead of relying on fragile prompt filtering, Teams often use structured ATR claims attached to JWT session tokens:Each tool call is validated against the user’s role, vertical permissions, and current task scope.\nAgents cannot self-escalate privileges.\nCross-vertical actions (e.g., lending fraud patterns applied to insurance) require explicit elevated claims.\nSandbox execution and dangerous operations are tightly gated.\n\nPanguard rejects any call that violates these rules and returns a clear error to the agent.\n\n### Microsoft Agent Governance Toolkit as Deterministic Overlay\n\nPanguard is complemented by the Microsoft Agent Governance Toolkit running as a sidecar. While Panguard provides fast, AI-augmented protection, the Toolkit adds deterministic, rule-based governance with different failure modes. Together they create defense-in-depth at the MCP layer.\n\n### Prompt and Response Logging with Redaction\n\nEvery MCP interaction is logged with:Full context (redacted via Presidio in the Fluent Bit pipeline)\nTool parameters and results\nDecision metadata (why a call was allowed or blocked)\n\nLogs are written to WORM storage with Merkle roots for tamper evidence.\n\n### Key Takeaways\n\nThe MCP interface must be treated as the primary attack surface and protected with synchronous, low-latency interception.\nATR-based capability scoping is far more effective than prompt injection defenses.\nLayered protection (Panguard + Microsoft Toolkit) provides resilience through diverse failure modes.\nComprehensive auditing and redaction ensure forensic readiness without exposing sensitive data.\n\nStrong MCP runtime protection builds directly on the sandboxing and network controls from previous modules and enables safe agentic operation at scale.\n\n**Next module:** Data Classification and PII Redaction – Never Let Sensitive Data Hit Logs.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Model Context Protocol (MCP) specification](https://modelcontextprotocol.io/specification/draft)\n- [OWASP Top 10 for Agentic Applications (2026)](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)\n- [OWASP API Security Top 10](https://owasp.org/www-project-api-security/)", + "agentic-ai-security-data-models-observability": "**Modules 10–12** tie data handling (classification, PII, logs), model supply chain and weight verification, and runtime monitoring together—the stack teams need when agents read documents, call tools, and leave rich audit trails.\n\n## Data Classification and PII Redaction: Never Let Sensitive Data Hit Logs\n\n*Original module on ClawQL Docs: [Data Classification and PII Redaction: Never Let Sensitive Data Hit Logs](https://docs.clawql.com/security/best-practices/data-classification-pii-redaction-logs).*\n\nEven with strong runtime protection and sandboxing (Modules 8–9), sensitive data inevitably flows through agent sessions, documents, and tool calls. This module explains how to prevent PII, financial data, and other sensitive information from ever reaching persistent log stores.\n\n### Classification vs Redaction\n\nData classification and redaction are distinct but complementary controls:**Classification** tells you _what_ data is sensitive and how it should be handled.\n**Redaction** ensures sensitive data is removed or masked _before_ it is written to any queryable or long-term storage.\n\nBoth are required. Classification without redaction leaves raw PII in logs. Redaction without classification leaves you unable to reason about your data holdings.Organizations should maintain a formal data classification policy with tiers (Public, Internal, Confidential, Restricted) that maps to redaction rules.\n\n### Presidio in the Fluent Bit Pipeline\n\nReference stacks often run Microsoft Presidio as a pipeline stage in Fluent Bit — not as per-pod sidecars.\n\n**Why pipeline-level redaction?**\n\nOne consistent redaction engine for all log sources.\nFewer failure modes and surfaces to maintain.\nRedaction happens before logs reach Loki.\n\nPresidio identifies and redacts PII (names, SSNs, credit cards, medical records, etc.) and financial data in real time as logs are collected.\n\n### Redaction-Before-Write for WORM Compliance\n\nAll security-relevant logs are written to WORM storage. Because redaction occurs before write:No raw sensitive data ever lands in persistent stores.\nWORM compliance is maintained without needing record deletion (which defeats WORM).\nForensic value is preserved — enough context remains for investigation while PII is removed.\n\n### Forensic-Friendly Logging Design\n\nRedaction rules are tuned to balance privacy and usability:Entity replacement with tokens (e.g., [REDACTED_SSN]) rather than full removal.\nContext around redacted fields is retained where possible.\nFull unredacted logs (if ever needed for incident response) are available only through strict break-glass procedures with multi-party approval.\n\n### Key Takeaways\n\nRedaction must happen before data reaches any persistent log store — never after.\nPipeline-level Presidio integration provides consistent, maintainable coverage across the entire platform.\nClassification policy + redaction-before-write satisfies both privacy regulations and forensic requirements.\nThis approach ensures sensitive data never becomes a liability in logs, even during full incident investigations.\n\nProper data handling completes the protection of information in motion and at rest, enabling safe monitoring and response in the following modules.\n\n**Next module:** Model Integrity – Verifying Weights Before Inference.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Microsoft Presidio](https://microsoft.github.io/presidio/)\n- [Fluent Bit](https://docs.fluentbit.io/manual/)\n- [NIST Privacy Framework](https://www.nist.gov/privacy-framework)\n\n---\n\n## Model Integrity: Verifying Weights Before Inference\n\n*Original module on ClawQL Docs: [Model Integrity: Verifying Weights Before Inference](https://docs.clawql.com/security/best-practices/model-integrity-verifying-weights).*\n\nModel weights represent one of the largest and most overlooked attack surfaces in AI platforms. Traditional container scanning misses them entirely because they are large binary blobs fetched at runtime. This module explains how this pattern closes the “model-in-the-middle” attack vector with cryptographic verification before any inference begins.\n\n### The Model Weight Gap\n\nContainer images can be verified with Cosign and Kyverno, but model weights (Ollama models, Hugging Face checkpoints, custom fine-tunes) are typically downloaded directly and bypass image scanning. A poisoned weight file can contain backdoors that activate only during inference, exfiltrate data, or alter agent behavior.Treat model weights with the same rigor as container images.\n\n### Init-Container Verification Pattern\n\nEvery inference or agent pod that loads model weights runs a mandatory init container that performs verification before the main container starts.\n\n**Core Verification Steps:**\n\nSHA-256 hash validation against a signed manifest.\nCosign blob signature verification.\nManifest stored in Harbor alongside the weights.\n\n**Example Init Container:**\n\n```yaml\ninitContainers:\n - name: verify-weights\n image: registry.internal.example/clawql/weight-verifier:latest\n command:\n - /bin/sh\n - -c\n - |\n cosign verify-blob \\\n --key /etc/signing-keys/cosign.pub \\\n --signature /weights/manifest.sig \\\n /weights/manifest.json\n sha256sum -c /weights/manifest.json\n volumeMounts:\n - name: model-weights\n mountPath: /weights\n - name: signing-keys\n mountPath: /etc/signing-keys\n readOnly: true\n```\n\nThe main inference container only starts if the init container succeeds.\n\n### Harbor Manifest Storage\n\nSigned manifests and weights are stored in Harbor:One unified trust root for images and models.\nReplication and scanning policies apply uniformly.\nKyverno policies can extend verifyImages logic to model-related init containers.\n\n### Key Takeaways\n\nModel weights must be verified on every pod start, not just on first download.\nThe init-container pattern combined with Cosign + SHA-256 provides strong cryptographic assurance.\nStoring manifests in Harbor unifies supply chain controls for both containers and models.\nThis control closes a critical gap that standard container security tools cannot address.\n\nModel integrity ensures the AI brains running your agents are exactly the ones you authorized and have not been tampered with.\n\n**Next module:** Runtime Monitoring and Observability – Falco, Wazuh, Prometheus, and Merkle Metrics.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [NIST AI RMF (integrity / measurement)](https://www.nist.gov/itl/ai-risk-management-framework)\n- [Sigstore blob signing](https://docs.sigstore.dev/cosign/signing/overview/)\n- [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/)\n\n---\n\n## Runtime Monitoring and Observability: Falco, Wazuh, Prometheus, and Merkle Metrics\n\n*Original module on ClawQL Docs: [Runtime Monitoring and Observability: Falco, Wazuh, Prometheus, and Merkle Metrics](https://docs.clawql.com/security/best-practices/runtime-monitoring-observability).*\n\nStrong prevention and containment are incomplete without comprehensive visibility. This module covers the runtime monitoring stack, which provides deep observability into system behavior, detects anomalies, and correlates events across layers.\n\n### The Observability Stack\n\nReference architectures often deploy a full observability suite:**Falco** (eBPF) — syscall-level monitoring and Kubernetes audit log integration. Detects suspicious activity such as unexpected shells, file modifications, or network connections inside containers.\n**Wazuh** — OSS SIEM for log correlation, rule-based alerting, vulnerability detection, and compliance reporting.\n**Prometheus** — metrics collection with custom exporters for Merkle root verification and Cuckoo filter health.\n**Loki** — log aggregation (receives only redacted logs from the Presidio pipeline).\n**Tempo** — distributed tracing for request flows through the intelligent MCP gateway.\n**Kiali** — Istio service mesh topology and traffic visualization.\n\n### Alert Tuning and Ownership\n\nWazuh and Falco generate high volumes of events by default. Runbooks should require:Named owner responsible for alert tuning.\nTiered response (low-confidence → alert only; high-confidence → auto-quarantine via Talon).\nRegular tuning sessions to reduce noise while preserving signal.\n\n### Node Pinning Strategy\n\nObservability workloads are pinned to dedicated non-GPU nodes using node selectors and taints. This prevents monitoring overhead from affecting inference latency or consuming GPU VRAM needed for agents.\n\n### Merkle and Cuckoo Metrics\n\nCustom Prometheus metrics expose:Merkle root verification success/failure rates.\nCuckoo filter false-positive rates (critical for security paths).\nAudit trail completeness.\n\nThese metrics ensure cryptographic integrity is actively monitored, not assumed.\n\n### Key Takeaways\n\nRuntime monitoring turns the platform into a sensor that detects compromise early.\nLayered tools (Falco for low-level, Wazuh for correlation, Prometheus for metrics) provide comprehensive coverage with different strengths.\nAlert tuning and node pinning are operational requirements, not optional.\nMerkle and Cuckoo metrics bring cryptographic controls into day-to-day observability.\n\nEffective monitoring enables the automated response and containment covered in the next module.\n\n**Next module:** Automated Response and Containment – Falco + Talon Quarantine, Panguard Blocking.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Falco](https://falco.org/docs/)\n- [OpenTelemetry](https://opentelemetry.io/docs/)\n- [Prometheus docs](https://prometheus.io/docs/introduction/overview/)\n- [Wazuh](https://documentation.wazuh.com/current/)", + "agentic-ai-security-operations-and-production": "**Modules 13–17** span automated containment, IR and recovery (PICERL), GPU abuse controls, secure workstation and local development practices, and production deployment patterns for full agent stacks.\n\n## Automated Response and Containment: Falco + Talon Quarantine, Panguard Blocking\n\n*Original module on ClawQL Docs: [Automated Response and Containment: Falco + Talon Quarantine, Panguard Blocking](https://docs.clawql.com/security/best-practices/automated-response-containment).*\n\nDetection without automated response leaves security teams overwhelmed. This module covers the high-confidence automated containment mechanisms that limit damage while keeping humans in the loop.\n\n### Confidence Tier Mapping\n\nNot every alert warrants automatic action. Teams often use a tiered system:**Low confidence** — Log only, no notification.\n**Medium confidence** — Alert on-call via Slack/page.\n**High confidence** — Immediate automated containment + page.\n\nRules are tuned and reviewed regularly by the designated alert owner.\n\n### Falco + Talon Quarantine Flow\n\nFalco detects suspicious events (unexpected shell in a pod, privilege escalation, anomalous outbound connection). On high-confidence matches, Talon automatically:Removes the pod from Service endpoints.\nApplies a restrictive NetworkPolicy isolating the pod.\nPreserves the pod for forensic analysis instead of terminating it.\nTriggers a Wazuh alert with full context.\n\nThe pod remains running in quarantine until human review and manual release.\n\n### Panguard Blocking\n\nPanguard provides synchronous blocking at the MCP layer: Rejects out-of-scope or malicious tool calls in under 50 ms.\nReturns a clear error to the agent so it can gracefully handle the block rather than hallucinate or retry.\nLogs the full session for audit.\n\nAgents are coded to surface blocks to the user instead of silently failing.\n\n### Human-in-the-Loop Design\n\nAutomation augments, never replaces, human oversight:All automated actions are reversible.\nQuarantined pods are easily inspected.\nBreak-glass procedures exist for urgent manual intervention.\n\n### Key Takeaways\n\nAutomated containment turns fast detection into fast response, limiting blast radius.\nTiered confidence prevents alert fatigue while enabling immediate action on serious threats.\nFalco + Talon provides pod-level isolation; Panguard provides MCP-level blocking.\nPreservation for forensics is prioritized over immediate termination.\n\nThis automated response layer works hand-in-hand with monitoring (Module 12) and feeds directly into incident response processes.\n\n**Next module:** Incident Response and Recovery – PICERL, WORM Audits, and Tested Backups.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Falco Talon (response)](https://docs.falco.org/projects/talon/)\n- [MITRE D3FEND (response techniques)](https://d3fend.mitre.org/)\n- [NIST SP 800-61 (incident handling)](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)\n\n---\n\n## Incident Response and Recovery: PICERL, WORM Audits, and Tested Backups\n\n*Original module on ClawQL Docs: [Incident Response and Recovery: PICERL, WORM Audits, and Tested Backups](https://docs.clawql.com/security/best-practices/incident-response-recovery-picerl).*\n\nEven with layered prevention, containment, and monitoring, incidents will eventually occur. This module details the structured incident response process, tamper-evident audit capabilities, and the requirement for regularly tested recovery paths.\n\n### PICERL Runbooks\n\nTeams often follow the PICERL framework (Prepare, Identify, Contain, Eradicate, Recover, Lessons Learned). Dedicated runbooks cover common scenarios:Vault lease expiry and emergency revocation\nPanguard outage fallback (graceful degradation of MCP traffic)\nTalon-quarantined pod review and release\nJWT signing key rotation\nWazuh alert escalation paths\n\nAll runbooks are version-controlled, tested quarterly, and accessible via out-of-band communications.\n\n### WORM Audits and Merkle-Rooted Forensics\n\nEvery security-relevant event (MCP tool calls, memory operations, document processing, routing decisions) is recorded with:Full redacted context\nMerkle root linking the event to the broader workflow tree\nImmutable WORM storage\n\nThis creates a tamper-evident forensic trail. Investigators can verify the integrity of logs and reconstruct exact sequences of events.\n\n### Quarterly Restore Testing\n\nBackups are useless if untested. Disaster recovery baselines should mandate:3-2-1+ backup strategy (3 copies, 2 media types, 1 offsite)\nQuarterly full restore tests with documented results\nTests must successfully restore a complete application instance including memory graph, documents, and audit trails\n\nResults are stored in the STRIDE artifact repository with timestamps.\n\n### Out-of-Band Communications\n\nPrimary infrastructure (Slack, internal chat, monitoring) may be compromised or unavailable during an incident. Runbooks should require:Self-hosted Matrix or Mattermost on separate hardware\nPre-defined activation triggers and access lists\nRegular testing of the out-of-band channel\n\n### Key Takeaways\n\nIncident response must be practiced, not theoretical — PICERL runbooks and quarterly restore tests are mandatory.\nWORM storage + Merkle roots provide cryptographically verifiable audit trails for post-incident forensics.\nHuman oversight and out-of-band communications ensure resilience when primary systems are affected.\nRecovery testing closes the loop between prevention and actual operational readiness.\n\nThis process guide ties together all previous controls into a complete security lifecycle.\n\n**Next module:** GPU and Resource Protection – Preventing Rogue Agent Denial-of-Service.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [NIST SP 800-61 Rev. 2 (Computer Security Incident Handling)](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)\n- [FIRST PICERL / CSIRT frameworks](https://www.first.org/)\n- [NIST SP 800-34 (contingency planning)](https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final)\n\n---\n\n## GPU and Resource Protection: Preventing Rogue Agent Denial-of-Service\n\n*Original module on ClawQL Docs: [GPU and Resource Protection: Preventing Rogue Agent Denial-of-Service](https://docs.clawql.com/security/best-practices/gpu-resource-protection).*\n\nAgentic workloads can consume massive GPU resources through runaway loops, infinite tool calling, or maliciously crafted prompts. Without proper controls, a single rogue agent can starve the entire cluster of inference capacity. This module details how to protect GPU resources using quotas, limits, and node isolation.\n\n### ResourceQuota and LimitRange Configuration\n\nUse `ResourceQuota` and `LimitRange` to enforce hard GPU limits at the namespace level:\n\n```yaml\napiVersion: v1\nkind: ResourceQuota\nmetadata:\n name: openclaw-gpu-quota\n namespace: openclaw\nspec:\n hard:\n requests.nvidia.com/gpu: \"4\" # Set to your actual maximum intended concurrency\n limits.nvidia.com/gpu: \"4\"\n```\n\n**Best Practice**: Set the quota to your real maximum agent concurrency (not 1). The goal is a safety ceiling, not artificial restriction. Pair this with a LimitRange to enforce per-pod limits:\n\n```yaml\napiVersion: v1\nkind: LimitRange\nmetadata:\n name: gpu-limit-range\nspec:\n limits:\n - type: Container\n defaultRequest:\n nvidia.com/gpu: 1\n default:\n nvidia.com/gpu: 1\n max:\n nvidia.com/gpu: 2\n```\n\n### Node Selectors and Taints\n\nInference workloads (model serving, agent execution) are pinned to dedicated GPU nodes using node selectors and taints. Observability, logging, and control-plane components are explicitly excluded from these nodes.This isolation prevents monitoring overhead from introducing latency jitter on critical inference paths.\n\n### Preventing Rogue Agent Scenarios\n\n**Runaway tool loops** are contained by Panguard ATR rules and token-budget controls in Memory 2.0.\n**ResourceQuota** acts as the final hard stop if an agent bypasses application-level limits.\n**Kata sandboxing** (Module 8) adds isolation so even a compromised agent cannot directly manipulate GPU devices outside its assigned resources.\n\n### Key Takeaways\n\nGPU quotas and limits are essential to prevent denial-of-service from rogue or poorly behaving agents.\nSet realistic maximums based on your hardware and expected concurrency.\nCombine quotas with node isolation to protect inference performance.\nResource protection must work together with MCP runtime controls and sandboxing for complete defense.\n\nThis specialized protection ensures the platform remains stable and available even under abnormal agent behavior.\n\n**Next module:** Workstation and Local Development Security – Same Posture Everywhere.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Kubernetes ResourceQuota / LimitRange](https://kubernetes.io/docs/concepts/policy/resource-quotas/)\n- [NVIDIA GPU Operator / scheduling (vendor)](https://docs.nvidia.com/datacenter/cloud-native/)\n- [OWASP Top 10 for LLM (availability / DoS themes)](https://owasp.org/www-project-top-10-for-large-language-model-applications/)\n\n---\n\n## Workstation and Local Development Security: Same Posture Everywhere\n\n*Original module on ClawQL Docs: [Workstation and Local Development Security: Same Posture Everywhere](https://docs.clawql.com/security/best-practices/workstation-local-development-security).*\n\nSecurity is not only a production concern. Developer workstations are often the weakest link and the most common entry point for supply chain attacks. Engineering policy should require the same high security standards in local development environments as in production.\n\n### Full Stack on Docker Desktop\n\nDevelopers run the complete clawql-full-stack Helm chart on Docker Desktop with the security bundle enabled:\n\n```yaml\nsecurity:\n fullBundle: true\n kata:\n enabled: true\n panguard:\n enabled: true\n weightVerification:\n enabled: true\n```\n\nThis deploys the intelligent MCP gateway, Panguard, Kyverno policies, and golden images locally.\n\n### Panguard CLI for Local MCP Proxy\n\nThe pga up command starts a local Panguard instance that mirrors production behavior:Same ATR rule enforcement\nSame blocking and auditing\nLocal MCP proxy for Cursor, Claude Desktop, and other clients\n\nAll local tool calls go through the same security chokepoint as production.\n\n### Additional Local Protections\n\n**Aegis EDR** — Process, filesystem, and network monitoring on macOS/Windows workstations.\n**Wazuh Agents** — Forward local events to the central SIEM for correlation with cluster activity.\n**Gitleaks** — Mandatory pre-commit hook (enforced via Husky or similar).\n**YubiKey** — Required for any Git commit that touches Helm charts or critical configuration.\n\n### Developer Onboarding Requirements\n\nEvery new developer must:Install and configure Aegis + Wazuh agent.\nSet up YubiKey for Git signing.\nEnable Gitleaks pre-commit hooks.\nRun the full secure stack on Docker Desktop before contributing.\n\nNo exceptions for “quick local testing.”### Key Takeaways\n\nLocal development must mirror production security posture — there are no trusted environments.\nDeveloper workstations are high-value targets and must be treated as part of the attack surface.\nTools like Panguard CLI, Aegis, and Wazuh agents extend cluster defenses to the desktop.\nConsistent standards across dev and prod reduce the risk of supply chain compromise at the source.\n\nThis local security layer ensures the entire development lifecycle aligns with the platform’s defense-in-depth model.\n\n**Next module:** Production Deployment – One-Command Secure Full Stack.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [CIS Workbench (benchmarks for workstations)](https://www.cisecurity.org/cis-benchmarks)\n- [NIST SP 800-63 (digital identity)](https://pages.nist.gov/800-63-4/)\n- [Sigstore Git signing (keyless)](https://docs.sigstore.dev/signing/git-support/)\n\n---\n\n## Production Deployment: One-Command Secure Full Stack\n\n*Original module on ClawQL Docs: [Production Deployment: One-Command Secure Full Stack](https://docs.clawql.com/security/best-practices/production-deployment-secure-full-stack).*\n\nAll previous security controls culminate in a single, repeatable, secure deployment process. This module provides an example command and checklist to deploy a fully hardened reference deployment with every defense-in-depth layer enabled.\n\n### Security-Enabled Helm Command\n\nDeploy the complete secure stack with one command:bash\n\nhelm upgrade --install clawql-full-stack ./charts/clawql-full-stack \\\n --namespace clawql \\\n --create-namespace \\\n --set security.fullBundle=true \\\n --set security.kata.enabled=true \\\n --set security.panguard.enabled=true \\\n --set security.wazuh.enabled=true \\\n --set security.presidio.enabled=true \\\n --set security.weightVerification.enabled=true \\\n --set gpu.quota.max=4 \\\n --set istio.mTLS=strict \\\n --set supplyChain.allowlistOnly=true\n\nThis enables:Golden distroless images with read-only root\nKata Containers for all MCP workloads\nPanguard + ATR enforcement\nFull observability stack (Falco, Wazuh, Prometheus)\nPresidio redaction pipeline\nModel weight verification\nGPU quotas and node isolation\nStrict Istio mTLS and ServiceEntries\n\n### Deployment Order\n\nHarbor (registry)\nVault (dynamic secrets)\nIstio (ambient profile)\nFalco + Talon + Wazuh\nPanguard\nclawql-full-stack umbrella chart\n\nThe Kubernetes Operator handles reconciliation and self-healing of security components.\n\n### Post-Deploy Verification Checklist\n\nConfirm all pods use Kata runtime where required\nVerify Cosign signatures on running images\nTest Panguard blocking with a deliberate out-of-scope tool call\nValidate model weight verification on a sample inference pod\nCheck Merkle root metrics in Prometheus\nConfirm no external egress except approved ServiceEntries\nRun a full end-to-end MCP tool call and review redacted logs\n\n### Key Takeaways\n\nA secure reference deployment is achieved through a single, opinionated Helm command with explicit security flags.\nDefense-in-depth is enabled by default — not as optional add-ons.\nFollow the documented deployment order and post-deploy checklist to avoid misconfiguration.\nTreat the full secure stack as the baseline; partial deployments are only for non-production testing.\n\nThis completes the operational deployment foundation of the series.\n\n**Next module:** Threat Modeling with STRIDE for Agentic AI Systems.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Helm best practices](https://helm.sh/docs/chart_best_practices/)\n- [Kubernetes production checklist (SIG)](https://github.com/kubernetes/sig-security/tree/main/sig-security-external-audit)\n- [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes)", + "agentic-ai-security-governance-and-owasp-agentic": "**Modules 18–20** focus on STRIDE-style threat modeling for agentic systems, mitigations aligned with the OWASP Agentic Top 10, and a practical quarterly security review checklist you can adapt to your org.\n\n## Threat Modeling with STRIDE for Agentic AI Systems\n\n*Original module on ClawQL Docs: [Threat Modeling with STRIDE for Agentic AI Systems](https://docs.clawql.com/security/best-practices/threat-modeling-stride-agentic-ai).*\n\nThreat modeling is not a one-time exercise. In agentic MCP platforms, where systems are dynamic and agents can chain tools unpredictably, STRIDE must be a living process that evolves with the platform. This module explains how to apply STRIDE specifically to agentic AI systems.\n\n### STRIDE for Agentic Systems\n\nSTRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is adapted to address the unique risks of MCP, autonomous agents, and multi-backend orchestration.\n\n- **S — Spoofing:** Agent identity spoofing via forged session claims or stolen JWTs; model weight impersonation (model-in-the-middle attacks).\n- **T — Tampering:** Merkle tree manipulation of memory graph or documents; tool call parameter tampering in transit; model weight poisoning.\n- **R — Repudiation:** Agents denying tool calls or actions; lack of immutable audit trails.\n- **I — Information disclosure:** PII leakage through logs or MCP responses; cross-tenant or cross-vertical recall exposing restricted data.\n- **D — Denial of service:** Rogue agent GPU exhaustion; MCP gateway flooding or policy-bypass attempts.\n- **E — Elevation of privilege:** Agent escaping sandbox to host; privilege escalation via tool chaining or vertical bypass.\n\n### Living Threat Model Process\n\nMature programs treat the threat model as a living artifact:\n\n- Updated quarterly or on any major change (new integration, new proxy plugin, new MCP tool).\n- Linked directly to controls in your defense-in-depth documentation.\n- Reviewed as part of significant Helm or infrastructure upgrade gates.\n- Stored in version-controlled, signed repositories with full history.\n\nNew components (e.g., a new vertical or external MCP proxy) require a STRIDE entry before production deployment.\n\n### Gating Deployments with STRIDE\n\nNo high-risk production change should ship without:\n\n- Updated STRIDE analysis for the affected components.\n- Mapping of new threats to existing or new controls.\n- Sign-off from the security owner.\n\nThis ensures security scales with platform growth rather than becoming a checkbox.\n\n### Key Takeaways\n\nSTRIDE for agentic systems must address dynamic behaviors like tool chaining, memory recall, and multi-backend routing.\nThreat modeling must be continuous and tied to deployment gates, not a static document.\nEvery new feature or integration requires explicit threat analysis and control mapping.\nA living STRIDE model turns security from reactive to proactive across the entire software lifecycle.\n\nThis strategic practice ties together all technical controls in this curriculum and prepares the platform for long-term evolution.\n\n**Next module:** OWASP Agentic Top 10: Mapping Risks to Architectural Controls.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [Microsoft STRIDE / threat modeling](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats)\n- [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/)\n- [MITRE ATLAS (AI threats)](https://atlas.mitre.org/)\n\n---\n\n## OWASP Agentic Top 10: Mapping Risks to Architectural Controls\n\n*Original module on ClawQL Docs: [OWASP Agentic Top 10: Mapping Risks to Architectural Controls](https://docs.clawql.com/security/best-practices/owasp-agentic-top-10-mitigations).*\n\nThe OWASP Agentic Top 10 highlights the most critical risks in autonomous AI agent systems. These risks apply to any autonomous agent architecture. This module maps each major risk to the specific controls and architecture patterns that mitigate it.\n\n### 1. Prompt Injection / Jailbreaking\n\n**Risk**: Malicious instructions that override agent behavior. \n**Example control patterns**: ATR scoping + Panguard synchronous enforcement. Capabilities are restricted at the tool level, not through prompt filtering. Natural language is never the security boundary.\n\n### 2. Sensitive Information Disclosure\n\n**Risk**: Leakage of PII, credentials, or proprietary data. \n**Example control patterns**: Presidio redaction in the Fluent Bit pipeline before any log write, combined with GraphQL projection and Memory 2.0 token-budget trimming. Redaction-before-write ensures sensitive data never reaches persistent stores.\n\n### 3. Privilege Escalation\n\n**Risk**: Agent gaining unauthorized access to tools or data. \n**Example control patterns**: JWT ATR claims validated on every MCP call, explicit tool scoping per role/vertical, and least-privilege RBAC. Cross-vertical actions require elevated claims.\n\n### 4. Model Denial of Service\n\n**Risk**: Resource exhaustion through runaway loops or heavy inference. \n**Example control patterns**: GPU ResourceQuota + LimitRange, Panguard rate limiting, and token-budget controls in Memory 2.0 recall.\n\n### 5. Supply Chain Vulnerabilities\n\n**Risk**: Compromised dependencies, images, or model weights. \n**Example control patterns**: Harbor as single trust root with allowlist-only resolution, Cosign keyless signing, golden distroless images, and init-container model weight verification.\n\n### 6. Insecure Output Handling\n\n**Risk**: Agent output leading to command injection or unsafe actions. \n**Example control patterns**: Structured tool calling through the intelligent MCP gateway. All outputs are validated and scoped before execution. No raw shell or direct code execution outside Kata sandboxes.\n\n### 7. Training Data / Memory Poisoning\n\n**Risk**: Contaminated knowledge graph or RAG corpus. \n**Example control patterns**: Merkle-rooted provenance on every Memory 2.0 ingest, Cuckoo filter deduplication, and Presidio redaction on document intake. Cross-vertical recall requires explicit elevated ATR.\n\n### 8. Unauthorized Code Execution\n\n**Risk**: Agent executing arbitrary code. \n**Example control patterns**: Kata Containers as default runtime for all MCP/sandbox workloads, combined with explicit sandbox_exec tool gating and read-only root filesystems.\n\n### 9. Overreliance on Agent Autonomy\n\n**Risk**: Blind trust in agent decisions without oversight. \n**Example control patterns**: Human-in-the-loop via HITL approval gates in automation, audit logging of all decisions, and Merkle-rooted workflow trails for full accountability.\n\n### 10. Multi-Step Tool Chaining Attacks\n\n**Risk**: Agents chaining tools in harmful sequences. \n**Example control patterns**: Intelligent routing engine with historical success scoring and sensitivity checks, plus Panguard session-level ATR rules that evaluate cumulative risk across chained calls.\n\n### Key Takeaways\n\nDefense in depth mitigates the OWASP Agentic Top 10 through defense-in-depth rather than single-point solutions.\nThe majority of risks are addressed at the architectural level (ATR scoping, sandboxing, cryptographic provenance) rather than reactive prompt filtering.\nEvery major risk has multiple overlapping controls from different layers of the stack.\nThis mapping is reviewed quarterly as part of the living STRIDE process (Module 18).\n\nThe complete series equips you with both tactical implementation details and strategic understanding of agentic security.\n\n**Next module (final):** Quarterly Security Review Checklist – Keeping Defense-in-Depth Alive.\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [OWASP Top 10 for Agentic Applications (2026)](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)\n- [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/)\n- [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework)\n\n---\n\n## Quarterly Security Review Checklist: Keeping Defense-in-Depth Alive\n\n*Original module on ClawQL Docs: [Quarterly Security Review Checklist: Keeping Defense-in-Depth Alive](https://docs.clawql.com/security/best-practices/quarterly-security-review-checklist).*\n\nDefense-in-depth is not a set-it-and-forget-it architecture. It requires continuous validation and maintenance. This final capstone guide provides the operational checklist that must be executed quarterly to keep the entire security posture effective over time.\n\n### Quarterly Review Cadence\n\nPerform this full review every three months, or after any major change (new vertical, new proxy backend, Helm upgrade, or Kubernetes version bump). Assign a named security owner responsible for completion and documentation.\n\n### 1. Supply Chain & Image Verification\n\nVerify all running images are pulled from Harbor with valid Cosign signatures.\nConfirm allowlist-only resolution is enforced and no external registries are in use.\nReview Trivy/OSV-Scanner results for new critical vulnerabilities.\nValidate SBOMs exist for all production images and model weights.\n\n### 2. Admission Control & Runtime Policies\n\nCheck Kyverno policies are active and in “Enforce” mode.\nConfirm all MCP and sandbox pods use Kata runtime.\nVerify model weight verification init containers are functioning on inference pods.\nReview and approve any temporary namespace exemptions.\n\n### 3. Identity & Zero Trust Controls\n\nAudit Vault dynamic secret leases and revoke any orphaned credentials.\nRotate JWT signing keys if due.\nVerify ATR claim enforcement is working on a sample of MCP tool calls.\nConfirm YubiKey signing requirement is enforced on all Helm chart changes.\n\n### 4. Network & Containment\n\nReview Istio ServiceEntries and egress allowlists against current needs.\nValidate default-deny NetworkPolicy is blocking unauthorized traffic.\nCheck Kiali for unexpected east-west connections.\nConfirm mTLS is in strict mode everywhere.\n\n### 5. Monitoring & Observability\n\nReview Wazuh and Falco alert tuning — reduce noise, improve signal.\nCheck Prometheus metrics for Merkle root verification and Cuckoo filter health.\nConfirm observability workloads are pinned away from GPU nodes.\nTest Talon quarantine and release process on a non-production pod.\n\n### 6. Data Protection & Logging\n\nVerify Presidio redaction is active in the Fluent Bit pipeline.\nSample WORM logs to ensure no raw PII is present.\nConfirm Merkle roots are being recorded for all critical workflows.\n\n### 7. Backup & Recovery Testing\n\nPerform a full restore test of a primary application instance (including memory, documents, and audit trails).\nDocument restore time, success rate, and any issues.\nVerify 3-2-1+ backup strategy is functioning.\n\n### 8. STRIDE & OWASP Review\n\nUpdate the living STRIDE threat model with any new components.\nRe-map OWASP Agentic Top 10 risks to current controls.\nDocument any new threats and required mitigations.\n\n### 9. Documentation & Runbooks\n\nConfirm all PICERL runbooks are current.\nVerify out-of-band communication (Matrix/Mattermost) is tested and ready.\nEnsure this quarterly checklist itself is up to date.\n\n### Key Takeaways\n\nSecurity is a continuous process, not a destination.\nQuarterly reviews with a named owner and documented results prevent drift and degradation.\nEvery layer — supply chain, admission, network, runtime, monitoring, and recovery — must be actively validated.\nTreat the full defense-in-depth stack as a living system that requires ongoing care.\n\nCompleting this checklist keeps your organization’s security posture strong, auditable, and ready for both current and future threats.\n\n**End of curriculum**\n\n## Further reading (vendor-neutral)\n\nThese resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.\n\n- [NIST CSF 2.0](https://www.nist.gov/cyberframework)\n- [CIS Controls](https://www.cisecurity.org/controls)\n- [ISO/IEC 27001 (ISMS overview)](https://www.iso.org/standard/27001)", +} as const + +export type AgenticSecurityCurriculumPillarSlug = + keyof typeof agenticSecurityCurriculumPillarBodies diff --git a/personal-site/src/lib/articles.ts b/personal-site/src/lib/articles.ts index 046069a..dd052cc 100644 --- a/personal-site/src/lib/articles.ts +++ b/personal-site/src/lib/articles.ts @@ -11,7 +11,7 @@ export interface ArticleWithSlug extends Article { slug: string } -/** Articles list and /articles/ pages — sourced only from `featuredLinkedInPosts` in site.ts */ +/** Articles list and /articles/ pages — sourced from `featuredLinkedInPosts` in site.ts (LinkedIn mirrors and syndicated long-form). */ export async function getAllArticles(): Promise { return featuredLinkedInPosts .map((post) => ({ diff --git a/personal-site/src/lib/site.ts b/personal-site/src/lib/site.ts index 4e5336d..853ea03 100644 --- a/personal-site/src/lib/site.ts +++ b/personal-site/src/lib/site.ts @@ -1,3 +1,4 @@ +import { agenticSecurityCurriculumPillarBodies } from '@/lib/agenticSecurityCurriculumPillarBodies.generated' import { featuredLinkedInPostBodies } from '@/lib/featuredLinkedInPostBodies' /** Site-wide copy and links — update here to refresh resume CTAs and featured work. */ @@ -122,14 +123,20 @@ export type FeaturedLinkedInPost = { title: string /** Short excerpt for cards and meta (full narrative is in `body`) */ description: string - /** Full post text mirrored from LinkedIn for reading on this site (see `featuredLinkedInPostBodies.ts`) */ + /** Full markdown body (LinkedIn mirror or long-form; see `featuredLinkedInPostBodies.ts` / generated curriculum) */ body: string - linkedInUrl: string + /** When set, article and home cards link to the original LinkedIn thread */ + linkedInUrl?: string + /** + * When there is no `linkedInUrl`, optional primary outbound link for cards and article footer + * (e.g. canonical curriculum hub on ClawQL Docs). + */ + syndicationSource?: { label: string; href: string } /** Optional secondary links (docs, npm, repo) */ extraLinks?: { label: string; href: string }[] } -/** Home page cards + /articles — metadata here; full post copy in `featuredLinkedInPostBodies.ts`. */ +/** Home page cards + /articles — metadata here; bodies in `featuredLinkedInPostBodies.ts` or generated curriculum pillars. */ export const featuredLinkedInPosts: FeaturedLinkedInPost[] = [ { slug: 'truenas-scale-homelab-recovery', @@ -177,6 +184,120 @@ export const featuredLinkedInPosts: FeaturedLinkedInPost[] = [ }, ], }, + { + slug: 'agentic-ai-security-supply-chain-and-admission', + date: '2026-05-11', + title: + 'Agentic AI Security, Part 1: Supply Chain, Golden Images, and Admission Control', + description: + 'Long-form consolidation of curriculum modules 1–3: digest pinning and private mirrors, golden images and signing in CI, and cluster admission policy for agent and MCP runtimes—with links to each module on ClawQL Docs.', + body: agenticSecurityCurriculumPillarBodies['agentic-ai-security-supply-chain-and-admission'], + syndicationSource: { + label: 'Agentic AI Security Curriculum (ClawQL Docs)', + href: 'https://docs.clawql.com/security/best-practices', + }, + extraLinks: [ + { + label: 'Series source (GitHub)', + href: 'https://github.com/danielsmithdevelopment/ClawQL/tree/main/docs/security/security-best-practices-series', + }, + ], + }, + { + slug: 'agentic-ai-security-identity-zero-trust', + date: '2026-05-10', + title: + 'Agentic AI Security, Part 2: Identity, Least Privilege, and Zero Trust', + description: + 'Modules 4–6 in one guide: scoped identities for agents and tools, zero-trust fundamentals, and advanced Vault, HSM, and provenance patterns—with canonical links per module.', + body: agenticSecurityCurriculumPillarBodies['agentic-ai-security-identity-zero-trust'], + syndicationSource: { + label: 'Agentic AI Security Curriculum (ClawQL Docs)', + href: 'https://docs.clawql.com/security/best-practices', + }, + extraLinks: [ + { + label: 'Series source (GitHub)', + href: 'https://github.com/danielsmithdevelopment/ClawQL/tree/main/docs/security/security-best-practices-series', + }, + ], + }, + { + slug: 'agentic-ai-security-mesh-sandbox-mcp', + date: '2026-05-09', + title: + 'Agentic AI Security, Part 3: Service Mesh, Sandboxing, and MCP Runtime Protection', + description: + 'Modules 7–9 combined: RBAC and mTLS with Istio, Kata vs gVisor sandbox tradeoffs, and MCP runtime protection—plus links to the full modules on docs.clawql.com.', + body: agenticSecurityCurriculumPillarBodies['agentic-ai-security-mesh-sandbox-mcp'], + syndicationSource: { + label: 'Agentic AI Security Curriculum (ClawQL Docs)', + href: 'https://docs.clawql.com/security/best-practices', + }, + extraLinks: [ + { + label: 'Series source (GitHub)', + href: 'https://github.com/danielsmithdevelopment/ClawQL/tree/main/docs/security/security-best-practices-series', + }, + ], + }, + { + slug: 'agentic-ai-security-data-models-observability', + date: '2026-05-08', + title: + 'Agentic AI Security, Part 4: Data Classification, Model Integrity, and Runtime Monitoring', + description: + 'Modules 10–12: data classification and PII in logs, verifying model weights, and observability for agentic workloads—consolidated with outbound links to each original module.', + body: agenticSecurityCurriculumPillarBodies['agentic-ai-security-data-models-observability'], + syndicationSource: { + label: 'Agentic AI Security Curriculum (ClawQL Docs)', + href: 'https://docs.clawql.com/security/best-practices', + }, + extraLinks: [ + { + label: 'Series source (GitHub)', + href: 'https://github.com/danielsmithdevelopment/ClawQL/tree/main/docs/security/security-best-practices-series', + }, + ], + }, + { + slug: 'agentic-ai-security-operations-and-production', + date: '2026-05-07', + title: + 'Agentic AI Security, Part 5: Incident Response, Automation, GPU, Workstations, and Production', + description: + 'Modules 13–17 in depth: automated containment, IR and PICERL, GPU abuse controls, secure local development, and production hardening for agent stacks—with links to every module.', + body: agenticSecurityCurriculumPillarBodies['agentic-ai-security-operations-and-production'], + syndicationSource: { + label: 'Agentic AI Security Curriculum (ClawQL Docs)', + href: 'https://docs.clawql.com/security/best-practices', + }, + extraLinks: [ + { + label: 'Series source (GitHub)', + href: 'https://github.com/danielsmithdevelopment/ClawQL/tree/main/docs/security/security-best-practices-series', + }, + ], + }, + { + slug: 'agentic-ai-security-governance-and-owasp-agentic', + date: '2026-05-06', + title: + 'Agentic AI Security, Part 6: Threat Modeling, OWASP Agentic Top 10, and Quarterly Review', + description: + 'Modules 18–20: STRIDE for agentic AI, OWASP Agentic Top 10 mitigations, and a quarterly security review checklist—merged here with links to the canonical curriculum.', + body: agenticSecurityCurriculumPillarBodies['agentic-ai-security-governance-and-owasp-agentic'], + syndicationSource: { + label: 'Agentic AI Security Curriculum (ClawQL Docs)', + href: 'https://docs.clawql.com/security/best-practices', + }, + extraLinks: [ + { + label: 'Series source (GitHub)', + href: 'https://github.com/danielsmithdevelopment/ClawQL/tree/main/docs/security/security-best-practices-series', + }, + ], + }, ] /** Home page spotlight projects (aligned with resume “Open Source and Projects”) */