Why a Program, Not Just a Policy
A policy without inventory, oversight, and enforcement is just a document. It’s worth being precise about why that distinction matters, because the risk isn’t hypothetical.
Ungoverned AI is unmeasured risk. You can’t assess it, insure against it, or defend it in an audit if you haven’t inventoried where it lives in your environment. Regulators aren’t waiting for you to catch up either. The NIST AI RMF, the Colorado AI Act, and dozens of other state and international statutes are already in force or taking effect, and exposure varies by jurisdiction across AI-specific statutes, privacy law, and ordinary tort and contract liability.
A single AI incident (a data leak, a biased output, a hallucinated commitment a chatbot made on your behalf) can undo years of accumulated trust in a single news cycle. And accountability can’t be retrofitted after the fact: when something goes wrong, “who approved this?” needs to have an answer that already exists, not one you construct under pressure.
The more useful reframe is that governed adoption moves faster than blocked adoption. Organizations that can’t say where AI is running end up defaulting to blanket restrictions, which employees route around anyway. A documented program lets the business move with the technology instead of pretending it can hold the line against it, and it means walking into an audit with evidence instead of excuses.
Grounding the Program in NIST AI RMF
Rather than inventing a governance vocabulary from scratch, it’s worth anchoring on the NIST AI Risk Management Framework, which is voluntary and non-regulatory but has become the de facto industry reference. It organizes the problem into four functions.
- Govern establishes accountability: who owns AI risk, and how decisions get enforced. In practice this looks like an AI governance committee and an acceptable-use policy.
- Map answers whether you actually know where AI is being used today: a use-case inventory, the data sources and stakeholders involved, and the gap between intended purpose and unintended use.
- Measure evaluates whether your AI is behaving as expected, through security and privacy controls, model performance testing, bias testing, and red-teaming.
- Manage covers what happens when AI fails, drifts, or causes harm: mitigation strategies, human-in-the-loop controls, kill switches, rollbacks, and continuous monitoring.
NIST tells you what a mature program covers. It doesn’t tell you how to operationalize it day to day. That’s the gap most organizations get stuck in.
A Four-Step Operating Model
The way we translate the RMF into something a team can actually run is a four-step, vendor-neutral cycle: Discover, Classify & Control, Protect, Govern.
- Discover means seeing every generative AI app, agent, and model in use across the organization, the complete-visibility, no-shadow-AI outcome.
- Classify & Control sorts that discovered activity into sanctioned, tolerated, and unsanctioned use, and applies data-sharing policy granularly enough to produce enforceable acceptable-use rules rather than a blanket yes-or-no.
- Protect blocks sensitive data loss and inline threats before they leave the organization, in real time.
- Govern maintains a living AI inventory, assesses risk continuously, and produces the evidence an audit actually wants to see.
The important structural detail is that this is a cycle, not a checklist: Govern feeds the next Discover. The living inventory a governance function maintains is exactly what surfaces the next wave of shadow AI, so the four steps compound rather than run once and stop. Mapped back to NIST, Govern anchors the whole program, while Map, Measure, and Manage run through all four steps rather than sitting in a single stage.
Two Lenses, One Inventory
A subtlety worth calling out technically: complete AI visibility genuinely requires two different vantage points, and neither one alone is sufficient.
A security stack sees AI on the wire, live GenAI app and model traffic, agentic and MCP traffic, AI agents on the endpoint, observed in real time. What it’s typically blind to is AI embedded inside vendor platforms that’s only visible through attestation, AI running on your own public-facing website or content, and the business context of why a given use exists or who owns it.
A dedicated governance platform sees AI in the artifacts, declared and embedded use surfaced through API scans of websites, repositories, and content, plus vendor and employee attestations that capture purpose, ownership, and risk context. What it’s typically blind to is live traffic; it has no inline enforcement or real-time blocking capability.
The overlap between the two, shadow SaaS AI that shows up both as observed wire traffic and as a declared attestation, is a useful trust signal in itself: when both lenses independently report the same tool, the inventory is corroborating itself, not just aggregating coverage. Every discovery from either lens should reconcile into a single governed AI inventory, risk-ranked and reportable, rather than living in two disconnected systems.
AI Agents Are Identities
This is the piece of the technical picture that governance conversations most often skip, and it’s increasingly the one that matters most. Every AI agent is a non-human identity, and it needs to be governed like one.
Agents inherit both major threat models at once. Like human identities, they’re exposed to compromised credentials, excessive privilege, and session hijacking. Like machine identities, they’re exposed to stolen keys, leaked secrets, and the fact that they operate continuously at machine velocity rather than during business hours. The scale of this shift is already visible in industry data: machine identities now outnumber human identities by roughly 82 to 1, three-quarters of organizations report measurable growth in non-human identities, and current projections put AI agent abuse behind roughly one in four enterprise breaches within the next few years.
The practical implication is that non-human identities should run through the same four-step model as everything else, not a separate program.
- Discover means finding every agent identity, service account, and credential, including the shadow ones nobody provisioned deliberately.
- Classify & Control means assigning a human owner to each one and enforcing least privilege with just-in-time access rather than standing permissions.
- Protect means detecting and blocking credential misuse and session hijacking at runtime.
- Govern means lifecycling the identity (attestation, rotation, and retirement) with real accountability attached. The identity layer isn’t an adjacent workstream; it’s the same methodology pointed at a different asset class.
And practically: agents need owners before they need blockers. Assigning ownership is the higher-leverage first move than trying to restrict what an unowned agent can do.
A Reference Architecture, Independent of Vendor
Whatever stack an organization runs, the underlying architecture reduces to the same shape: a single common control plane, and multiple enforcement points, spanning two distinct traffic types.
The first traffic type is GenAI app and SaaS traffic: employees using generative AI tools in a browser or over the network. The second is agentic AI and AI workload traffic: agents, models, MCP tool calls, and LLM APIs that your own systems invoke programmatically.
Both need policy set from one console, but enforced at different points: the network edge for campus and datacenter traffic, the cloud edge for remote users, the browser or endpoint where enforcement can live natively without rerouting traffic, and — on the agentic side — the API layer embedded directly in an application or agent, the workload layer inside your own cloud VPC, and an inline AI proxy for LLM, MCP, and agent-to-agent calls.
Two additional layers cut across both traffic types. An identity layer authenticates and authorizes every actor (human and non-human) across both domains. A governance layer sits above the enforcement infrastructure entirely: platform-independent, it maintains the AI inventory, the risk register, policy and public notices, and compliance reporting.
The architecture is deliberately boring in the sense that it doesn’t depend on any single product; it’s the blueprint any stack should be evaluated against, not the other way around.
Where This Maps to Known Threats
It’s worth stress-testing the four-step model against a concrete threat list rather than leaving it abstract. The OWASP GenAI LLM Top 10 for 2026 reflects how the threat landscape has shifted toward the agentic era. Excessive Agency has climbed to the third-ranked risk, Unbounded Consumption has risen as agents make far more calls than a human ever would, and a new category, Hidden Context Exposure, absorbs system-prompt leakage as its own concern.
Mapped against the methodology, every one of the ten items lands cleanly in an existing step. Prompt injection, sensitive information disclosure, supply chain risk, data and model poisoning, and improper output handling are all Protect-stage concerns, inline guardrails, AI-aware data loss prevention, and output validation. Excessive agency, unbounded consumption, and vector or embedding weaknesses belong to Classify & Control, least-privilege identity for agents, usage limits at the gateway, and access control over AI data stores. Misinformation is a Govern-stage problem, addressed through output guardrails paired with a human-oversight policy rather than a purely technical control.
The point isn’t that any individual control is novel, as most of this maps to controls security teams already run. It’s that none of the ten items require inventing a fifth step. If your four-step program is complete, it already has an answer for each row on this list.
Sequencing the Rollout
Before selecting a stack, it’s worth being deliberate about sequencing, because the four steps carry very different timeframes and different failure modes if rushed.
- Discover (“see it”) is achievable in days, particularly if you already own SSE, firewall, or EDR licensing that can light up AI discovery with near-zero additional lift.
- Classify & Control (“shape it”) takes weeks, and the discipline that matters most here is starting permissive with coaching controls rather than blocking outright; user friction is what kills governance rollouts, and it’s easier to tighten policy once you have evidence than to walk back a heavy-handed block that drove usage underground.
- Protect (“enforce it”) takes weeks to months and depends heavily on where your traffic actually lives: remote-heavy organizations should favor the cloud edge, datacenter-heavy organizations the network edge, browser-first teams the endpoint.
- Govern (“govern it”) is ongoing by definition; a living inventory doesn’t have a completion date.
A few decision factors are worth resolving explicitly before committing to a path: whether you’re building AI systems or primarily consuming third-party ones (building requires its own API, workload, and proxy enforcement, not just SaaS controls), who owns each agent identity, whether data residency or on-prem constraints narrow which enforcement options are viable, and, again, whether the rollout will coach users toward compliant behavior or attempt to block noncompliant behavior outright.
The Outcome Worth Building Toward
None of this is really about any specific product. It’s about building a program capable of answering four questions with confidence at any point in time: who owns AI risk, and how are decisions enforced; do we know where AI is being used today; how do we know our AI is behaving as expected; and what happens when it fails, drifts, or causes harm.
An organization that can answer all four isn’t slower to adopt AI than a competitor running ungoverned. It’s faster, because it isn’t relitigating the same risk conversation every time a new tool or agent shows up. That’s the actual argument for treating AI governance as infrastructure rather than paperwork: it’s not a gate in front of adoption, it’s what makes fast adoption defensible.
