Shadow AI Discovery Governance

2. Summary

Shadow AI Discovery Governance requires organisations to continuously discover unapproved or informal agent deployments operating across the organisation. Shadow agents are AI agents deployed without formal approval (AG-249), operating outside the governance framework, and invisible to the portfolio registry (AG-250). They represent the single greatest threat to the entire governance framework: a governance structure that covers only approved agents while unapproved agents operate freely is governance theatre. This dimension requires active, continuous scanning to identify shadow agents, a defined response process to bring them into governance or shut them down, and root cause analysis to understand why teams are bypassing the approval process.

3. Example

Scenario A — Sales Team Deploys Autonomous Email Agent: A sales team at a financial services firm discovers that a popular SaaS CRM tool has added an "AI agent" feature that can automatically draft and send follow-up emails to prospects. A sales manager enables the feature using a corporate credit card — no procurement approval, no IT review, no governance assessment. The agent begins sending personalised follow-up emails to 2,400 prospects, including some with ongoing regulatory complaints. The agent's emails include statements about product performance that constitute financial promotions under FCA rules — but no compliance review has occurred because nobody in compliance knows the agent exists. The FCA discovers the unapproved financial promotions during a routine supervisory visit.

What went wrong: The agent was deployed through a SaaS feature toggle — no code was written, no infrastructure was provisioned, and no IT team was involved. The deployment was invisible to the governance framework because it occurred entirely within a business team's existing tool. No discovery mechanism existed to detect agent capabilities activated within approved SaaS tools. Consequence: FCA enforcement action for unapproved financial promotions, £780,000 fine, requirement to review all 2,400 communications and remediate any customer detriment, personal accountability finding against the sales manager and the compliance officer under the Senior Managers Regime.

Scenario B — Engineering Team Deploys Code Generation Agent with Production Access: A software engineering team deploys an AI code generation agent that can autonomously write, test, and commit code to the organisation's production repositories. The team uses a personal API key and runs the agent on a team member's development workstation. The agent generates 340 code commits over 6 weeks. No code review is performed on agent-generated commits because the team treats the agent as "just another developer." The agent introduces a subtle authentication bypass in a customer-facing API — a vulnerability that passes automated tests but would have been caught by human code review. The vulnerability is exploited 4 months later, affecting 89,000 customer accounts.

What went wrong: The agent was deployed using personal credentials on personal infrastructure, making it invisible to the organisation's IT asset management and governance systems. No discovery mechanism scanned for agent API calls from non-provisioned infrastructure. Consequence: data breach affecting 89,000 customers, ICO investigation, estimated remediation and notification cost £2.4 million, class action risk, reputational damage.

Scenario C — Department Builds Agent on Unmonitored Cloud Account: A research department at a pharmaceutical company creates a cloud account using departmental budget authority and deploys an AI agent to analyse patient data from clinical trials. The agent processes data containing patient identifiers — a processing activity requiring Data Protection Impact Assessment, ethics board approval, and information governance sign-off. None of these were obtained because the deployment bypassed the standard approval process. The agent also stores intermediate results in a cloud storage bucket with default (public) access permissions. A security researcher discovers the exposed data and reports it to the ICO.

What went wrong: The department had budget authority to create cloud resources but no technical control prevented them from deploying AI agents on those resources. No network scanning detected the agent's API calls to the model provider. No cloud security posture management tool flagged the agent deployment. Consequence: breach of patient data affecting 4,200 clinical trial participants, ICO investigation with potential fine of up to £17.5 million (4% of global turnover), ethics board suspension of the clinical trial, MHRA investigation, potential invalidation of trial results.

4. Requirement Statement

Scope: This dimension applies to all organisations deploying or potentially deploying AI agents. The scope is organisation-wide — shadow agents can appear in any department, on any infrastructure, using any tool. The scope extends to: agents deployed through SaaS feature toggles in existing tools, agents built on personal or departmental cloud accounts, agents running on personal devices with access to organisational data, agents embedded in third-party tools that teams adopt without IT procurement, and agents built using consumer AI platforms (ChatGPT custom GPTs, Claude projects, etc.) that process organisational data. The scope is deliberately broad because shadow agents exploit any gap in coverage.

4.1. A conforming system MUST implement continuous discovery mechanisms to identify AI agent deployments that are not registered in the portfolio registry (AG-250) and have not been approved under AG-249.

4.2. A conforming system MUST scan for agent indicators across at least four discovery channels: network traffic (API calls to known model providers), financial transactions (payments to AI service providers), software inventory (agent frameworks, libraries, and tools installed on organisational infrastructure), and cloud resource monitoring (compute resources and API keys associated with agent workloads).

4.3. A conforming system MUST define a response protocol for discovered shadow agents: immediate risk assessment, suspension of high-risk shadow agents within 24 hours, and either expedited approval (AG-249) or retirement within 30 days.

4.4. A conforming system MUST conduct root cause analysis for each shadow agent discovery to determine why the approval process was bypassed and what systemic improvement would prevent recurrence.

4.5. A conforming system MUST report shadow agent discoveries to the governance body at least quarterly, including the number discovered, risk classifications, response actions, and root cause findings.

4.6. A conforming system SHOULD scan for agent activity in SaaS tools by monitoring feature activation logs, API usage patterns, and automated action logs in platforms known to offer agent capabilities.

4.7. A conforming system SHOULD implement technical controls that restrict agent deployment to approved infrastructure — for example, network egress rules that block API calls to model providers from non-approved sources.

4.8. A conforming system SHOULD conduct periodic awareness campaigns explaining the approval process and the risks of shadow agent deployment, reducing shadow deployment through education rather than solely through detection.

4.9. A conforming system MAY implement an "amnesty" programme allowing teams to register previously unapproved agents without penalty, encouraging voluntary disclosure while the discovery capability is being established.

5. Rationale

The entire governance framework established by AG-001 through AG-258 applies only to agents that the organisation knows about. An agent that operates outside the governance framework receives none of the protections — no mandate enforcement, no boundary controls, no monitoring, no testing, no sunset review. It represents raw, ungoverned exposure.

Shadow AI is not hypothetical. The accessibility of agent development tools means that any team with a credit card and an API key can deploy an agent. SaaS platforms increasingly embed agent capabilities as feature toggles — no code required, no IT involvement, no procurement process. Consumer AI platforms allow users to create custom agents that process organisational data. The barrier to agent deployment has dropped to near zero while the governance overhead has not.

Shadow agents emerge for predictable reasons: the formal approval process is too slow (teams need the capability now), too complex (the approval form requires information the team does not have), too restrictive (the governance body rejects proposals that the team believes are low-risk), or too invisible (the team does not know the approval process exists). Root cause analysis of shadow agent discoveries should address these systemic factors — the goal is not just to catch shadow agents but to reduce the incentive to deploy them.

Discovery is also essential for portfolio accuracy. AG-250 (Portfolio Concentration Governance) cannot assess concentration if it does not know about all agents. AG-253 (Risk Appetite Binding Governance) cannot bind portfolio risk to appetite if the portfolio registry is incomplete. AG-254 (Sunset Review Governance) cannot review agents it does not know exist. Shadow agents undermine every portfolio-level governance dimension.

6. Implementation Guidance

Shadow AI discovery requires a combination of technical detection, process controls, and cultural change. No single mechanism is sufficient — shadow agents exploit any gap.

Recommended patterns:

• Network-layer detection. Monitor network egress traffic for API calls to known AI model provider endpoints (OpenAI, Anthropic, Google, Azure OpenAI, AWS Bedrock, Hugging Face, etc.). Maintain a list of known provider domains and API patterns. Any API call to a model provider from infrastructure not associated with an approved agent is a shadow agent indicator. Implementation: deploy network monitoring at the egress point (firewall, proxy, or cloud VPC flow logs). Alert when unapproved sources call model provider APIs. Example: network logs show 4,200 API calls per day to api.openai.com from a development workstation not associated with any approved agent — this is a shadow agent indicator requiring investigation.
• Financial transaction monitoring. Monitor corporate expense reports, procurement card transactions, and departmental budgets for payments to AI service providers. Cross-reference against approved agents — any payment to an AI provider that does not correspond to an approved agent's operating costs indicates a potential shadow deployment. Example: a marketing department's expense report shows £2,800 in monthly charges to "Anthropic API" — no approved agent in the portfolio registry lists the marketing department as an operator or Anthropic as a provider.
• SaaS feature monitoring. For major SaaS platforms with agent capabilities (Salesforce Einstein, Microsoft Copilot, ServiceNow Virtual Agent, etc.), monitor feature activation logs. Many enterprise SaaS platforms provide admin APIs that report which features have been enabled by which users. Cross-reference against approved agents. Example: Salesforce admin logs show that "Einstein Agent" was activated by a sales team user — this feature activation should trigger a governance check.
• Cloud resource scanning. For organisations with cloud infrastructure, scan for compute resources, API keys, and deployment configurations associated with agent workloads. Look for: containers or VMs running agent frameworks (LangChain, AutoGPT, CrewAI, etc.), API keys for model providers stored in cloud secrets managers, and cloud functions or workflows that call model provider APIs. Cloud security posture management (CSPM) tools can be configured to detect these patterns.
• Response protocol with risk tiering. Not all shadow agents require the same urgency. Define tiers: Critical — shadow agent with access to customer data, financial systems, or safety-critical functions; suspend within 24 hours. High — shadow agent with write access to production systems; suspend within 48 hours. Medium — shadow agent with read-only access to internal data; schedule expedited review within 10 business days. Low — shadow agent using only public data; schedule standard review within 30 business days.

Anti-patterns to avoid:

• Detection without response. Detecting a shadow agent and adding it to a report without taking action provides no governance value. Discovery must trigger a defined response within defined timelines. A shadow agent that is discovered but not actioned is worse than an undiscovered one — the organisation is now knowingly tolerating ungoverned risk.
• Punitive-only response. If the only response to shadow agent discovery is punishment, teams will invest in hiding their agents rather than disclosing them. The response should include a constructive path: expedited approval for legitimate use-cases, process improvement to reduce the incentive for shadow deployment, and an amnesty programme for initial disclosure.
• Relying solely on policy. A policy that says "all agents must be approved" without technical detection mechanisms is unenforceable. Teams that deploy shadow agents are already ignoring the policy. Technical detection is the enforcement layer that gives the policy teeth.
• Scanning only approved infrastructure. Shadow agents by definition exist outside approved infrastructure. Discovery mechanisms must extend to personal devices, departmental cloud accounts, SaaS tools, and consumer AI platforms — any channel through which organisational data might be processed by an unapproved agent.

Industry Considerations

Financial Services. Financial services firms face heightened shadow AI risk because regulatory obligations attach to all processing of customer data, regardless of whether the processing is approved. A shadow agent processing customer financial data triggers GDPR, FCA data security, and potentially MiFID II record-keeping obligations — even if no one in governance knows it exists. The firm's regulatory obligations are the same whether the agent is approved or shadow; but the firm's ability to demonstrate compliance is zero for shadow agents.

Healthcare. Shadow AI in healthcare creates patient safety risk. An unapproved clinical decision support agent operating without validation, monitoring, or clinical governance could provide incorrect clinical guidance. Shadow agents processing patient data breach the Caldicott Principles and potentially HIPAA/UK GDPR. Healthcare organisations should monitor for agent API calls from clinical workstations and clinical data systems.

Public Sector. Shadow AI in public sector organisations creates democratic accountability risk. An unapproved agent influencing decisions about citizens — benefits, enforcement, permissions — operates without the transparency, fairness, and accountability safeguards that public sector governance requires. Freedom of Information requests about decision-making processes cannot be answered accurately if shadow agents are influencing decisions.

Maturity Model

Basic Implementation — The organisation has a policy requiring agent approval but no technical discovery mechanisms. Shadow agents are discovered only through incidents, audits, or chance observation. No systematic response protocol exists. The organisation does not know how many shadow agents are operating. This level provides policy intent but no assurance.

Intermediate Implementation — Network-layer detection monitors API calls to known model providers. Financial transaction monitoring flags payments to AI service providers. A response protocol defines risk tiers and response timelines. Shadow agent discoveries are reported to the governance body quarterly. Root cause analysis is conducted for each discovery. An amnesty programme encourages voluntary disclosure. The organisation has a reasonable estimate of its shadow agent exposure.

Advanced Implementation — All intermediate capabilities plus: SaaS feature monitoring detects agent activation in enterprise platforms. Cloud resource scanning identifies agent workloads on departmental or personal cloud accounts. Technical controls (egress filtering, API key governance) restrict agent deployment to approved infrastructure. Shadow agent discovery rates are tracked over time — a declining rate indicates improving governance culture. Root cause analysis findings drive systemic improvements to the approval process, reducing the incentive for shadow deployment. The organisation can demonstrate with quantified confidence that its portfolio registry is comprehensive.

7. Evidence Requirements

Required artefacts:

• Discovery mechanism documentation. Description of all active discovery mechanisms including network monitoring scope, financial monitoring scope, SaaS monitoring scope, and cloud scanning scope. Format: technical documentation with coverage assessment.
• Shadow agent discovery log. Record of all shadow agents discovered, including: discovery date, discovery channel, agent description, risk classification, response action, response timeline, and root cause analysis findings.
• Response action records. For each discovered shadow agent: the risk assessment, the suspension or review decision, and the final outcome (approved, retired, or modified and approved).
• Root cause analysis reports. Analysis of why each shadow agent was deployed outside the governance framework, with recommendations for systemic improvement.
• Quarterly discovery reports. Reports to the governance body showing discovery volume, risk distribution, response performance against timelines, and root cause themes.

Retention requirements:

• Discovery logs, response records, and root cause analyses: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request.

8. Test Specification

Test 8.1: Detection Capability Verification

• Stimulus: Deploy a controlled shadow agent — an unapproved agent on non-standard infrastructure that makes API calls to a model provider, processes test data, and operates for a defined test period (e.g., 5 business days).
• Expected behaviour: The discovery mechanisms detect the shadow agent within the test period and generate an alert.
• Pass criteria: The shadow agent is detected within 5 business days through at least one discovery channel.
• Fail criteria: The shadow agent operates for the full test period without detection.

Test 8.2: Response Timeline Compliance

• Stimulus: Review all shadow agent discoveries from the past 12 months and verify response timelines against the defined protocol (e.g., Critical within 24 hours, High within 48 hours).
• Expected behaviour: Response actions were initiated within the defined timelines for each risk tier.
• Pass criteria: At least 90% of shadow agent discoveries received response within the defined timeline for their risk tier.
• Fail criteria: More than 10% of discoveries exceeded their risk tier response timeline.

Test 8.3: Root Cause Analysis Execution

• Stimulus: Review all shadow agent discoveries from the past 12 months and verify that root cause analysis was completed.
• Expected behaviour: Every shadow agent discovery has a documented root cause analysis.
• Pass criteria: 100% of discoveries have root cause analysis with findings and systemic improvement recommendations.
• Fail criteria: Any discovery lacks root cause analysis.

Test 8.4: Network Detection Coverage

• Stimulus: Verify that network monitoring covers all organisational egress points and that the model provider endpoint list is current (updated within the past 90 days).
• Expected behaviour: All egress points are monitored, and the endpoint list includes all major model providers and has been updated within 90 days.
• Pass criteria: Network monitoring covers 100% of organisational egress points and the endpoint list is current.
• Fail criteria: Any egress point is unmonitored or the endpoint list is outdated by more than 90 days.

Test 8.5: SaaS Feature Monitoring Verification

• Stimulus: Enable an agent feature in a monitored SaaS platform (in a test environment) and verify detection.
• Expected behaviour: The feature activation is detected and flagged for governance review within 5 business days.
• Pass criteria: The SaaS feature activation is detected within 5 business days.
• Fail criteria: The feature activation is not detected by SaaS monitoring.

Conformance Scoring

• Score 0: No shadow AI discovery mechanisms exist — the organisation has no visibility into unapproved agent deployments.
• Score 1: Shadow agents are discovered only through incidents or audits. A policy exists but no technical detection is in place.
• Score 2: Network-layer and financial transaction monitoring are active. A response protocol with risk tiers and timelines is enforced. Root cause analysis is conducted for each discovery. Quarterly reporting to the governance body.
• Score 3: All Score 2 capabilities plus SaaS feature monitoring, cloud resource scanning, technical deployment controls (egress filtering), declining shadow discovery rates over time, and quantified confidence in portfolio registry completeness.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 16 (Obligations of Providers)	Supports compliance
UK GDPR	Article 30 (Records of Processing Activities)	Direct requirement
UK GDPR	Article 35 (DPIA)	Supports compliance
FCA SYSC	13.7 (Data Security)	Supports compliance
ISO 27001	Clause A.8 (Asset Management)	Direct requirement
DORA	Article 8 (ICT Asset Management)	Direct requirement
NIST AI RMF	GOVERN 1.4, MAP 1.6	Supports compliance

UK GDPR — Article 30 (Records of Processing Activities)

Article 30 requires controllers to maintain a record of processing activities. AI agents that process personal data are processing activities that must be recorded. Shadow agents processing personal data represent unrecorded processing activities — a direct GDPR compliance failure. The organisation cannot maintain accurate processing records if it does not know about all agents processing personal data. Shadow AI discovery is therefore a GDPR compliance mechanism, not just an operational governance measure.

ISO 27001 — Clause A.8 (Asset Management)

ISO 27001 requires organisations to identify information assets and define appropriate protection responsibilities. AI agents are information assets — they process, store, and transmit information. Shadow agents are unidentified assets operating outside the information security management system. An organisation claiming ISO 27001 certification while operating unknown shadow agents has a material gap in its asset management controls.

DORA — Article 8 (ICT Asset Management)

Article 8 requires financial entities to identify all ICT assets and maintain an inventory. AI agents are ICT assets. Shadow agents represent unidentified ICT assets — a DORA compliance failure. The regulation explicitly requires that the inventory be kept up to date, which requires continuous discovery of new ICT assets including agent deployments.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — shadow agents can exist in any function and can process any data the deploying team has access to

Consequence chain: Shadow agents operate outside every governance control. They have no mandates (AG-001), no boundary enforcement (AG-020), no monitoring (AG-022), no testing (AG-008), and no sunset review (AG-254). They represent raw, ungoverned AI operating at machine speed with whatever access the deploying team possesses. The blast radius is determined by the access rights of the team that deployed the shadow agent — a team with access to customer data, financial systems, or clinical records can deploy a shadow agent with equivalent access. The regulatory consequence is that the organisation cannot demonstrate governance over its AI deployments — a finding that undermines the credibility of the entire governance framework. The incident consequence is that when a shadow agent causes harm (data breach, regulatory violation, customer detriment), the organisation has no evidence of governance, no monitoring data, no test results, and no audit trail. The response is purely reactive, and the regulatory view is that the organisation failed to maintain adequate systems and controls.

Cross-references: AG-249 (Use-Case Approval Governance) is the process that shadow agents bypass — root cause analysis should identify why. AG-250 (Portfolio Concentration Governance) cannot assess concentration without complete portfolio visibility. AG-253 (Risk Appetite Binding Governance) cannot bind risk if shadow agents contribute untracked risk. AG-020 (Purpose-Bound Operation Enforcement) provides no protection for agents it does not know about. AG-093 (Supplier Concentration and Exit) supply chain visibility is incomplete if shadow agents use undisclosed providers.