🎯MITRE ATLAS AML.T0011Rule: ATLAS-DISC-001high

Shadow AI Detection

Description

Detection of unauthorised, undocumented AI workloads running in the organisation's infrastructure. Shadow AI = AI workloads not in the inventory.

⚠️ Risk Impact

Shadow AI workloads escape every governance control because they aren't known. A model in shadow operation is a model with no impact assessment, no fairness measurement, no incident response plan.

🔍 How EchelonGraph Detects This

ATLAS-DISC-001Automated scanner rule

EchelonGraph's Tier 1 Cloud Scanner automatically checks for this condition across all connected cloud accounts. Violations are flagged as high-severity findings with remediation guidance.

🖥️ Manual Verification

terminal
kubectl get crd | grep -iE 'kserve|kubeflow|ray|seldon|runai' && kubectl get inferenceservices -A

🔧 Remediation

Monitor live K8s topology for unexpected KServe / Kubeflow / Ray / Seldon / Run:ai CRDs. Require approval for new AI workloads via admission policy. Run weekly inventory reconciliation against the AI registry.

💀 Real-World Attack Scenario

A data-science team spun up Kubeflow on their dev cluster 'for experimentation'. The 'experimentation' became their production inference pipeline; 8 months later it was serving 40% of customer-facing recommendations. Security found out via the cluster bill. Zero documentation existed; everything in MITRE ATLAS shadow-AI scope.

💰 Cost of Non-Compliance

Shadow AI in 2024: 31% of enterprises report material shadow-AI activity (Forrester). Per-incident cost when shadow surfaces in regulator probe: avg $1.4M (PwC 2024).

📋 Audit Questions

  • 1.Show me the AI inventory.
  • 2.When was it last reconciled against live cluster topology?
  • 3.What admission policy gates new AI workload creation?
  • 4.Has any shadow AI been detected and remediated in the last 12 months?

🎯 MITRE ATT&CK Mapping

T1538 — Cloud Service Discovery

🏗️ Infrastructure as Code Fix

main.tf
resource "kyverno_policy" "ai_workload_inventory" {
  metadata { name = "ai-workloads-must-be-registered" }
  spec = jsonencode({
    validationFailureAction = "enforce"
    rules = [{
      name = "require-registry-annotation"
      match = { resources = { kinds = ["InferenceService","Notebook","RayCluster","SeldonDeployment"] } }
      validate = {
        message = "AI workloads must have echelongraph.io/registry-id annotation"
        pattern = { metadata = { annotations = { "echelongraph.io/registry-id" = "?*" } } }
      }
    }]
  })
}

⚡ Common Pitfalls

  • ⛔Inventory exists but isn't reconciled — drift accumulates silently
  • ⛔Admission policy in 'audit' mode only — alerts but doesn't block
  • ⛔Missing newer AI runtimes (Ray, Run:ai, vLLM) in admission scope

📈 Business Value

Shadow AI detection prevents the 'we didn't know we had it' defence — which doesn't work in any 2024-2026 regulatory framework.

⏱️ Effort Estimate

Manual

2 weeks for inventory + admission policy

With EchelonGraph

EchelonGraph's Tier 3 watcher detects shadow AI within seconds of CRD creation

🔗 Cross-Framework References

AIRMF-MAP-1.1EUAIA-ART9-RMISO42001-8.3

Automate MITRE ATLAS AML.T0011 compliance

EchelonGraph continuously monitors this control across all your cloud accounts.

Start Free →