Overview — the AI governance & security layer cake

The thesis: standing up a governed enterprise AI platform isn’t one purchase — it’s a stack. Each layer does one job, has a priority (Day-1 / Day-2 / optional), and a shortlist of vendors competing for the slot. This wiki maps that stack for a hedge-fund / asset-manager CTO: what each layer is for, when you actually need it, who fills it, who owns whom, and how to tell neighbors apart. It also doubles as scaffolding for a CTO usage/evaluation survey (see survey-blueprint).

If you read nothing else, read day-1-for-a-50-person-fund — the opinionated minimum.

The three organizing ideas

1. The layer cake (the spine)

Seven layers, top to bottom. Each links to its categories:

  1. Foundationidentity-access, non-human-identity, identity-governance, secrets-management, siem-soc, ai-soc-analysts, edr-xdr, network-security-sase, sspm, software-supply-chain, anti-deepfake. The security estate you mostly already own; extend it to AI.
  2. Datadspm, dlp, data-access-governance. Know where sensitive data is, stop it walking out, right-size who can read it.
  3. AI model & promptai-runtime-security, ai-gateway, llm-observability, ai-red-teaming, ai-access-governance, ai-spm, agent-runtime-security, authorization-engine, mcp-gateway, tool-identity-integration. The AI-specific control plane — the heart of this wiki.
  4. Retrievalcontent-sources, vector-retrieval, entitlement-aware-rag. Once you do RAG, the AI must never surface a doc the user couldn’t already open.
  5. User experienceenterprise-ai-assistant, third-party-ai-apps, enterprise-browser, browser-security-extension. The governed tools people actually use.
  6. Governanceai-governance-platform, enterprise-grc, vendor-risk, comms-surveillance, ephemeral-environments, policy-as-code. Prove and manage AI risk to regulators and allocators.
  7. Policy / processtrust-zone-segmentation, risk-tiers, promotion-gates, hitl-approvals, acceptable-use-policies. Practices, not products.

Full canonical map: taxonomy.md (42 categories). Catalog: index.

2. The three trust zones (red / yellow / green)

Segment where agents run so the dangerous combination never lines up:

  • Red zone — agents “YOLO” on the open Internet, no access to internal data.
  • Yellow zone — agents reach the data warehouse but cannot reach the Internet to exfiltrate.
  • Green zone — agents touch internal production systems, but only under extreme vetting and governance, and no untrusted prompt input.

trust-zone-segmentation is the architectural control that makes the next idea impossible by construction. ephemeral-environments are how you implement disposable, zone-scoped compute.

3. The lethal trifecta — the core agent-security threat model

From Simon Willison: three ingredients that are individually fine but catastrophic when they combine in one agent context

  1. Untrusted input (a prompt/content an attacker controls),
  2. Access to sensitive data, and
  3. An egress path to exfiltrate it.

A governed chatbot behind a login rarely assembles all three. An agent that reads external content, holds credentials, and calls tools assembles them by default — which is why the trifecta is the organizing threat model for the agent-security slice of the stack (runtime firewalls, MCP gateways, agent authorization, tool identity, browsers, trust zones), while the rest of the stack is better described in plain risk terms. Each agent-facing control removes one ingredient:

What’s actually Day-1 vs Day-2

Consolidation: the map is moving under you

2025–26 saw a wave of M&A — much of the AI-runtime/guardrail field is now inside platforms (Palo Alto, Cisco, CrowdStrike, SentinelOne, F5, Zscaler, Check Point, Cato). If you already run one of those, you may get an AI-firewall/guardrail capability as a module — check before buying standalone. Full, dated, verified detail: ai-security-m-and-a-map.

How to navigate this wiki