Find AI agents hiding in code and runtime traffic

The hardest agent to govern is the one nobody knows about. A team can build a useful helper in a repository, wire it to a production endpoint, and start using it before the platform team has a clean inventory. That is usually not malicious. It is what happens when agent work moves faster than the review process.

Agent Discovery is CorpAI's answer to that gap. It looks for agent evidence in two places: source code and runtime traffic. Static discovery finds declared agents, frameworks, manifests, and custom patterns in GitHub repositories. Dynamic discovery looks at telemetry from live application traffic, starting with AWS ALB access logs.

The point is not to turn every match into an alarm. The point is to give admins a useful review queue. Some findings become approved catalog entries. Some are harmless internal experiments. Some need better documentation, access control, or retirement. CorpAI gives teams the evidence to make that call.

Why Discovery Matters

Enterprise AI governance often starts with the obvious systems: approved chat tools, sanctioned model providers, and platform-managed agents. The less obvious systems are just as important. Internal teams may build agents for support triage, sales research, finance reconciliation, incident response, or data operations. Those agents can be valuable, but they also create questions.

Who owns the agent? What data can it reach? Is it using a known framework? Is there a manifest? Which endpoint serves it? Has it been reviewed, or is it just something running behind an application route? A static inventory alone cannot answer all of that. Runtime telemetry alone cannot either. The useful view comes from combining both.

Static Discovery

Static discovery starts when an admin connects the CorpAI GitHub App and enables selected repositories. CorpAI installs a GitHub Actions workflow into the repository. That workflow runs on pushes to the configured branch and can also be run manually.

The workflow checks out the repository, requests the active signature bundle from CorpAI, scans text files under a safe size limit, and skips common generated or dependency directories such as node_modules, dist, build, and .git. When a signature matches, the workflow reports the signature id, file path, line number, redacted snippet, and match hash.

The signature model matters because agent evidence is not one fixed shape. Some teams use known frameworks. Some expose A2A endpoints. Some define manifest files. Some have organization-specific names or wrapper classes. CorpAI ships managed base signatures and lets admins add repository-level custom patterns when their environment has its own language.

Dynamic Discovery

Dynamic discovery covers the other half of the problem. Some agent behavior is visible in traffic before it is obvious in code review. A production route may receive A2A requests. A service path may reveal an agent endpoint. An older internal agent may still be running even if the repository moved on.

CorpAI handles this through organization-owned telemetry sources. The first supported source type is AWS ALB access logs. An admin creates an ALB source in CorpAI, receives a source token plus setup URLs, and runs a customer-side forwarder. The forwarder fetches the effective signature bundle, scans log records locally, redacts common sensitive URL material, and uploads normalized findings to CorpAI.

That design keeps source authentication explicit. Each telemetry source has its own token, status, environment label, setup metadata, heartbeat, and scan history. If a source should stop reporting, an admin can disable it. Findings already received remain visible, but the token no longer works for ingestion.

How Static and Dynamic Discovery Work Together

Static and dynamic discovery answer different questions. Static scans are strong when the agent is declared in code: framework imports, manifests, route definitions, Docker references, workflow files, or internal wrapper classes. Dynamic scans are strong when the agent is visible through behavior: requests, endpoint paths, hostnames, and runtime records.

When both paths find related evidence, the review gets much stronger. A repository match can show where an agent is implemented. A telemetry match can show that an endpoint is actually receiving traffic. Together, they help admins move from "we found a string" to "this looks like a live agent that needs an owner and a policy decision."

The same signature vocabulary keeps the workflow from splitting into two separate tools. Base signatures and classifications can identify common agent patterns across both paths. Custom patterns let teams teach CorpAI about their own internal agent names, wrappers, or endpoint conventions.

What Admins Gain

Admins get a practical inventory path. They can connect GitHub accounts, choose which repositories should run static scans, create custom patterns for a specific repository, add telemetry sources, and search observations without waiting for every team to manually self-report.

Security teams get better triage. An observation includes enough context to ask the next question: Is this a known agent? Is it approved? Is it still used? Does it need an Agent Card? Should it be deployed through CorpAI's governed runtime instead of staying behind a private route?

Platform teams get a bridge into the rest of the CorpAI lifecycle. Discovery can feed registration, approval, deployment, and audit work. The feature does not assume every match is production-ready. It gives teams a way to find agent activity early enough to bring it under control.