What Is AI Agent Discovery?

The Shadow AI Problem

Shadow AI refers to AI agents and LLM-powered applications that are deployed by teams or individuals within an organization without the knowledge or approval of centralized IT, security, or compliance teams. Just as shadow IT emerged when employees adopted cloud services without oversight, shadow AI is proliferating as teams rapidly build and deploy AI agents using readily available APIs and frameworks.

The scale of the problem is significant. Development teams spin up AI coding assistants, marketing deploys content generation agents, customer support builds chatbots, data teams create analysis pipelines — all using LLM APIs that can be activated with a single API key. Many of these deployments happen outside formal software development processes, through quick scripts, notebook experiments that become production services, or third-party tools with embedded AI capabilities.

Shadow AI creates multiple risk vectors. Unmonitored agents may leak sensitive data to LLM providers, generate non-compliant outputs, or make decisions without appropriate oversight. From a cost perspective, untracked API usage can result in unexpected bills. From a security perspective, API keys may be poorly managed, and agents may have excessive permissions.

The fundamental challenge is that traditional asset management and CMDB approaches do not capture AI agents. An AI agent is not a server, a container, or a conventional application — it is a piece of code that calls an LLM API, and it can exist as a standalone script, a function within a larger application, or an embedded capability in a third-party tool. Discovering these agents requires purpose-built scanning techniques.

How AI Agent Discovery Works

AI agent discovery employs multiple scanning techniques to achieve comprehensive coverage across different infrastructure layers.

Cloud infrastructure scanning connects to AWS, GCP, and Azure accounts through read-only IAM roles and identifies AI-related services: Amazon Bedrock endpoints, Azure OpenAI deployments, Google Vertex AI resources, SageMaker endpoints, and similar services. It also detects EC2 instances, Cloud Run services, or Lambda functions that make outbound connections to LLM API endpoints.

Code repository scanning analyzes GitHub, GitLab, and Bitbucket repositories for dependencies that indicate AI agent usage. This includes detecting imports of frameworks like LangChain, CrewAI, AutoGen, Haystack, and LlamaIndex, as well as direct usage of OpenAI, Anthropic, and Google AI client libraries. Repository scanning can also identify API keys that may be hardcoded or improperly managed.

Container and Kubernetes scanning examines running workloads to identify containers with AI framework dependencies, environment variables pointing to LLM API keys, and network connections to AI provider endpoints. This catches agents that were deployed through container orchestration without going through formal service catalogs.

Network-level detection using eBPF (extended Berkeley Packet Filter) provides the deepest level of discovery. eBPF probes attach to the Linux kernel networking stack and intercept TLS handshakes and DNS queries to identify any process communicating with known LLM API endpoints (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, etc.). This technique requires no code changes and catches agents regardless of the language, framework, or deployment method used.

Building an AI Agent Inventory

The output of discovery is a comprehensive AI agent inventory — a centralized catalog of every AI agent in the organization with metadata about each one. A useful inventory includes several key attributes for each agent.

Identification metadata includes the agent name, owning team, deployment location (cloud account, cluster, repository), and the AI frameworks and models it uses. This answers the basic question of what agents exist and who is responsible for them.

Risk classification categorizes agents based on the sensitivity of data they access, the decisions they make, whether they are customer-facing, and the regulatory requirements that apply. This allows governance teams to prioritize their efforts on the highest-risk agents.

Governance status tracks whether each agent has been instrumented with observability SDKs, whether guardrails are configured, whether it is covered by compliance reporting, and when it was last reviewed. This provides a clear picture of governance coverage gaps.

The inventory should be continuously updated as new agents are deployed and existing ones are modified or decommissioned. Static, point-in-time audits quickly become stale given the pace of AI agent deployment in most organizations. Automated discovery that runs on a schedule or in real time ensures the inventory remains current.

NodeLoom builds this inventory automatically through its discovery scanning capabilities. Discovered agents can be onboarded into the governance platform with SDK instrumentation, guardrail configurations, and compliance tracking — transforming visibility into active governance.

Why Discovery Matters for Compliance

Regulatory frameworks increasingly require organizations to maintain an inventory of their AI systems. The EU AI Act mandates that providers and deployers of high-risk AI systems maintain documentation and registration. ISO 42001 requires organizations to identify and document AI systems within their scope. NIST AI RMF includes "map" as a core function, requiring organizations to understand the context and scope of their AI systems.

Without discovery, organizations cannot truthfully claim compliance with these requirements. An incomplete inventory means unknown risks, ungoverned agents, and potential regulatory violations. Auditors and regulators will ask: "How do you know this is a complete inventory?" and organizations need a defensible answer — not just a spreadsheet maintained through manual processes.

Discovery also supports incident response. When a security event occurs — for example, an LLM provider discloses a data breach — organizations need to quickly identify all agents that interact with that provider. Without a comprehensive inventory, this becomes a manual, error-prone process during a time-critical situation.

Cost governance is another compliance-adjacent benefit. Organizations subject to financial controls need to understand and allocate AI spending accurately. Discovery provides the foundation for cost attribution by identifying all sources of LLM API usage across the organization.

Implementing AI Agent Discovery

Effective discovery implementation follows a layered approach, starting with the easiest and least intrusive scanning methods and progressively adding deeper detection capabilities.

Start with cloud account scanning. Connect read-only credentials for your AWS, GCP, and Azure accounts. This provides immediate visibility into managed AI services and is non-intrusive — it reads metadata only and does not affect running workloads. Most organizations discover AI services they did not know existed during this initial scan.

Add repository scanning next. Connect to your GitHub or GitLab organization to scan for AI framework dependencies across all repositories. This reveals agents that are in development or deployed outside of cloud-managed services. Repository scanning also identifies security issues like hardcoded API keys.

Deploy container scanning for Kubernetes clusters and Docker environments. This layer catches agents that are running in production but were not deployed through formal cloud services — for example, a Python script with OpenAI calls running in a Docker container on an EC2 instance.

For maximum coverage, deploy eBPF-based network monitoring on Linux hosts that may run AI workloads. This kernel-level detection catches every LLM API call regardless of the deployment method, language, or framework. It is particularly valuable for discovering agents that do not show up through other scanning methods.

NodeLoom supports all four discovery layers and consolidates results into a single agent inventory. Discovered agents are presented with recommended governance actions — such as installing the SDK for monitoring, configuring guardrails, or adding the agent to compliance scope — enabling teams to move quickly from discovery to governance.

Frequently Asked Questions

Related Articles