The SANS AI Security Maturity Model has a Stage 3 problem. Here's the architecture that solves it.

The SANS AI Security Maturity Model is the most useful thing I've read on AI security in a while. It's also where most enterprises hit a wall, the Stage 3 gap isn't a policy gap, it's an infrastructure gap.

The model, and what it actually demands

SANS published its AI Security Maturity Model (AISMM) recently. Chris Cochran, their Field CISO and VP of AI Security, is the author. The pitch: turn AI security from a roundtable topic into something a CISO can measure. Not where the roadmap claims you'll be next year. Where the evidence puts you today.

It's a two-axis grid: three pillars of capability scored across five stages of maturity.

The three pillars:

• Protect: securing your AI against adversarial attacks, prompt injection, model theft, and supply chain risk.
• Utilize: using AI to detect threats, automate response, and improve security operations.
• Govern: policy, risk management, oversight. The foundation everything else rests on.

And the five stages, ascending:

1. Stage 1, Unaware / Ad Hoc. No formal approach. Unmanaged AI use across the org, no inventory, no controls. Risk is invisible because nobody's looking for it.
2. Stage 2, Reactive / Policy-Emerging. Basic policies exist; tools are either blocked outright or allowed without logging. SANS calls this the Framework of No. The practical outcome, and they're blunt about it, is that AI usage goes underground rather than stopping.
3. Stage 3, Defined / Risk-Informed. Formal governance, controlled deployment, and the first stage where controls are enforced at runtime instead of on paper. A complete classified inventory of every AI system and agent. Distinct Non-Human Identities (NHIs) per agent. Prompt-injection defences and structured logging at the data plane. A documented human owner for every deployed agent.
4. Stage 4, Managed / Integrated. AI embedded in security ops, systems secured by design. Confused Deputy isolation between untrusted inputs and agent execution. Autonomous response for validated scenarios. Formal NHI lifecycle with automated credential rotation. Board-level AI risk reporting.
5. Stage 5, Optimizing / Adaptive. AI-native security with autonomous capabilities. Custom ML models tuned to your environment, A/B testing of detection models, AI-powered threat hunting. Security as a continuously improving discipline, not a static control set.

It maps to NIST AI RMF, the EU AI Act, ISO 42001 and OWASP AI Exchange. For EMEA enterprises under GDPR, DORA and NIS2, those aren't optional alignments. They're audit requirements.

Here's what the framework makes obvious: most enterprises are stuck at Stage 2 heading into Stage 3, and that transition is the hardest one. Not for lack of ambition. Because Stage 3 demands specific, concrete, infrastructure-level controls that no policy document can deliver on its own.

This post maps those requirements, pillar by pillar, stage by stage, to the Solo agentic stack: agentgateway, agentregistry and kagent. SANS tells you what you need. The Solo stack is how you build it on Kubernetes.

Why Stage 2 → Stage 3 is where most enterprises stall

Stage 3 is a real inflection point, not the next checkbox on a maturity ladder. Here's why.

Stage 2 is the Framework of No: a binary acceptable-use policy that usually reads "don't use AI" or "use with caution", tools blocked outright or allowed without logging, no governance structure to speak of. SANS is blunt about the outcome. Block-based policies push AI usage underground, they don't prevent it. Shadow AI is only Shadow AI when a policy exists to violate. But the underlying risk, ungoverned agents calling ungoverned tools with ungoverned credentials, doesn't care what your policy says.

Stage 3, Defined / Risk-Informed, changes the rules. It requires:

• A complete, classified inventory of every AI system, agent and model in your environment.
• Internal AI agents assigned distinct Non-Human Identities (NHIs) with strict, scoped access control.
• Prompt injection and instruction manipulation defences implemented at the data plane.
• Input validation and output filtering deployed in production.
• Structured logging with trace IDs across every agent step and tool call.
• Runtime validation of dynamically loaded agent tools and plugins.
• Secure agent-to-agent communication with mutual authentication.
• Human-in-the-loop thresholds and automated policy enforcement defined for high-risk agent workflows.
• Every deployed AI agent has a documented human owner.

None of it is a policy document or a training programme. It's infrastructure. SANS's own evidence scale makes this explicit: a written or draft policy alone caps you at score 2, "Developing". To reach Stage 3 ("Established") you need approved policy and consistent execution and stakeholder awareness confirmed. You need a data plane that enforces the controls at runtime.

That data plane is agentgateway. The catalog that ensures only vetted tools reach it is agentregistry. The Kubernetes-native layer that makes agents first-class workloads with observable, ownable identities is kagent.

The three planes of the Solo agentic stack

Quick orientation before the pillar mapping. The three products aren't independent tools bolted together. They're three distinct planes of one stack:

Competitors sell pieces. The hyperscalers (AWS Bedrock AgentCore, Google Vertex AI Agent Builder, Azure AI Foundry) each have capable agentic offerings inside their own cloud. The gap is cross-cloud governance: identity stops at the cloud boundary, observability fragments, policy enforcement duplicates. Solo runs on your Kubernetes cluster, under your IdP, with your audit trail, no matter which LLM or cloud the agent calls into.

Both agentgateway and agentregistry are open-governance now: agentgateway in the Linux Foundation, agentregistry in the CNCF (contributed March 2026, announced at KubeCon EU 2026 in Amsterdam). kagent is a CNCF sandbox project.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: snowflake-mcp-route
  namespace: agents
spec:
  parentRefs:
    - name: agentgateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /mcp/snowflake
      backendRefs:
        - name: snowflake-mcp-server
          port: 8080
---
apiVersion: gateway.solo.io/v1alpha1
kind: AgentgatewayPolicy
metadata:
  name: snowflake-jwt-policy
  namespace: agents
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: snowflake-mcp-route
  jwtAuth:
    issuer: "https://your-idp.example.com"
    audiences:
      - "snowflake-mcp"
    remoteJwks:
      uri: "https://your-idp.example.com/.well-known/jwks.json"

apiVersion: kagent.dev/v1alpha1
kind: Agent
metadata:
  name: threat-triage-agent
  namespace: security-ops
  annotations:
    kagent.dev/owner: "security-team@yourorg.com"
    kagent.dev/approved-by: "security-governance-council"
spec:
  description: "Triages security alerts and enriches with threat intelligence"
  systemPrompt: |
    You are a security operations agent. Triage incoming alerts,
    enrich with threat intelligence, and escalate based on severity.
    Do not take remediation actions without explicit human approval.
  tools:
    - name: threat-intel-lookup
      mcpServer: threat-intel-mcp
    - name: alert-enrichment
      mcpServer: siem-mcp
    - name: escalation-notify
      mcpServer: pagerduty-mcp
  modelConfig:
    provider: anthropic
    model: claude-sonnet-4-20250514

The mapping table: SANS AISMM stages vs. Solo stack

What "Shadow AI" looks like at the infrastructure layer

One of the model's sharpest moves is the split between BYOAI (Bring Your Own AI, policy-neutral, pre-policy) and Shadow AI (BYOAI that violates an existing policy, only possible once a policy exists to violate).

Most enterprises treat Shadow AI as a human-behaviour problem: employees using unapproved tools, developers standing up agents on their laptops, teams wiring up LLM endpoints without telling IT. The usual response is DLP rules, training programmes, and acceptable-use policies.

The Solo stack treats it as an infrastructure problem with an infrastructure solution. What that looks like:

• agentregistry runtime discovery scans connected runtimes (Kubernetes clusters, AWS AgentCore environments, Google Vertex AI deployments) and flags agents, MCP servers, and tools that are deployed but not registered. Shadow inventory: real workloads with real access, outside the governed perimeter.
• agentgateway policy enforcement means even if a developer deploys an unregistered MCP server inside the cluster, agents going through the gateway can't call it. The backend config is generated from agentregistry's approved catalog. If it isn't approved, it isn't reachable.
• kagent's declarative model means any agent not defined as a CRD misses out on the operational benefits: lifecycle management, identity, reconciliation. That creates an incentive for developers to register agents properly rather than skirt the system.

That's the Framework of No solved architecturally, not culturally. You're not trying to stop people from using AI. You're making sure anything they deploy lands inside the governed perimeter, not alongside it.

Conclusion

What stands out about the SANS AISMM is how actionable it is. NIST AI RMF has the comprehensive ground covered. AISMM tells you what evidence you need at each stage, which pillar is capping your overall score, and what to build next.

The Stage 3 gap is real. Most enterprises have governance documents and security policies. Very few have the infrastructure that makes those policies enforceable at runtime, where agents are actually making decisions, calling tools, and producing outputs that have real operational consequences.

The Solo stack closes that gap. agentgateway enforces policy at the data plane. agentregistry governs the tool catalog. kagent makes agents first-class Kubernetes workloads with identity, ownership, and audit trails built in.

The framework describes the problem. The stack solves it.

Further reading

• SANS AI Security Maturity Model: the source framework this article references. SANS gates the eBook download behind a signup form; that's the canonical source if you want the full text.
• agentgateway documentation: Kubernetes deployment, JWT auth, MCP connectivity, guardrails.
• kagent documentation: agent CRDs, A2A, tool configuration.
• agentregistry on GitHub: CNCF sandbox project, open source catalog.
• Solo.io agentic AI product page: Enterprise capabilities and commercial support.
• Securing MCP and agentic systems, common customer questions: the companion field guide to the patterns referenced throughout this post.