How to Discover AI Agents Through Cloud Platform APIs

August 13, 20266 min read

Agents built on managed cloud platforms are easy to lose track of, even though the platform running them already knows they exist. A team spins up an agent in AWS Bedrock or Google Vertex AI, ships it, and moves on. The provider keeps a record. The security team often does not. That gap between what the platform knows and what your organization has inventoried is exactly what API-driven discovery closes.

This is a practical guide to that technique: how to query the cloud platforms' own control-plane APIs to enumerate the agents they run, what to capture per agent, and where this method stops seeing. It is one of four discovery techniques a complete strategy needs, and the one that gives you authoritative inventory for managed cloud agents straight from the source.

What API-driven discovery is

API-driven discovery means asking the cloud platform directly for a list of the agents it is running. Most managed AI platforms maintain a control plane that tracks the agents, tools, and configurations deployed on them. Increasingly, they expose that inventory through management APIs you can query.

This is a different signal from the other discovery techniques. Telemetry-based discovery listens to what agents emit. Network-layer analysis inspects what agents send over the wire. API-driven discovery skips both and goes to the platform's own system of record. When it works, you get a clean, structured list rather than an inference assembled from traces or packets.

The catch, which we will get to, is that this only works for agents built on platforms that offer these APIs. But for those agents, no other technique gives you a more authoritative answer.

Platform by platform

Each major cloud provider handles agent enumeration differently, and the surfaces are still maturing. Here is how to think about querying each.

AWS Bedrock

Bedrock exposes agents through its Agents for Bedrock and AgentCore control-plane APIs. You can enumerate the agents in an account and region, then drill into each one to retrieve its aliases, action groups, and the foundation model it is configured to use. Action groups are worth capturing carefully, since they define the tools and functions an agent can invoke, which is a large part of its risk surface. Iterate across every region and account in your organization, because an agent enumeration scoped to one region will miss agents deployed elsewhere.

Google Vertex AI

Vertex AI runs agents through its Agent Engine (also surfaced via Agentspace), which deploys and hosts reasoning engines. You can list the deployed agents and reasoning engines per project, then inspect each for its configuration and the tools it has access to. As with Bedrock, scope matters: enumeration runs per project, so a complete inventory means iterating across every project in your organization rather than querying a single one.

Azure AI Foundry

Azure AI Foundry provides an Agent Service that manages agents along with the tools and connections they use. You can query it to enumerate deployed agents and inspect the resources each one is wired to. As with the other providers, the specifics of what the API returns are evolving, so treat the enumeration as a starting inventory to reconcile against what you actually observe rather than a guaranteed-complete list.

The through-line across all three: query per account or project, iterate across regions, and capture not just that an agent exists but what it can reach. These APIs are newer than the platforms themselves, and coverage is still filling in, so build for the fact that what they return today will expand over time.

What to capture per discovered agent

Enumerating agents is only useful if you record enough about each one to act on it later. For every agent an API returns, capture:

Model — which foundation model or model version the agent runs on.
Tools and action groups — the functions, APIs, and capabilities the agent can invoke. This defines much of its risk surface.
Data sources — the knowledge bases, vector stores, or databases the agent can reach.
Owning account or project — where the agent lives, which is your first clue to who is responsible for it.
Region — where it runs, which matters for both completeness and data residency.
Owner — the accountable person or team, if the platform's metadata or tags resolve it.

This metadata is what turns a raw list into something a security team can triage. An agent's name tells you almost nothing. Its model, tools, and data access tell you how much risk it carries and how urgently it needs an owner and guardrails.

The limitation: managed platforms only

API-driven discovery sees exactly one class of agent: those built on managed platforms that expose enumeration APIs. Everything else is invisible to it.

An agent self-hosted on a VM, running in a container, or built on a framework with no management API will never show up in a platform API query, no matter how thorough your enumeration. The platform does not know about it because the platform is not running it. This is the technique's blind spot, and it is a large one in most enterprises, where plenty of agent code runs outside managed services.

The practical move is to treat the API response as a declaration, not the truth. Reconcile what the platforms declare against what you actually observe through telemetry and network analysis. Where an agent shows up in your traces but not in any platform API, you have found something running outside managed infrastructure. Where the reverse is true, you may have an agent the platform provisioned that has gone quiet. The gap between declared and observed is where shadow agents hide.

Where it fits with the other three techniques

API-driven discovery is one layer of a strategy that needs all four techniques, because each catches what the others miss.

Telemetry-based discovery listens to OpenTelemetry streams and catches any agent that emits traces, whether or not it runs on a managed platform. It covers self-hosted agents that API-driven discovery cannot see, as long as they are instrumented.

MCP server monitoring finds agents by the capability surface they expose through Model Context Protocol servers, catching agents that advertise tools even when their platform offers no enumeration API.

Network-layer analysis inspects traffic for LLM API call signatures and catches agents that emit no telemetry and expose no MCP server, including ones built on non-standard frameworks.

API-driven discovery's specific contribution is authoritative inventory for managed cloud agents, straight from the platform's own record. The other three infer an agent's existence from what it emits or sends. This one asks the source. That makes it the highest-confidence signal for the agents it can see, and useless for the agents it cannot. Run all four and reconcile the results, and the coverage gaps in any one technique get closed by the others.

From discovery to governance

Discovery is the first step, not the goal. Once an API query surfaces an agent, it needs to move from a line in an inventory to a governed application. Triage each discovered agent by the risk its model, tools, and data access imply. Assign an accountable owner, since an agent without one is an agent no one is answerable for. Classify its risk tier, and apply the guardrails and access controls appropriate to what it does. An agent that can write to a production database needs tighter controls than one that answers read-only questions.

Done at the scale of a large enterprise, this handoff has to be as automated as the discovery itself. Manually triaging thousands of agents does not work, which is why discovery and governance belong in the same workflow.

How Arthur fits

Arthur runs API-driven discovery as one of four parallel techniques in its agent security and governance (ASG) platform, alongside telemetry-based discovery, MCP monitoring, and network-layer analysis. Querying cloud platform APIs gives Arthur authoritative inventory for agents running on managed services like AWS Bedrock and Google Vertex AI, while the other three techniques catch the agents those APIs cannot see. The discovery and governance best practices that make an agent governable also make it discoverable in the first place, since agents that send telemetry to standard locations and expose their tools and data sources are the ones a governance function can actually inventory and assess.

Arthur's data plane runs inside your own VPC, so telemetry and agent data never leave your environment, while the ASG control plane gives security, audit, and governance teams one view of every agent regardless of which cloud or framework runs it. Discovered agents can be triaged, assigned an owner, classified by risk, and brought under guardrails and policy from the same place they were found.

TL;DR

API-driven discovery queries a cloud platform's own control-plane APIs to enumerate the agents it runs, giving you authoritative inventory straight from the source.
AWS Bedrock (Agents for Bedrock / AgentCore), Google Vertex AI (Agent Engine / Agentspace), and Azure AI Foundry (Agent Service) all expose agent enumeration, though the surfaces are still maturing. Query per account or project and iterate across regions.
Capture each agent's model, tools, data sources, owning account or project, region, and owner.
The technique only sees agents on managed platforms that expose these APIs. Self-hosted and unmanaged agents stay invisible, so reconcile declared against observed.
It is one of four discovery techniques. Telemetry, MCP monitoring, and network analysis close the gaps it leaves, and it gives the highest-confidence answer for the managed agents it can see.
Discovery only pays off when it hands directly to governance: triage, ownership, risk classification, and guardrails.

Want to see how Arthur discovers and governs every agent across your cloud environments? Book a demo with an AI expert, or explore the Agent Development Toolkit to start building reliable agents today.

‍