MODULE 10 — Shadow AI & Enterprise AI Governance¶

⚠️ Currency note: This module is accurate as of October 2026. Survey statistics, product names (agent registries, identity services, discovery tools), and regulatory dates are volatile. Current values live in Appendix G — Current Landscape. The statistics in §10.1 come from the studies cited and were not re-verified in the October 2026 refresh; quote them as "as of the cited study."

10.1 The Scale of the Problem¶

Shadow AI is no longer a fringe phenomenon. It is the default state of AI use in most enterprises.

The 2026 Verizon Data Breach Investigations Report documents a data point that should fundamentally change how architects think about AI governance: 45% of employees are regular AI users on corporate devices — up from 15% in 2025. That is a tripling in a single twelve-month window. Shadow AI is now the third most common non-malicious insider action in the data loss prevention dataset, representing a fourfold increase in percentage terms from the previous year.

Additional data points that characterize the current reality:

70% of enterprise AI operates outside IT oversight (Lenovo, April 2026)
82% of paste operations into AI tools come from personal, unmanaged accounts (LayerX 2025)
77% of enterprise AI users regularly copy and paste data into chatbots, and 22% of those operations contain PII or payment card information
40% of file uploads to AI platforms include PII or PCI data (LayerX 2025)
33% of employees using unsanctioned tools shared research data or datasets, 27% shared employee data including salaries and performance records, and 23% inputted company financial statements (BlackFog, January 2026)
67% of employees use AI tools at work, only 18% of organizations have formal AI security policies (Salesforce 2026)
Shadow AI breaches cost $670,000 more than standard breaches (IBM 2025)
The average enterprise has 14 distinct AI tools in use — IT is aware of only 4–5 (Productiv 2026)

The Samsung incident is the canonical case study: in 2023, three semiconductor engineers used ChatGPT to help with their work. One pasted proprietary source code to fix a bug. Another transcribed internal meeting notes. The data crossed Samsung's perimeter and was processed by OpenAI's infrastructure. Samsung subsequently banned ChatGPT internally — but the data had already left.

This is not a rare edge case. This is daily behavior at scale.

10.2 Why Shadow AI Happens¶

Understanding why employees use unsanctioned AI is prerequisite to designing governance that works. Most commentary frames Shadow AI as a security problem to be contained. The root cause is a productivity gap.

The productivity demand is real. Employees who use AI tools are, in many cases, genuinely more productive. An AI-assisted developer writes code faster. An AI-assisted analyst summarizes research faster. An AI-assisted writer produces first drafts faster. The tools deliver real value.

The approved alternative is often absent, slow, or inferior. When a financial analyst needs to summarize 20 earnings call transcripts and IT's official AI tool is not approved yet, or is in a pilot for a different team, or requires a 6-week procurement process — the analyst uses ChatGPT. The choice is not between "sanctioned tool" and "unsanctioned tool." It is between "getting the work done today" and "not getting the work done today."

Most employees don't understand the data risk. A 2025 Awareways study found that while most employees know the rules around AI usage, the majority bypass them anyway. More telling: many employees who are "violating policy" genuinely do not understand what happens to data they paste into ChatGPT. They perceive it as a tool they are using, not as data they are transmitting to a third-party cloud service that may retain, log, and potentially train on it.

The governance implication: A Shadow AI strategy that only restricts without enabling is a strategy that drives Shadow AI further underground — employees use personal devices and personal accounts rather than managed corporate devices. Governance must address the productivity demand, not just the security risk.

10.3 The Shadow AI Taxonomy¶

Not all Shadow AI carries the same risk. A taxonomy helps prioritize governance effort.

By Data Sensitivity¶

SHADOW AI DATA RISK TIERS

TIER 1: CRITICAL DATA (immediate action required)
  Examples being submitted to AI:
  - Source code (proprietary algorithms, security credentials)
  - Financial data (unreleased earnings, M&A analysis)
  - Customer PII (names, accounts, contact information)
  - Employee data (salaries, performance records, HR matters)
  - Clinical data (patient records, trial data)
  - Legal privileged communications

  Risk: Regulatory violation, IP theft, competitive exposure
  Detection: DLP on AI domains + content classification
  Response: Block or require approved alternative immediately

TIER 2: SENSITIVE BUSINESS DATA (governance required)
  Examples:
  - Internal strategy documents
  - Product roadmaps
  - Customer contracts and SOWs
  - Internal communications about business matters
  - Vendor pricing and negotiation documents

  Risk: Competitive exposure, contractual violation
  Detection: Sensitivity label monitoring
  Response: Require approved enterprise AI tool

TIER 3: GENERAL BUSINESS DATA (monitor and guide)
  Examples:
  - Meeting notes without sensitive content
  - General analysis and research tasks
  - Document formatting and editing
  - Email drafting for non-sensitive topics
  - General coding assistance (non-proprietary code)

  Risk: Low — mainly productivity and data hygiene
  Response: Acceptable use policy, prefer approved tools

By Tool Category¶

SHADOW AI TOOL RISK PROFILE

HIGHEST RISK:
  Consumer ChatGPT (free tier): Data used for training by default
  Personal Claude/Gemini accounts: No enterprise data agreements
  Consumer AI browser extensions: Continuous data collection

  Problem: No enterprise data processing agreements, potential
           training data retention, unmanaged access tokens

MEDIUM RISK:
  Enterprise ChatGPT/Claude/Gemini accounts (paid, non-corporate):
    Data processing agreements exist at subscription level
    but not under enterprise contract with your organization
  Niche AI SaaS tools: Variable data handling policies

  Problem: Individual employees accepting terms on behalf
           of the organization; inconsistent data governance

LOWER RISK (still requires governance):
  Developer tools with AI features (GitHub Copilot personal):
    Well-defined data policies but not under corporate contract
  AI features in approved SaaS: Often AI-enabled without IT awareness
    (Notion AI, Grammarly, Salesforce Einstein, etc.)

The Browser Extension Problem¶

The 2026 DBIR identifies AI browser extensions as the fastest-growing Shadow AI vector. The average company has more than 15% of users with unauthorized AI extensions installed on their browsers. Many of these extensions are designed to collect and retain the context of pages the user visits — including internal applications, intranets, and sensitive web-based tools — in order to provide AI-assisted summaries and suggestions.

Unlike pasting content into ChatGPT (a conscious decision), browser extensions operate continuously and passively. An employee who would never paste client data into a chatbot may have a browser extension that is automatically summarizing every page they visit — including the CRM with client data, the HRIS with employee data, and the internal knowledge base with proprietary content.

10.4 Detection: Finding What You Don't Know Exists¶

Standard IT discovery methods cannot find most shadow AI. The fix requires scanning codebases, configurations, and documents — not asking employees to self-report.

Detection Signals¶

Network/DNS layer: - DNS queries and HTTP traffic to known AI service endpoints (api.openai.com, claude.ai, gemini.google.com, and the long tail of AI SaaS domains) - Anomalous outbound data volume to AI domains (employees uploading large files) - API key patterns in network traffic (suggests programmatic AI use, not just web UI)

Endpoint layer: - Browser extensions inventory: weekly audit of installed extensions on managed devices - Application inventory: AI desktop applications (Claude Desktop, ChatGPT desktop, etc.) - Clipboard monitoring signals: large copy operations followed by browser navigation to AI domains - Development environment scanning: .env files, configuration files containing AI API keys

Identity and access layer: - OAuth grants to AI services: enumerate applications that have been granted access to corporate identity providers (Entra ID, Okta) - API keys in code repositories: secret scanning on all repositories (GitHub Advanced Security, GitLeaks) - Expense reports: employees purchasing AI subscriptions using corporate cards (this is a data signal, not just a financial one)

Data layer: - DLP alerts on AI domain endpoints - Sensitivity label activity: labeled files being accessed, then AI tools being used shortly after - Email exfiltration to personal accounts followed by AI service access

Detection Tooling¶

SHADOW AI DETECTION STACK

Network layer:
  - CASB (Cloud Access Security Broker): Netskope, Microsoft Defender for Cloud Apps
    → Monitors and controls data flow to cloud services including AI
  - DNS filtering: Cisco Umbrella, Zscaler
    → Block or alert on unapproved AI domains

Endpoint layer:
  - Endpoint DLP: Microsoft Purview DLP, CrowdStrike
    → Block upload of classified content to AI services
  - MDM extension audit: Microsoft Intune
    → Weekly enumeration of browser extensions on managed devices

Identity layer:
  - OAuth audit: Entra ID, Okta → list all third-party app grants
  - Secret scanning: GitHub Advanced Security, Trufflehog
    → Finds AI API keys in code repositories

Specialized:
  - Knostic, Opsins: AI-specific visibility tools that map what
    AI can "see" in your environment
  - Varonis, Tenable: Data security platforms with AI risk features

The AI Inventory: What You Should Know But Don't¶

Under the EU AI Act, you cannot classify systems by risk tier, meet registration and transparency duties, or show which obligations apply to you without an inventory. An incomplete inventory is a compliance gap, not just a security gap. But most organizations cannot produce a complete inventory of the AI systems they operate, let alone the AI tools their employees are using.

AI INVENTORY REQUIREMENTS

For each AI system or tool in use, document:
  ├── Name, vendor, version
  ├── Purpose and business function
  ├── Owning team and technical contact
  ├── User population (who uses it, how many)
  ├── Data processed (what categories, what classification)
  ├── Data residency (where is data processed and stored?)
  ├── Training data retention (does the vendor train on your data?)
  ├── Authorization status (IT-approved, in-review, unapproved)
  ├── Contract and data processing agreement status
  ├── EU AI Act risk tier (if applicable)
  └── Last reviewed date

Inventory scope includes:
  - Enterprise-purchased AI tools (obvious)
  - AI features embedded in approved SaaS (often invisible)
  - Employee-purchased AI tools expensed to corporate (often invisible)
  - AI tools used via personal accounts (shadow — requires detection)
  - AI features in development tools (GitHub Copilot, IDE assistants)
  - AI browser extensions (often invisible without endpoint audit)

10.5 The Governance Spectrum: Block to Enable¶

Organizations respond to Shadow AI along a spectrum. The choice of position on this spectrum has significant consequences for both security outcomes and employee productivity.

THE GOVERNANCE SPECTRUM

BLOCK ──────────────────────────────────────────────────► ENABLE

|                |                |               |              |
Block all      Monitor         Restrict to    Provide       Actively
unapproved    and alert       approved       approved     encourage
AI access                     use cases      alternatives  AI use

Outcome:       Outcome:        Outcome:        Outcome:      Outcome:
Employees      Organization    Reduced but     Legitimate    Maximum
use personal   learns what's   not eliminated  need met;     productivity
devices and    happening but   Shadow AI       Shadow AI     with governance
personal       cannot act                      reduced
accounts
effectively

Security:      Security:       Security:       Security:     Security:
Worse          Partial         Better          Good          Requires
(lost                                                        maturity
visibility)

The blocking paradox. Organizations that block AI access without providing an alternative do not eliminate AI use — they push it to personal devices and personal accounts, which removes it entirely from the organization's visibility and control. A Menlo Security study found that 68% of employees use free-tier AI tools via personal accounts. Blocking corporate access to ChatGPT does not stop those 68% — it moves them to their phones and home computers. The organization loses visibility and gains nothing.

The enabling insight. A Healthcare Brew 2026 study found a significant drop in unauthorized AI usage when approved alternatives are provided. The governance strategy that most reduces risk is the one that most reduces the productivity gap — by giving employees good approved tools, employees have less reason to seek shadow alternatives.

10.6 The AI Acceptable Use Policy¶

An AI acceptable use policy (AUP) is the governance foundation. Without it, employees are making individual judgment calls about what is acceptable — with wildly variable results. With it, expectations are clear, training is possible, and enforcement is possible.

AUP Structure¶

Section 1: Purpose and Scope

This policy governs the use of artificial intelligence tools — including large language models, AI assistants, AI code generators, and AI-enabled features in software applications — by employees, contractors, and vendors acting on behalf of [Organization]. It applies to all AI tool use conducted in connection with your work for [Organization], whether on corporate devices, personal devices, or personal accounts.

Section 2: Approved AI Tools

The following AI tools are approved for use with the data categories specified:

APPROVED AI TOOL MATRIX

Tool                    | Data Classification Permitted
------------------------|----------------------------------------
[Internal AI Platform]  | All classifications including RESTRICTED
Microsoft 365 Copilot   | Up to CONFIDENTIAL (M365 data only)
GitHub Copilot Ent.     | Non-proprietary code, public libraries
[Approved RAG System]   | Up to CONFIDENTIAL (internal Q&A)

PROHIBITED TOOLS (for any corporate data):
  - Personal ChatGPT accounts (free tier)
  - Personal Claude accounts (free tier)
  - Any AI tool not listed in the approved tool matrix
  - AI browser extensions not approved by IT
  - AI features in personal SaaS accounts

Section 3: Data Use Rules

Always permitted (with approved tools only): - Drafting emails and documents that do not contain CONFIDENTIAL data - Summarizing publicly available information - Generating code for non-proprietary logic - Formatting and editing non-sensitive content - Research and analysis using public information

Permitted with approved tools only (not consumer tools): - Summarizing internal documents and meeting notes - Analyzing business data and generating reports - Customer-related communications and analysis - Code generation for proprietary or customer-facing systems

Prohibited regardless of tool: - Submitting personally identifiable information about customers or employees - Submitting financial data not yet publicly disclosed (earnings, M&A) - Submitting content covered by NDA or attorney-client privilege - Submitting source code to unapproved tools - Submitting clinical or patient data to any tool not meeting HIPAA requirements - Using AI-generated content without human review for regulatory filings

Section 4: Human Oversight Requirements

AI is a tool, not a decision-maker. The following content requires human review before use: - Customer-facing communications - Financial analysis and recommendations - Legal and compliance documents - Any content used in regulatory submissions - Marketing content making factual claims

Section 5: Verification and Quality

Employees are responsible for the accuracy of AI-generated content they submit or act upon. "The AI said so" is not an acceptable defense for errors in submitted work.

Section 6: Reporting

Report unauthorized AI tool usage by others or data incidents related to AI use to [security contact]. Report a new AI tool you believe would be useful for business purposes to IT for review.

10.7 The AI Tool Catalog and Review Process¶

The approved tool matrix in the AUP is only useful if it is current and the review process is fast enough that employees don't give up and use shadow tools while waiting.

The Tool Review Process¶

AI TOOL REVIEW PROCESS

Intake:
  ├── Any employee can nominate a tool via the IT portal
  ├── Form captures: tool name, use case, data types that would be used,
  │     estimated user count, business justification
  └── Target response time: decision within 10 business days

Review criteria:
  ├── Data processing agreement: does the vendor have an
  │     enterprise DPA that meets your data classification requirements?
  ├── Training data: are your prompts/data used to train the model?
  │     (OpenAI enterprise: no; consumer ChatGPT: varies)
  ├── Data residency: where is data processed and stored?
  ├── Security certifications: SOC2 Type II, ISO 27001, relevant compliance?
  ├── Access controls: MFA, SSO integration, audit logging available?
  ├── Incident history: any significant data breach incidents?
  └── Integration risk: does the tool require OAuth grants to M365 or other
        corporate systems?

Outcome categories:
  ├── APPROVED: added to tool catalog with permitted data classification
  ├── APPROVED WITH CONDITIONS: approved for specific data classifications only
  ├── IN REVIEW: more information needed, employee notified
  ├── REJECTED: reason documented, alternative suggested where possible
  └── ESCALATED: legal/compliance review required

Review team:
  ├── IT Security (primary reviewer)
  ├── Legal/Privacy (data processing agreement review)
  ├── Compliance (regulatory requirements check)
  └── Business stakeholder from requesting department (use case validation)

Making the Catalog Accessible¶

A tool catalog nobody knows about is a tool catalog nobody uses. The catalog must be: - Searchable by tool name and use case - Current — updated within 48 hours of a decision - Visible — linked from the AUP, accessible from the employee intranet, discoverable through IT helpdesk - Actionable — the catalog page for each approved tool includes the login URL, the SSO setup instructions, and the data classification it's approved for

The goal is to make the approved tool the path of least resistance. If finding the approved tool requires more effort than just using ChatGPT, employees will use ChatGPT.

10.8 Governance Without Blocking Productivity: The Practical Balance¶

The organizations that have the best Shadow AI outcomes — lowest rate of unauthorized tool use, highest rate of appropriate AI adoption — share a common pattern: they solve the productivity problem first and the security problem second.

The Enable-and-Govern Approach¶

Step 1: Acknowledge the productivity reality. Accept that AI tools deliver real value. The goal is to channel that value through governed tools, not to eliminate it.

Step 2: Close the gap faster than employees go around it. If the approval process for a new AI tool takes 8 weeks, employees will use the unapproved alternative for 8 weeks. Streamline the review process. Fast-track review for low-risk tools. Pre-approve categories of tools with similar risk profiles.

Step 3: Make the approved tool better than the shadow alternative. This is the most powerful governance control. An approved internal AI tool that has better data (company knowledge base, internal documents) and better integration (SSO, existing workflow) will be preferred by employees over a general-purpose consumer tool — if they know it exists and can access it easily.

Step 4: Train, don't just prohibit. Employees who understand why they cannot paste customer data into ChatGPT (it may be used to train the model, it crosses the data perimeter, it may violate GDPR) make better decisions than employees who are told "the rules say no." Training converts the AUP from a compliance checkbox into genuine behavior change.

Step 5: Measure the gap. Use Shadow AI detection (Section 10.4) to continuously measure the gap between authorized and unauthorized AI use. Treat a widening gap as a signal that the approved tools are not meeting the productivity need — not just as a compliance failure.

10.9 Policy-as-Code for AI¶

Organizational policy expressed in documents requires humans to read, interpret, and apply it. Policy-as-code expresses governance rules as executable constraints that are enforced automatically.

For AI systems, policy-as-code means the architectural controls — not the written policy — are the enforcement mechanism. The written policy explains the intent; the code enforces it.

Examples¶

DLP as code:

name="__codelineno-7-1" href="#__codelineno-7-1"># DLP policy enforced at the AI gateway level class="c1"># Not a document employees read — a control that runs on every request class="k">def evaluate_request(request: AIRequest) -> PolicyDecision: # Check data classification of content pii_detected = presidio_analyzer.analyze(request.prompt) if pii_detected and request.destination not in APPROVED_FOR_PII: return PolicyDecision.BLOCK( reason="PII detected in prompt sent to unapproved service", log_incident=True, notify_user=True ) sensitivity_label = get_content_sensitivity(request.attached_files) if sensitivity_label >= CONFIDENTIAL and not request.is_enterprise_tool: return PolicyDecision.BLOCK( reason="CONFIDENTIAL content cannot be sent to consumer AI tools" ) # Check tool authorization if request.destination not in approved_tools_registry: return PolicyDecision.BLOCK( reason=f"{request.destination} is not in the approved AI tools registry" ) return PolicyDecision.ALLOW(log_for_audit=True)

Model access policy as code (OPA):

# OPA policy: which users can access which AI models

package ai.access

default allow = false

# Allow access to approved models
allow {
    user_has_role(input.user, "ai_user")
    input.model in approved_models
}

# Allow access to high-capability models for approved teams only
allow {
    user_has_role(input.user, "ai_power_user")
    input.model in high_capability_models
}

# Never allow access to unapproved models
deny {
    not input.model in all_approved_models
}

# Use gateway aliases, not raw vendor model IDs, so a model swap is a
# registry change rather than a policy rewrite (Module 37)
approved_models = {"general-chat-tier", "efficient-tier", "internal-llm-v2"}
high_capability_models = {"frontier-reasoning-tier"}
all_approved_models = approved_models | high_capability_models

Agent authorization policy:

# Agent tool access policy: which agents can call which tools

package agent.tools

default allow_tool = false

# Allow if the agent has this tool in its approved manifest
allow_tool {
    agent := data.agents[input.agent_id]
    input.tool in agent.approved_tools
    is_correct_phase(agent, input.tool, input.current_phase)
}

# Irreversible tools require human approval
deny_tool {
    input.tool in irreversible_tools
    not human_approval_granted(input.task_id)
}

irreversible_tools = {"send_email", "execute_transaction", "delete_record", "publish_content"}

The Value of Policy-as-Code¶

Consistency: The policy is applied the same way every time. Human interpretation of written policy varies.

Auditability: Every policy evaluation is logged. You can answer "was this request compliant?" with certainty.

Testability: Policies can be unit-tested. A policy change is tested against a suite of scenarios before deployment.

Version control: Policies are versioned like code. You can see exactly what the policy was on any given date.

Enforcement without awareness: Employees don't need to remember or understand the policy for it to be enforced. The code enforces it regardless.

10.10 Governing an Agent Fleet: Registry, Lifecycle, and Ownership¶

Sections 10.1–10.9 govern people using AI tools. A growing share of AI activity is now agents acting on their own: reading mailboxes, calling APIs, writing to systems of record, and calling other agents. The governance unit changes from "an employee and a tool" to "an autonomous actor with credentials." That actor has no manager, never resigns, and keeps running after everyone has forgotten it.

The platforms have reorganized around this. Google launched Gemini Enterprise Agent Platform (the successor to Vertex AI) on April 22, 2026, framed around four verbs: build, scale, govern, optimize. Its governance layer is Agent Identity, Agent Registry, and Agent Gateway, so that "every agent … has a trackable identity." Microsoft gives each agent a first-class directory identity through Microsoft Entra Agent ID. Microsoft Agent 365, generally available May 1, 2026, is positioned as the control plane to "take control of agent sprawl." At GA, Microsoft also previewed registry sync that discovers and inventories agents running on AWS Bedrock and Google Cloud. The vendor details will keep changing (Appendix G). The pattern will not: every agent gets a registry entry, an identity, an owner, and a lifecycle.

Why Fleet Scale Changes the Problem¶

ONE AGENT vs. A FLEET

Concern            │ 5 agents (pilot)          │ 500+ agents (fleet)
───────────────────┼───────────────────────────┼──────────────────────────────
Knowing they exist │ Everyone knows them       │ Nobody knows the full list
Ownership          │ The team that built it    │ Builders move teams or leave
Credentials        │ Reviewed by hand          │ Thousands of tokens and grants;
                   │                           │ nobody reviews them by hand
Tool access        │ Hand-picked               │ MCP servers added ad hoc;
                   │                           │ permissions only grow
Cost               │ Visible in one bill       │ Diffuse; a runaway loop hides
                   │                           │ in the aggregate
Model changes      │ Tested once               │ One deprecation hits 80 agents
                   │                           │ at once (Module 37)
Incident response  │ "Turn it off"             │ "Which of the 500 did this,
                   │                           │ and who can turn it off?"

The Agent Registry¶

The registry is the AI inventory (Section 10.4) extended for autonomous actors. If an agent is not in the registry, it does not get an identity, credentials, or gateway access. This is the single most important control in this section.

AGENT REGISTRY ENTRY (template)

agent_id:            agt-fin-invoice-recon-007
name:                Invoice Reconciliation Agent
purpose:             Match supplier invoices to POs; flag mismatches > 2%
business_owner:      J. Rivera, AP Operations Manager (named person)
technical_owner:     Finance Automation squad, on-call alias + named lead
build_origin:        pro-code (Agent Framework) | low-code (Copilot Studio) |
                     vendor SaaS agent | third-party via A2A
risk_tier:           TIER_2 (writes to ERP; no external communication)
autonomy_level:      L2 — acts within limits; human approves exceptions
identity:            Dedicated agent identity (e.g., Entra Agent ID);
                     NO shared service accounts, NO human credentials
model(s):            primary: <gateway alias>; fallback: <gateway alias>
                     (aliases, not raw vendor IDs — Module 37)
tools / MCP servers: erp-read, erp-write-flag-only, vendor-master-read
                     (each with a scoped grant and an expiry date)
data_access:         CONFIDENTIAL (financial); no PII beyond vendor contacts
approval_gates:      any ERP write > $10,000; any vendor-master change
cost_budget:         $1,200/month; alert at 80%; hard stop at 150%
eval_status:         eval suite v3 passed 2026-09-12; pass rate 96.4%
portability:         scorecard current (Module 37 §37.9); fallback tested
last_review:         2026-09-15     next_recertification: 2026-12-15
status:              proposed | approved | active | suspended | retired

Every field answers a question someone will ask during an incident or an audit. Leave out owner and nobody can turn the agent off. Leave out tools, and nobody can say what it could have touched. Leave out model(s), and a provider deprecation becomes a hunt through codebases.

Autonomy Levels¶

AGENT AUTONOMY LEVELS

L0 — SUGGEST:   Drafts output; a human performs every action.
L1 — ASSIST:    Performs reversible actions; a human approves each
                irreversible one (Module 6 §6.4 approval touchpoint).
L2 — BOUNDED:   Acts alone within explicit limits (amount, scope,
                recipients); exceptions escalate to a human.
L3 — AUTONOMOUS: Acts alone across a workflow; humans review samples
                and metrics after the fact.

Rule: the autonomy level is a registry field enforced by policy-as-code
(Section 10.9), not a description in a design document. Raising an
agent's level is a change that needs re-approval. An L3 agent with
irreversible tools needs Tier 1 review.

The Agent Lifecycle¶

AGENT LIFECYCLE

PROPOSE ──► REVIEW ──► DEPLOY ──► MONITOR ──► RECERTIFY ──► RETIRE
   │           │          │          │            │            │
Registry    Security,   Identity   Cost, eval   Owner        Revoke
entry       data, risk  issued;    scores,      confirms     identity,
drafted:    tier and    scoped     escalation   purpose,     tokens,
purpose,    autonomy    grants     rate, tool   access,      MCP/tool
owner,      level       with       calls vs.    autonomy     grants;
tools,      approved;   expiry;    manifest     still        archive
data        eval        gateway    (Module 6    needed;      logs per
            passed      route      §6.6)        eval re-run  retention
                        created                    │
                                                   └─ Missed? → auto-
                                                      suspend after a
                                                      grace period

Recertification cadence by tier:
  Tier 1: quarterly     Tier 2: semi-annually     Tier 3: annually
  Also triggered by: model change, new tool, autonomy increase,
  owner change, security incident

Use the identity platform's expiry features so that inaction removes access instead of keeping it. Microsoft Entra, for example, can attach access packages with expiry dates to agent identities. As expiry approaches it notifies the agent's human sponsor, and if the sponsor does nothing, access lapses on the end date.

Shadow Agents¶

Shadow AI (Sections 10.1–10.4) now has an agent form. Low-code builders such as Microsoft Copilot Studio let any employee build an agent that connects to mailboxes, SharePoint, and business systems. Developers run local coding agents with broad file and shell access. Microsoft's own GA announcement for Agent 365 says many local and cloud-hosted agents "run unmanaged and outside of traditional governance," creating "a new wave of shadow AI."

Apply the enable-and-govern approach from Section 10.8, not a blanket ban: - Make registration the easy path. Low-code environments should register agents and issue identities automatically when an agent is published. Agents should not depend on the builder's own credentials. - Default citizen-built agents to L0–L1 autonomy and CONFIDENTIAL-or-lower data until reviewed. - Detect the rest: OAuth and app-grant audits for agent-like consumers, endpoint inventory for local agent runtimes, gateway logs for unregistered callers (Section 10.4 detection stack).

Sprawl Metrics¶

AGENT FLEET HEALTH METRICS (review quarterly; Tier 1 agents monthly)

Coverage:     % of discovered agents present in the registry     target 100%
Orphans:      agents whose owner has left or changed role         target 0
Idle:         agents with no invocations in 60 days               retire or justify
Overdue:      agents past recertification date                    target 0
Privilege:    agents with grants unused for 90 days               revoke
Shared IDs:   agents running on shared/human credentials          target 0
Autonomy mix: count by L0–L3, trend over time                     watch L3 growth
Cost:         spend per agent vs. budget; top 10 by spend         investigate outliers
Duplication:  agents with overlapping purpose in the same team    consolidate

Orphaned Agents¶

An orphaned agent is one whose accountable human is gone. This happens to every fleet, because people change roles and leave and agents do neither. An orphaned agent keeps its credentials, keeps running, and has nobody to answer for it.

Controls: - Hook the HR leaver and mover process into the registry. When an owner leaves or changes role, each of their agents is reassigned to a named person within 5 business days, or it is suspended. - Use the identity platform's sponsorship rules. Microsoft Entra transfers an agent identity's sponsorship to the departing sponsor's manager automatically, so a human is always accountable. Treat that as a safety net, not as the reassignment itself. The manager inherits accountability without the context. - Never let an agent run on a person's credentials. When that person leaves, the agent either breaks at an unpredictable moment or keeps working through an account that should have been disabled.

Decommissioning and Credential Revocation¶

Retiring an agent means removing its ability to act, not just deleting its code.

AGENT RETIREMENT RUNBOOK

  □ Set registry status → suspended; gateway route disabled
  □ Disable the agent identity; revoke OAuth tokens and refresh tokens
  □ Remove MCP server and tool grants; rotate any secrets it could read
  □ Remove A2A trust relationships and webhook/schedule triggers
  □ Cancel delegated permissions granted by users ("on behalf of")
  □ Hand off or close in-flight work (open tickets, pending approvals)
  □ Archive prompts, configs, eval results, logs per retention policy
  □ Verify: no calls from the agent identity for 7 days → status retired
  Target: identity disabled and credentials revoked within 24 hours

How agent identities authenticate and how credentials are scoped is covered in Module 9. Runtime failure modes such as tool authorization creep are in Module 6 §6.5. Model-dependency tracking for the fleet is in Module 37: the model(s) and portability registry fields are what let you answer "which agents break if this model is deprecated?" in minutes.

10.11 The AI Governance Framework Architecture¶

AI governance is not a single policy. It is a multi-layer system of controls, processes, and feedback loops.

AI GOVERNANCE FRAMEWORK

┌────────────────────────────────────────────────────────────────────┐
│                    STRATEGY LAYER                                    │
│  ├── AI governance charter: executive commitment and accountability  │
│  ├── AI principles: values guiding AI use (transparency, fairness,  │
│  │     accountability, human oversight)                             │
│  └── Risk appetite: what levels of AI risk are acceptable and to    │
│        whom is decision authority delegated                         │
└────────────────────────────────────────────────────────────────────┘
                              │
┌────────────────────────────▼───────────────────────────────────────┐
│                    POLICY LAYER                                      │
│  ├── AI Acceptable Use Policy (Section 10.6)                        │
│  ├── AI Data Classification Policy (what data can go to which AI)   │
│  ├── AI Development Standards (Module 9.7: AI Security in SDLC)    │
│  ├── AI Vendor Assessment Requirements (Section 10.7)               │
│  └── AI Incident Response Policy                                    │
└────────────────────────────────────────────────────────────────────┘
                              │
┌────────────────────────────▼───────────────────────────────────────┐
│                    CONTROL LAYER                                     │
│  ├── AI Tool Catalog (approved tools registry)                      │
│  ├── DLP controls on AI service endpoints                           │
│  ├── Policy-as-code enforcement (OPA, gateway policies)            │
│  ├── AI Inventory (all AI systems documented)                       │
│  ├── Agent registry and lifecycle (Section 10.10)                   │
│  ├── Agent authorization framework (Modules 6, 7)                  │
│  └── Prompt governance (Module 3)                                   │
└────────────────────────────────────────────────────────────────────┘
                              │
┌────────────────────────────▼───────────────────────────────────────┐
│                    MONITORING LAYER                                  │
│  ├── Shadow AI detection (Section 10.4)                             │
│  ├── AI audit logs (all AI interactions logged)                     │
│  ├── Security monitoring (injection attempts, anomalous usage)      │
│  ├── Cost monitoring (spend attribution by team/feature)            │
│  └── Quality monitoring (eval scores, human escalation rate)        │
└────────────────────────────────────────────────────────────────────┘
                              │
┌────────────────────────────▼───────────────────────────────────────┐
│                    REVIEW AND IMPROVEMENT LAYER                     │
│  ├── Quarterly AI governance review                                 │
│  │     - AI inventory current?                                      │
│  │     - Shadow AI detection metrics reviewed?                      │
│  │     - Policy gaps identified from incidents?                     │
│  │     - New tools reviewed and cataloged?                          │
│  ├── AI security red team (Module 9.6)                              │
│  ├── Incident post-mortems (what governance failed and why?)        │
│  └── Regulatory alignment check (EU AI Act, NIST AI RMF)           │
└────────────────────────────────────────────────────────────────────┘

The Governance Team¶

AI governance requires cross-functional ownership. No single team can own it effectively:

AI Platform Team: Technical implementation of approved tools, policy-as-code, LLM gateway, evaluation infrastructure

IT Security: Shadow AI detection, DLP enforcement, tool assessment, red teaming

Legal/Privacy: Data processing agreement review, regulatory compliance (EU AI Act, GDPR, HIPAA), AUP drafting

Compliance/Risk: AI inventory, model risk framework (in US banking, the April 2026 interagency guidance, SR 26-2, which replaced SR 11-7; see Module 11), audit trail requirements

HR/Communications: AUP training and communication, change management for AI adoption

Business Representatives (per department): Tool nomination, use case validation, shadow AI reporting

Executive Sponsor: The AI governance program needs executive visibility and backing. AI governance failures (Samsung-style data leakage events) become executive incidents. Prevention requires executive-level commitment.

10.12 The AI Governance Maturity Model¶

Organizations are at different stages of AI governance maturity. Understanding where you are helps prioritize where to go next.

AI GOVERNANCE MATURITY LEVELS

LEVEL 1: AWARE (most organizations today)
  ├── Shadow AI is happening but not measured
  ├── No formal AI governance policy
  ├── Some employees know not to paste sensitive data; many don't
  ├── AI tools reviewed ad-hoc; no formal catalog
  └── No AI inventory; no compliance posture

  Priority: AUP, shadow AI detection, tool catalog

LEVEL 2: CONTROLLED
  ├── AUP in place; basic training conducted
  ├── Shadow AI detection active (network layer at minimum)
  ├── Approved tool catalog published and maintained
  ├── DLP on known AI service endpoints
  ├── AI inventory started (IT-known tools documented)
  └── Basic audit logging for enterprise AI tools

  Priority: Policy-as-code, inventory completeness, agent registry

LEVEL 3: MANAGED
  ├── Policy-as-code enforced at the gateway
  ├── Complete AI inventory (including shadow AI findings)
  ├── Formal tool review process with defined SLA
  ├── Agent authorization framework active
  ├── Agent registry complete; every agent has a named owner
  ├── Prompt governance for production systems (Module 3)
  ├── AI security integrated into SDLC (Module 9.7)
  └── Regular red team exercises

  Priority: Eval infrastructure, model risk framework, EU AI Act compliance

LEVEL 4: OPTIMIZED
  ├── Shadow AI gap measured and trending toward zero
  ├── Approved tools are better than shadow alternatives
  ├── AI governance is a competitive advantage (trust, compliance)
  ├── Continuous monitoring with automated remediation
  ├── Agent lifecycle automated: recertification, expiry, revocation
  ├── EU AI Act compliant for all high-risk systems
  ├── Model risk framework active for regulated AI decisions
  └── AI governance as input to AI strategy (not just risk management)

10.13 The AI Governance Checklist¶

Shadow AI detection - [ ] Network monitoring for AI service traffic active? - [ ] Browser extension audit on managed endpoints monthly? - [ ] OAuth grants to AI services audited quarterly? - [ ] DLP configured for known AI service endpoints? - [ ] Secret scanning active on all code repositories?

Policy and catalog - [ ] AI Acceptable Use Policy published and communicated? - [ ] AI tool catalog published and current? - [ ] Tool review process exists with < 10 business day SLA? - [ ] Data classification matrix per tool defined?

Governance structure - [ ] AI inventory exists? (all AI systems documented) - [ ] AI governance team with cross-functional membership? - [ ] Executive sponsor for AI governance? - [ ] Quarterly governance review scheduled?

Technical enforcement - [ ] Policy-as-code for data classification enforcement? - [ ] LLM gateway with audit logging active? - [ ] Agent authorization framework active? - [ ] Prompt governance for production AI systems?

Agent fleet governance - [ ] Agent registry exists and covers every production agent, including citizen-built agents? - [ ] Every agent has a named, current human owner (not a team alias)? - [ ] Every agent has its own identity, not a shared service account or a person's credentials? (Module 9) - [ ] Autonomy level assigned and enforced by approval gates for irreversible actions? - [ ] Per-agent cost budget with alerting at the gateway? - [ ] Recertification cadence set by tier, with automatic suspension when missed? - [ ] Leaver process re-assigns or suspends agents owned by departing employees? - [ ] Retirement runbook revokes credentials, tokens, and MCP/tool grants within 24 hours? - [ ] Sprawl metrics (unregistered, orphaned, idle agents) reviewed quarterly?

Regulatory - [ ] EU AI Act risk tier assessed for all AI systems? - [ ] NIST AI RMF profile mapped? - [ ] AI inventory adequate for compliance documentation?

EXERCISE — Shadow AI Audit: Run a shadow AI audit for a team of 20–50 people in your organization. Use three detection methods: (1) survey — ask employees what AI tools they use for work; (2) OAuth audit — enumerate AI app grants in your identity provider; (3) network log analysis — check for traffic to AI service domains. Compare the three lists. The gap between what employees report using and what the other methods find is your shadow AI inventory gap. Quantify it. For each tool found that is not in the approved catalog: assess the data classification risk and prioritize remediation.

PONDER — The Samsung Test: Take the most sensitive piece of data in your organization. Now ask: what is the technical barrier that prevents a well-intentioned employee from pasting this into ChatGPT while trying to do their job effectively? If the answer is "the AUP says not to" — you have a policy control, not a technical control. What is the cost of converting the policy control to a technical control?

WORKSHOP — AI Acceptable Use Policy Design: Write a complete AI Acceptable Use Policy for your organization (or a hypothetical one). Cover: the approved tool matrix with data classification tiers, the human oversight requirements, the verification responsibility, the reporting mechanism, and the consequences for violation. Then identify the three governance controls that would technically enforce the most critical provisions of the policy you wrote.

WORKSHOP — AI Governance Gap Assessment: Using the maturity model from Section 10.12, assess your organization's current AI governance maturity level. For each gap between current and Level 3 (Managed): estimate the effort, assign an owner, and propose a timeline. Prioritize the gaps by risk × effort — which high-risk gaps can be closed with low effort first?

Next: Module 11 — Compliance & Model Risk in Regulated Industries