TL;DR

Shadow AI is not merely unapproved software. An unsanctioned agent, copilot, script, or autonomous workflow can authenticate as a machine identity, call a model provider, read enterprise data, invoke tools, modify systems, and create spend without appearing in a centralized AI inventory.

The practical discovery method is evidence correlation. Start with model-provider traffic, provider usage and audit records, non-human identities, CI/CD and Kubernetes inventory, runtime execution, package installation, secrets access, data access, and billing. No single signal proves that an agent exists. Multiple signals tied to the same workload, identity, time window, and owner create the defensible finding.

This runbook provides a staged process for finding shadow AI, preserving evidence, containing risky workloads without destroying the investigation trail, and turning confirmed findings into an enterprise agent inventory with ongoing ownership and detection.

Introduction

Traditional shadow IT usually creates an unmanaged application, subscription, device, or data store. That is already an operational and security problem, but the unmanaged system often waits for a person to use it.

Shadow AI changes the risk model because the software can act. A developer can add a model API call to a deployment pipeline. A business team can connect a copilot to a ticketing platform. An administrator can schedule a script that reads reports, asks a model to interpret them, and writes the result into another system. A platform engineer can deploy an agent framework into Kubernetes using a service account that already reaches secrets, storage, and internal APIs.

None of those examples requires a formal enterprise AI program. They require a runtime, a credential, network access, and enough authority to complete a task.

That is why an AI policy or approved-tools list is not a discovery control. The organization needs an operational method that answers a harder question: Where are model-assisted and autonomous workloads actually running, which identities do they use, what can they reach, and who owns the risk?

Scenario: The Automation Nobody Owns

The incident starts with an ordinary symptom. A cloud bill contains model-inference charges that no approved project recognizes. A service principal begins reading a document repository at 2:00 a.m. A CI/CD runner installs an AI orchestration package during a job, then makes outbound connections to a model endpoint. A Kubernetes CronJob calls a ticketing API hundreds of times after a small configuration change.

Each event can be explained independently. The bill might belong to a prototype. The identity might support reporting. The package might be a transient build dependency. The API burst might be a retry problem.

The risk appears when the evidence converges:

• The same workload contacts a model provider.
• The same machine identity reads secrets or business data.
• The runtime invokes administrative or write-capable tools.
• The execution repeats without a human initiating every action.
• No service catalog, architecture record, approved repository, cost center, or accountable owner explains the behavior.

At that point, the enterprise is not investigating an unapproved chat session. It is investigating an active software principal with uncertain authority.

Why Shadow AI Is More Dangerous Than Shadow IT

Shadow AI inherits the familiar problems of shadow IT, including unsupported software, unknown data handling, fragmented procurement, inconsistent access control, and missing lifecycle ownership. It adds several capabilities that increase the potential blast radius.

It Can Act Through Existing Authority

An agent does not need a special “AI administrator” role. It can inherit the permissions of a CI/CD runner, Kubernetes service account, automation worker, managed identity, local user, or shared API key. The model may be new, while the authority it exercises is years old.

It Can Turn Read Access Into Decisions and Writes

A workflow that can read documents and send messages may summarize confidential material into an external channel. A workflow that can inspect infrastructure and execute commands may convert a broad troubleshooting request into changes. A workflow with ticketing, finance, procurement, or cloud APIs can produce business actions, not just text.

It Can Create Variable and Distributed Spend

Model calls, vector databases, serverless execution, SaaS connectors, data egress, and downstream tool activity can spread charges across multiple accounts. The model-provider invoice may reveal only part of the cost.

It Can Operate Outside Human Working Patterns

Scheduled jobs, event triggers, queue consumers, webhooks, and autonomous loops continue when the original developer is absent. A prototype left on a worker may become a production dependency without ever passing a production review.

It Can Hide Inside Legitimate Automation

The hardest shadow agents are not named “agent.” They are embedded in scripts, notebooks, pipeline steps, browser automations, workflow platforms, chat integrations, or ordinary services. Discovery based only on framework names will miss custom implementations and overcount harmless dependencies.

Signs That Unauthorized Agents Are Operating

Shadow AI rarely announces itself. Investigators should look for combinations of signals rather than wait for a definitive alert.

Network and Provider Signals

• New outbound connections to model-provider, inference, embedding, vector, or agent-service endpoints from systems that are not registered as AI workloads.
• Repeated API calls from build workers, automation servers, user desktops, jump hosts, or shared application tiers.
• Model usage or spend associated with personal accounts, unknown projects, unmanaged workspaces, or unrecognized API keys.
• Large changes in token consumption, request volume, embedding activity, or tool-related calls without a matching release or business event.
• Provider activity that continues after the supposed prototype or pilot ended.

Identity and Credential Signals

• New service principals, managed identities, workload identities, Kubernetes service accounts, OAuth applications, or long-lived API keys with no registered owner.
• Non-human identities authenticating from new runtimes, regions, clusters, runners, or source addresses.
• Shared service accounts used by several unrelated workloads, making attribution difficult.
• Secrets retrieved by an identity immediately before model-provider or tool traffic.
• Personal credentials or user-scoped tokens used by unattended processes.

Runtime and Automation Signals

• AI SDKs, agent frameworks, model clients, browser automation packages, or tool-integration libraries appearing in a pipeline, container, notebook, function, or scheduled task.
• Runtime package installation on long-lived workers, especially when followed by outbound model traffic.
• New Kubernetes Deployments, Jobs, CronJobs, or pods with model credentials, broad service accounts, or external egress.
• CI/CD jobs that call collaboration, ticketing, source-control, cloud, or infrastructure APIs after invoking a model.
• Retry storms, tool-call fan-out, recursive task creation, or a small trigger producing a disproportionate number of downstream actions.

Data and Business Signals

• Document repositories, databases, object stores, or internal APIs accessed by a machine identity that has no approved AI use case.
• Generated tickets, messages, pull requests, cloud changes, or purchase activity without an accountable human requester.
• Prompt, response, embedding, or trace data appearing in an unapproved logging or observability platform.
• Business teams expensing model subscriptions or automation platforms outside centralized procurement.

A single package name or destination domain is a lead. A useful finding connects execution, identity, provider use, data access, tool use, time, and ownership.

The Evidence Model for Finding Shadow AI

The discovery process should treat shadow AI as a correlation problem across six evidence planes.

The important point is the join. A proxy event without an identity is weak. A service account without runtime context is ambiguous. A provider key without a source workload is hard to contain safely. The investigation becomes reliable when records share stable attributes such as workload identity, namespace, host, runner, project, API key identifier, source address, repository, deployment digest, timestamp, or cost center.

What Each Signal Can and Cannot Prove

The evidence model deliberately avoids a common mistake: declaring every AI library, endpoint connection, or developer experiment to be a production agent. Discovery should be broad. Confirmation should be disciplined.

Prerequisites and Safety Checks

Before running discovery commands or containment actions, establish investigative authority and protect the evidence.

• Define the authorized scope, including accounts, tenants, subscriptions, clusters, repositories, runners, network zones, and provider organizations.
• Select a time window that covers the first observed anomaly and enough history to establish normal behavior.
• Export the current approved AI inventory, service catalog, CMDB records, provider projects, approved gateways, and known egress destinations.
• Confirm log retention for identity, provider, network, Kubernetes audit, CI/CD, secrets, data, endpoint, and cloud control-plane sources.
• Use read-only investigation credentials wherever possible.
• Avoid dumping secret values, complete prompts, model responses, or sensitive documents into an analyst workstation or ticket.
• Record query times, filters, export hashes, and evidence locations so results can be reproduced.
• Coordinate with incident response, legal, privacy, human resources, and business owners when the investigation may involve employee activity or regulated data.
• Do not delete a workload simply because it is unapproved. It may be a business dependency, an incident foothold, or the only remaining source of evidence.

Runbook Stage: Establish Scope and an Approved Baseline

Discovery begins by defining what “known” looks like. Without a baseline, every provider call becomes suspicious and every legitimate experiment creates noise.

Build a baseline that lists:

• approved model providers, cloud AI services, private inference endpoints, and AI gateways;
• approved provider organizations, accounts, projects, workspaces, and billing relationships;
• registered AI applications, copilots, agents, pipelines, notebooks, and automation workflows;
• expected source networks, clusters, runners, hosts, serverless environments, and user groups;
• approved human and machine identities;
• expected data sources, tools, egress destinations, and spending ranges;
• accountable business and technical owners;
• expected schedules, triggers, and change windows.

The baseline does not need to be perfect before discovery starts. It needs enough structure to distinguish registered activity from unexplained activity. Record gaps as gaps. Do not silently classify an unknown workload as approved because it resembles something legitimate.

Runbook Stage: Discover Model-Provider API Traffic

Network telemetry is often the fastest way to identify where to look, especially when the enterprise has no centralized provider account or agent platform.

Search DNS, Proxy, Firewall, and Egress Records

Start with outbound traffic from servers, runners, clusters, desktops, notebooks, browser automation hosts, serverless functions, and SaaS integration points. Build and maintain a reviewed destination set that includes approved providers, observed providers, private endpoints, API gateways, model routers, embedding services, vector platforms, and known AI SaaS integrations.

The following vendor-neutral query pattern groups model-related connections by source identity and workload. Replace the table, fields, time syntax, and domain source with equivalents from the enterprise logging platform.

SELECT
    source_identity,
    source_workload,
    destination_fqdn,
    COUNT(*) AS connections,
    SUM(bytes_out) AS bytes_out,
    MIN(event_time) AS first_seen,
    MAX(event_time) AS last_seen
FROM proxy_events
WHERE event_time >= CURRENT_TIMESTAMP - INTERVAL '30' DAY
  AND destination_fqdn IN (
      SELECT fqdn FROM approved_and_observed_ai_domains
  )
GROUP BY source_identity, source_workload, destination_fqdn
ORDER BY last_seen DESC;

Successful execution produces a source-to-destination list that can be compared with the approved inventory. Prioritize sources with no owner, new first-seen dates, persistent off-hours traffic, large outbound volumes, unusual geography, or repeated connections from privileged environments.

This search is not complete coverage. TLS encryption, private endpoints, shared SaaS domains, content delivery networks, encrypted DNS, proxy bypass, HTTP/3, local models, and provider traffic routed through an enterprise gateway can hide the destination. Join network results with provider, identity, and runtime evidence instead of treating the domain list as a final detector.

Reconcile Provider Organizations, Projects, Keys, and Spend

For every provider available to the enterprise, collect the equivalent of:

• organizations and accounts;
• projects and workspaces;
• users, service accounts, and API keys;
• audit or activity records;
• model usage and cost reports;
• rate limits and spend limits;
• key creation, rotation, and last-used metadata;
• source address or request metadata when available.

Cloud-hosted model services should be reconciled through their cloud audit and billing systems as well as the AI service itself. Direct provider subscriptions should be compared with procurement, expense, and finance records. Personal or departmental accounts are especially important because centralized cloud logging may not see them.

Shared keys are a warning sign. They collapse multiple workloads into one provider identity and make attribution, spend control, rotation, and containment harder. Treat a shared key as an investigation branch, not as an owner.

Runbook Stage: Find Unmanaged Service Accounts and Machine Identities

Shadow agents usually need a non-human identity somewhere in the chain, even when the original experiment began under a developer account.

Inventory the following identity types:

• cloud service principals and application identities;
• managed identities and workload identity federation relationships;
• IAM users, roles, access keys, and assumed-role sessions;
• Kubernetes service accounts and bound role permissions;
• CI/CD runner identities and repository deployment credentials;
• OAuth applications, bots, and integration accounts;
• local service users and scheduled-task accounts;
• provider API keys and service accounts;
• secrets-manager identities and vault authentication roles.

For each identity, capture the owner, purpose, creation time, credential types, last use, source environment, assigned roles, effective permissions, and workloads that reference it. Focus on identities that are recently created, broadly privileged, long-lived, ownerless, used from several runtimes, or active outside the expected schedule.

A machine identity should map to a workload, and that workload should map to an accountable owner. When either link is missing, the identity belongs in the investigation queue.

Check Kubernetes Service-Account Authority

After identifying a suspicious pod or controller, use the service account shown in its specification to review effective access. Replace the namespace and service-account values with the workload under investigation.

kubectl auth can-i 
  --as=system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT 
  --list

Run this only with appropriate authorization. The output identifies Kubernetes API permissions, not cloud permissions, secrets available through external identity federation, application-level permissions, or network reachability. Those require separate checks.

Runbook Stage: Inspect CI/CD Runners, Kubernetes, and Automation Workers

Shadow AI often enters through the places already designed to execute code unattended. These platforms should be treated as primary discovery surfaces, not secondary developer tools.

Inventory Kubernetes Workloads Without Reading Secret Values

The first command captures a point-in-time inventory for later analysis. The second produces a compact view of pod names, service accounts, images, and referenced Kubernetes secrets. It reads metadata references, not secret contents.

kubectl get deployment,statefulset,daemonset,job,cronjob,pod 
  --all-namespaces -o json 
  > kubernetes-workload-inventory.json

kubectl get pods --all-namespaces -o json | jq -r '
  .items[]
  | [
      .metadata.namespace,
      .metadata.name,
      (.spec.serviceAccountName // "default"),
      ([.spec.containers[].image] | join(",")),
      ([.spec.containers[].envFrom[]?.secretRef.name]
        | unique | join(",")),
      ([.spec.volumes[]?.secret.secretName]
        | unique | join(","))
    ]
  | @tsv'

Successful execution produces an inventory that can be joined to audit events, image registries, deployment histories, identity bindings, egress logs, and secrets-access evidence. Investigate default service accounts, unpinned or unfamiliar images, mutable tags, unapproved registries, broad egress, recent CronJobs, and workloads referencing high-value secrets.

Also inspect admission records, controller ownership, Helm releases, GitOps sources, image digests, namespace labels, network policies, and runtime classes. A running pod is only one layer. The deployment source and reconciliation controller determine whether it will return after containment.

Inspect Pipeline Definitions and Repositories

Search pipeline files, scripts, notebooks, and source trees for model clients, agent frameworks, tool protocols, orchestration libraries, and provider names. This command uses ripgrep and should be tuned to the enterprise technology stack.

rg -n -i 
  'openai|anthropic|bedrock|vertex|azure[._-]?openai|langchain|llama[-_]?index|autogen|crewai|semantic[-_]?kernel|mcp|tool[_ -]?call' 
  .github .gitlab-ci.yml Jenkinsfile azure-pipelines.yml 
  src scripts notebooks 2>/dev/null

A match is a discovery lead, not proof of execution. Dependencies may be unused, examples may be documentation, and custom agents may contain none of the expected names. Correlate findings with build logs, package downloads, runner telemetry, provider usage, release records, and runtime activity.

Review pipeline variables and secret references without exposing their values. Identify steps that install packages dynamically, run code from mutable branches, call external APIs, invoke shell commands, or publish artifacts outside approved repositories.

Inspect Long-Lived Automation Workers

On authorized Linux workers, review active containers, services, and scheduled execution:

systemctl list-timers --all
systemctl list-units --type=service --state=running
crontab -l
docker ps --no-trunc
podman ps --no-trunc

On authorized Windows workers, review scheduled tasks and running services:

Get-ScheduledTask |
    Select-Object TaskPath, TaskName, State

Get-CimInstance Win32_Service |
    Where-Object State -eq 'Running' |
    Select-Object Name, StartName, PathName

Expected success is a reproducible execution inventory that can be matched to process telemetry, installed packages, network connections, service accounts, script locations, code-signing status, and configuration-management records. Avoid changing service state during the discovery pass.

Runbook Stage: Detect Tool Calling and Runtime Package Installation

An agent becomes operationally significant when model output can influence a tool, command, API, workflow, or system change. Tool use may appear as native provider calls, orchestration-framework activity, ordinary API requests, shell execution, browser automation, or messages placed onto a queue.

Look for these sequences:

• model request followed by a privileged API call from the same workload;
• inference followed by shell, PowerShell, Python, browser, infrastructure-as-code, or database execution;
• package installation followed by provider traffic and tool access;
• a small inbound event followed by a large fan-out of downstream calls;
• repeated tool failures followed by rapid retries or alternative actions;
• new tickets, pull requests, messages, cloud changes, or records created by a machine identity;
• a model call followed by secrets access that was not required before execution;
• execution that persists through a scheduler, queue, controller, or webhook.

Runtime detections should use process lineage where available. A network connection from a worker is more useful when it can be tied to a process, container, image digest, command line, parent process, code artifact, and service identity.

Dynamic package installation deserves special attention because it changes the worker after the approved image or build artifact was reviewed. Capture package-manager logs, shell history where policy permits, endpoint telemetry, container-layer changes, and package cache records. Do not assume that blocking package installation alone removes the agent. The required libraries may already be baked into an image or vendored into a repository.

Runbook Stage: Map Reachable Credentials and Data Sources

Finding the workload is only half the investigation. The next question is what the workload could do.

Build a reachability map for each candidate:

Review effective access, not only assigned roles. Include group membership, role inheritance, identity federation, pod identity, secret injection, environment variables, mounted volumes, local credential files, metadata services, cached tokens, shared folders, browser profiles, repository secrets, and downstream service-to-service delegation.

The goal is not to extract every secret. It is to document which credential references exist, which principal can retrieve them, which systems accept them, and what operations they permit. Record sensitive values only through approved incident-handling procedures, and rotate them after evidence preservation when exposure is confirmed or cannot be ruled out.

Classify data sources by sensitivity and action by reversibility. Reading a public knowledge base is not equivalent to reading payroll records. Creating a draft ticket is not equivalent to deleting infrastructure. The same agent design can have radically different risk depending on identity and tool reachability.

Runbook Stage: Correlate Evidence and Score Candidate Agents

Create one investigation record per candidate workload. Join records by the strongest available identifiers and preserve uncertainty rather than forcing a premature conclusion.

Confidence is separate from impact. A confirmed agent with read-only access to a public source may be lower priority than a probable agent using a privileged deployment identity. Score blast radius across data sensitivity, write authority, credential reachability, network reach, spend, trigger frequency, human oversight, rollback capability, and business criticality.

A practical prioritization rule is:

Investigation Priority = Evidence Confidence x Maximum Reachable Impact

This is a triage model, not a mathematical risk guarantee. Use a small, consistently defined scale and document why each factor received its rating.

Containment Without Destroying Evidence

Containment should reduce the agent’s ability to cause harm while preserving enough state to determine what happened. Deleting a pod, revoking every credential, or wiping a worker may stop activity, but it can also destroy process state, logs, artifacts, and attribution evidence. It may also trigger a controller that immediately recreates the workload.

Use the least destructive control that achieves the required risk reduction:

Evidence to Preserve Before Major Changes

Capture what is available and authorized:

• provider audit, usage, cost, project, workspace, and key metadata;
• identity sign-ins, token events, role assignments, and effective access;
• DNS, proxy, firewall, flow, and egress records;
• Kubernetes manifests, audit events, controller references, pod status, image digests, and namespace metadata;
• CI/CD pipeline definitions, run logs, variables references, runner identity, artifacts, and release records;
• process trees, command lines, loaded modules, container state, package-manager records, and endpoint telemetry;
• secret-reference metadata and secrets-manager access events;
• data access records and tool API activity;
• source repository commit, branch, tag, dependency lock files, and artifact hashes;
• scheduler, webhook, queue, and event-trigger configuration;
• timestamps, analyst queries, exported evidence hashes, and custody records.

Do not copy full prompts, responses, or source documents unless they are necessary and approved for the investigation. Metadata and hashes often provide enough proof while reducing privacy and data-handling risk.

Select the Containment Control

• Unknown but low-impact workload: Increase telemetry, apply spend and rate limits, and contact the likely owner.
• Confirmed agent with risky tool access: Remove or deny the write-capable tool permission while preserving read-only observation where safe.
• Runaway loop or spend event: Pause the trigger, queue consumer, CronJob, or controller; apply provider quotas and egress throttling.
• Suspected credential compromise: Preserve identity and secrets-access evidence, then revoke and rotate credentials using the incident-response process.
• Active destructive behavior: Isolate the workload, identity, and affected resources immediately. Evidence preservation remains important, but safety takes priority.

Containment should include a recovery decision. Record what must be true before the workload can return, who approves restoration, which credentials must be replaced, which tests must pass, and which monitoring must remain enabled.

Build the Enterprise Agent Inventory

A confirmed or authorized agent should not disappear into an incident ticket. Convert the finding into a durable inventory record that can support security, operations, cost, architecture, compliance, and lifecycle management.

Inventory quality depends on stable identifiers. Require the same agent ID to appear in the service catalog, provider project, cloud tags, Kubernetes labels, pipeline metadata, logs, dashboards, and cost allocation where those systems support it.

Establish Ongoing Detection and Ownership

A one-time hunt finds today’s unknowns. An operating model should make tomorrow’s unknowns expensive to create and easy to detect.

Make Approved AI Activity Identifiable

• Route model traffic through approved organizations, projects, workspaces, private endpoints, or gateways.
• Give each production workload a unique non-human identity instead of a shared key.
• Prefer short-lived federated credentials over static secrets where supported.
• Require owner, agent ID, environment, provider, data classification, and risk-tier metadata on deployments.
• Send provider audit, usage, cost, identity, network, Kubernetes, CI/CD, secrets, and data-access telemetry to a common analytics platform.
• Define retention long enough to investigate low-frequency and scheduled agents.
• Register kill switches, tool-deny controls, quotas, and rollback procedures before production use.

A Kubernetes workload can carry discoverable metadata like the following. Adapt the label keys and allowed values to the enterprise policy and admission controls.

metadata:
  labels:
    ai.enterprise/agent-id: finance-variance-agent
    ai.enterprise/owner: finance-automation
    ai.enterprise/provider: approved-gateway
    ai.enterprise/risk-tier: bounded-write

Successful implementation makes the workload joinable across cluster inventory, policy, logs, ownership, and cost. Labels are not security controls by themselves. Enforce required metadata at admission, validate the values against a registry, and protect who can change them.

Build Correlation Detections

High-value detections combine signals that are individually weak:

• new model-provider destination plus an unregistered source workload;
• new provider project or key plus no cost-center or owner mapping;
• service-principal sign-in plus provider traffic from a new runner or cluster;
• package installation plus model traffic plus subsequent tool API calls;
• secrets retrieval followed by model or external-service traffic;
• model activity followed by cloud, ticketing, messaging, code, or data writes;
• default Kubernetes service account plus external egress plus secret references;
• repeated tool errors, rapid retries, fan-out, or spend acceleration;
• off-hours scheduled execution without a registered operating schedule;
• an inventory record whose owner, repository, deployment, identity, or telemetry no longer resolves.

Assign every detector an investigation owner, evidence query, severity model, suppression rule, response action, and review cadence. An alert with no ownership simply creates another shadow system.

Require Recurring Attestation

Owners should periodically confirm that the agent still exists, still serves the stated purpose, still uses the recorded identities and tools, and still operates within its approved authority. Trigger out-of-cycle review when the model, tools, data sources, identity permissions, deployment path, provider, autonomy, or business process changes.

Agent Shark Patrol Checklist

Use this checklist as a recurring hunt or incident worksheet. Mark each line as complete, not applicable, blocked, or evidence retained.

Scope and Baseline

• Record the investigation window, environments, accounts, clusters, repositories, runners, and providers in scope.
• Export the approved AI application and agent inventory.
• Export approved provider organizations, projects, workspaces, gateways, and billing accounts.
• Identify the business, security, platform, identity, network, and incident-response contacts.
• Confirm log retention and analyst access before making containment changes.

Network and Provider Evidence

• Search DNS, proxy, firewall, flow, and egress telemetry for observed AI destinations.
• Identify new source workloads, hosts, users, service identities, and first-seen dates.
• Compare direct-provider traffic with traffic expected to pass through approved gateways.
• Inventory provider users, projects, workspaces, API keys, service accounts, usage, audit records, and cost.
• Reconcile provider spend with cloud billing, procurement, expenses, and cost centers.
• Flag personal accounts, unknown projects, shared keys, and unowned spend.

Identity Evidence

• Inventory service principals, managed identities, IAM roles, access keys, Kubernetes service accounts, OAuth apps, bots, and service users.
• Find identities with no owner, no purpose, stale credentials, or broad roles.
• Review first use, last use, source environment, sign-in geography, and off-hours activity.
• Map each non-human identity to a runtime, repository, deployment path, and owner.
• Identify personal credentials used by unattended workloads.

Kubernetes, CI/CD, and Worker Evidence

• Export Kubernetes Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, pods, service accounts, and image digests.
• Review default service accounts, broad RBAC, secret references, egress, and unapproved images.
• Inspect pipeline definitions, build logs, runner identities, deployment variables, and artifact repositories.
• Search code, notebooks, and lock files for model clients, orchestration frameworks, and tool integrations.
• Inventory scheduled tasks, timers, services, containers, serverless functions, RPA workflows, and automation workers.
• Identify dynamic package installation and mutable runtime changes.

Tool, Credential, and Data Reachability

• Correlate model activity with shell, browser, cloud, ticketing, messaging, source-control, database, and infrastructure API calls.
• Map secret references and secrets-manager access without copying secret values.
• Map effective cloud, Kubernetes, application, data, and SaaS permissions.
• Identify writable systems, approval actions, destructive operations, and spend authority.
• Classify reachable data and record residency, privacy, and regulatory concerns.
• Check whether shared credentials prevent workload-level attribution.

Correlation and Triage

• Create one candidate record per workload and preserve supporting evidence.
• Assign confirmed, probable, possible, registered, or false-positive confidence.
• Score maximum reachable impact separately from evidence confidence.
• Identify the business and technical owner, or explicitly record that no owner exists.
• Determine whether the workload is a prototype, production dependency, security test, abandoned automation, or suspected compromise.

Containment and Recovery

• Preserve provider, identity, network, runtime, deployment, secrets, data, and cost evidence.
• Select the least destructive control that reduces immediate risk.
• Pause triggers or controllers before deleting individual runtime instances when recreation is possible.
• Apply tool restrictions, egress controls, quotas, or rate limits where they reduce risk without erasing evidence.
• Revoke and rotate credentials after evidence capture when compromise or disclosure is confirmed or likely.
• Define restoration approval, validation tests, monitoring requirements, and rollback before re-enabling the workload.

Inventory and Ownership

• Create or update the enterprise agent inventory record.
• Assign stable agent ID, business owner, technical owner, support team, risk tier, and cost center.
• Record runtime, source, deployment, model, provider, identity, tools, data, triggers, network reach, and spend.
• Record telemetry, retention, kill switch, rollback, recovery, and last-review evidence.
• Add missing SIEM detections, admission controls, gateway rules, or identity policies revealed by the investigation.
• Schedule owner attestation and define the next review trigger.

Validation and Closure Criteria

The investigation can move from active discovery to closure only when the organization can answer these questions with evidence:

• What executed, where, and during which time window?
• Which model provider, service, gateway, or local model was used?
• Which human and non-human identities participated?
• Which credentials, tools, systems, and data sources were reachable?
• What actions occurred, and which actions were merely possible?
• What spend occurred, and who owns the cost?
• Who is accountable for the workload and business process?
• Was the activity approved, unapproved but benign, unsafe, compromised, or malicious?
• What containment and credential actions were completed?
• What evidence was preserved, where is it retained, and who can access it?
• What inventory, policy, logging, architecture, and detection changes prevent recurrence?
• What conditions must be met before the workload can operate again?

A closed ticket without an inventory update, owner, authority map, and detection improvement is not closure. It is deferred rediscovery.

Rollback and Fallback Considerations

Discovery controls can affect legitimate workloads. A new egress deny rule may block approved model traffic. Revoking a shared key may stop several applications. Pausing a controller may interrupt a business process. Rotating a secret may leave a stale copy in an unmanaged worker.

Before each containment change:

• identify dependent workloads and business services;
• capture the current configuration and evidence;
• define the expected effect and a time-bounded observation window;
• prepare a rollback or alternate path;
• notify the operational owner when doing so does not increase risk;
• verify both risk reduction and service impact after the change.

When centralized telemetry is incomplete, the fallback is not to guess. Narrow the scope, increase endpoint or workload observation, apply temporary rate and spend limits, preserve available records, and make uncertainty explicit in the decision log.

Common Failure Modes

Hunting Only for Famous Framework Names

Custom scripts, low-code workflows, provider-native agents, embedded copilot features, and ordinary API orchestration may not contain recognizable framework names. Use framework detection as one input, not as the inventory strategy.

Treating All Provider Traffic as an Agent

Interactive developer use, approved applications, security testing, and embedded SaaS features can generate the same network destinations. Confirm runtime behavior, identity, trigger, and tool authority before escalation.

Relying on One Shared Gateway Log

A gateway can improve control, but it may not see personal subscriptions, direct cloud-service calls, local models, private endpoints, or traffic from unmanaged devices. Validate bypass paths.

Revoking Credentials Before Capturing Attribution

Immediate revocation may be necessary during active harm. In lower-urgency cases, first preserve identity events, last-used metadata, source mappings, and dependent workloads so the organization can rotate safely and understand scope.

Deleting the Pod Instead of Stopping the Controller

Deployments, CronJobs, GitOps reconcilers, pipeline jobs, and external schedulers can recreate a workload. Identify the source of truth and trigger before assuming the runtime instance is the system.

Building an Inventory That Immediately Goes Stale

A spreadsheet updated after incidents will decay. Integrate the agent ID and owner into deployment metadata, identity, provider projects, cost allocation, logging, policy, and release gates so the inventory can be reconciled continuously.

Collecting Sensitive Content Instead of Evidence

Investigators may copy prompts, responses, documents, and secret values because they seem definitive. Prefer metadata, hashes, access records, identifiers, and narrowly scoped content collection under approved procedures.

Conclusion

Shadow AI is not difficult to find because it is invisible. It is difficult to find because its evidence is fragmented across systems that different teams own. Network operations see destinations. Identity teams see principals. Cloud teams see API events. Platform teams see workloads. Security teams see secrets and alerts. Finance sees spend. None of them sees the complete agent unless the records are joined.

The practical response is an operational discovery loop: establish the approved baseline, collect identity and execution evidence, find provider traffic and spend, inspect CI/CD and Kubernetes, map credentials and data reachability, correlate the signals, score confidence and blast radius, preserve evidence, and contain with the least destructive control that reduces risk.

The long-term goal is not merely to catch rogue prototypes. It is to make every authorized agent identifiable, attributable, bounded, observable, recoverable, and owned. When the enterprise can connect an agent ID to its runtime, identity, tools, data, provider, cost, owner, and kill switch, shadow AI has fewer places to hide and far less room to bite.

External References

• National Institute of Standards and Technology: AI RMF Core
  Canonical URL: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
• Microsoft Learn: Workload identities – Microsoft Entra Workload ID
  Canonical URL: https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
• Kubernetes: Auditing
  Canonical URL: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
• Kubernetes: Service Accounts
  Canonical URL: https://kubernetes.io/docs/concepts/security/service-accounts/
• Amazon Web Services: Monitor Amazon Bedrock API calls using CloudTrail
  Canonical URL: https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html
• Microsoft Learn: Monitor Azure OpenAI in Microsoft Foundry Models (classic)
  Canonical URL: https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/monitor-openai
• OpenAI: Admin APIs
  Canonical URL: https://developers.openai.com/api/docs/guides/admin-apis
• Anthropic: Admin API
  Canonical URL: https://platform.claude.com/docs/en/manage-claude/admin-api
• Google Cloud Documentation: Agent Platform audit logging information
  Canonical URL: https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/general/audit-logging

The post The Shadow AI Beneath the Surface: Finding Unsanctioned Agents Before They Bite appeared first on Digital Thought Disruption.