How to Discover Shadow AI Agents in Your Organization

The Challenge

Most organizations have no inventory of their AI agents. A 2025 survey found that 68% of enterprises have AI agents running in production that are not tracked by any central team. These shadow agents create regulatory, security, and cost risks. An ungoverned agent might process customer PII without proper consent, call external APIs with production credentials, generate outputs that violate brand guidelines, or consume thousands of dollars in LLM API costs without any budget attribution. Security teams cannot assess the attack surface of agents they do not know exist. Compliance teams cannot include unknown agents in audit scope.

How NodeLoom Solves This

NodeLoom Agent Discovery takes a multi-layered approach to finding AI agents. The eBPF kernel-level agent detects any process making TLS connections to LLM provider APIs (OpenAI, Anthropic, Google, Cohere, and others) without requiring code changes or container modifications. Cloud provider scanning inspects AWS, GCP, and Azure accounts for resources that match AI agent patterns (Lambda functions with LLM API keys, ECS tasks running agent frameworks, GKE pods with AI SDK dependencies). GitHub repository scanning identifies codebases that import AI agent frameworks. Together, these provide a complete inventory of your AI agent landscape.

Step-by-Step Implementation

1. 1

   Deploy the NodeLoom eBPF agent as a Kubernetes DaemonSet

   The NodeLoom eBPF agent runs as a DaemonSet on your Kubernetes clusters, meaning one instance runs on every node. The agent uses eBPF probes attached to the TLS send/receive kernel functions to detect outbound connections to known LLM provider endpoints. It identifies the source pod, namespace, container image, and the target LLM provider — without decrypting traffic or accessing request payloads. Discovered agents appear in the NodeLoom dashboard within minutes of deployment. The DaemonSet requires a Kubernetes cluster running Linux kernel 5.8 or later.

2. 2

   Configure cloud provider scanning

   Connect your AWS, GCP, and Azure accounts to NodeLoom using read-only IAM roles. NodeLoom scans your cloud resources on a configurable schedule (default: every 6 hours) and identifies resources that match AI agent patterns. On AWS, it inspects Lambda function environment variables and layers, ECS task definitions, EC2 instance metadata, and SageMaker endpoints. On GCP, it scans Cloud Functions, Cloud Run services, and GKE workloads. On Azure, it checks Azure Functions, Container Instances, and AKS deployments. Each discovered resource is classified by confidence level (high, medium, low) based on the strength of the detection signal.

3. 3

   Set up GitHub repository scanning

   Install the NodeLoom GitHub App on your organization. NodeLoom scans repositories for imports of AI agent frameworks (langchain, crewai, autogen, openai, anthropic, and others) and maps codebases to their deployment environments. When a developer pushes code that imports an AI framework, NodeLoom adds the repository to the agent inventory and links it to any matching cloud resources. This gives you a code-to-production mapping of your AI agents.

4. 4

   Review the discovered agent inventory

   The Agent Discovery dashboard shows every discovered AI agent grouped by detection source (eBPF, cloud scan, GitHub), environment (production, staging, development), team or namespace, LLM provider (OpenAI, Anthropic, Google, etc.), and governance status (instrumented, uninstrumented, quarantined). Each agent entry includes the detection method, last seen timestamp, estimated monthly LLM API cost, and a risk score based on factors like whether it handles PII, has guardrails configured, and is included in compliance scope.

5. 5

   Instrument discovered agents with NodeLoom SDKs

   For each discovered agent that is not yet instrumented, NodeLoom generates SDK integration instructions specific to the detected framework and language. If a discovered agent is a Python LangChain application, you get the exact callback handler code to add. If it is a TypeScript application calling the OpenAI API directly, you get the TypeScript SDK wrapper code. The goal is to move every agent from "discovered" to "instrumented" status, at which point it gets full monitoring, guardrails, drift detection, and compliance tracking.

Key Benefits

Frequently Asked Questions

Does the eBPF agent inspect or decrypt network traffic?

No. The eBPF agent only inspects the TLS handshake SNI (Server Name Indication) field to identify the destination hostname. It does not decrypt traffic, read request payloads, or access response data. It detects that a process is communicating with api.openai.com, but it does not see what is being sent or received.

What LLM providers does the eBPF agent detect?

The agent detects connections to OpenAI, Anthropic, Google (Vertex AI and Gemini), Cohere, Mistral, Replicate, Hugging Face Inference API, Azure OpenAI, and AWS Bedrock endpoints. The detection list is updated regularly.

Can I deploy the eBPF agent outside of Kubernetes?

Yes. The eBPF agent can run as a standalone binary on any Linux host with kernel 5.8 or later. The Kubernetes DaemonSet is the recommended deployment method, but standalone deployment is supported for VMs and bare-metal servers.

What permissions does the cloud provider scan require?

NodeLoom uses read-only IAM roles. On AWS, the role needs permissions like lambda:ListFunctions, ecs:DescribeTaskDefinitions, and ec2:DescribeInstances. No write permissions are required, and the role can be scoped to specific regions or accounts.

How often does discovery scanning run?

eBPF detection is continuous and real-time. Cloud provider scanning runs on a configurable schedule (default every 6 hours). GitHub scanning runs on push events via the GitHub App webhook, with a full scan every 24 hours.