In part 1 of this series, on discovering and mapping Copilot Studio agents in the wild, we took a close look at how active discovery and capability mapping for agents could play out. In this second part, we want to dive into how design patterns, metadata, and AI integrations can be targeted as attack surfaces using passive recon and OSINT methods, tailor-made for agents and AI systems.
Recap: What is reconnaissance for agents & AI systems
We can define reconnaissance for agents & AI systems as the systematic process of discovering, enumerating, and mapping publicly deployed AI agents and their supporting infrastructure, including the identification of agent types, deployment platforms, capabilities (tools, knowledge, integrations), authentication posture, and exploitable metadata.
This type of recon can be seen as a subset of web discovery, which focuses on AI systems as the targets and which often sits at the intersection of web application, cloud, SaaS, low-code/no-code and API security, with an addition of AI-specific practices.
It encompasses both the discovery of agents themselves and the mapping of the broader AI infrastructure ecosystem (e.g., LLM runtimes, API gateways, databases, MCP servers) that supports them. It often aims to answer a specific class of questions (some of which we’ll address in the discussed techniques later on), such as:
Attack surface
- What agents exist and how are they deployed?
- What AI backends are they integrated (e.g., proxies, MCP endpoints, skills)
- How is the system hosted and what infrastructure supports it?
Initial access
- What inference endpoints are open?
- Is authentication configured, and if so how?
Discovery & impact
- What metadata is exposed, and what does it reveal about the organization?
- What knowledge sources and capabilities do the systems or agents connect to?
- Are any identities configured into these connections?
The first step is often reconnaissance for targets. Agents & AI targets may be uncovered through a combination of OSINT, platform-specific deployment knowledge, predictable design patterns, search indexing, embedded clients, registries, or indirect infrastructure artifacts. Once a target is discovered, capability enumeration and discovery of embedded knowledge may then occur through direct interaction with the agent, inspection of metadata, API probing, tool discovery, and uncovering connected systems and possible integrated identities.
Passive recon methods that support active scanning
Continuing from where we left off in part 1, we should first mention that passive reconnaissance can assist in later stages of active scanning & discovery.
The secret goldmine: Embedded agents and the backlinks that link them
Many agentic SaaS and enterprise platforms are designed to be embedded via iFrames or injected into websites and frontend portals. This is because one of the main use cases for agents is embedding them elsewhere (this could serve both infrastructure or security purposes), which is often done using iFrames. This creates a natural trail of backlinks, since we know there’ll be an iFrame link between a source enterprise site and the agentic backend.
While this can exist for different types of backend, for the purposes of our conversation it’s mostly prominent for agentic SaaS platforms, and we’ll use Copilot Studio for some of the examples here, for clarity:
There are ways to search specifically for these backlinks, for example, by using backlink-oriented search engines, which are especially built for these embedded use cases and can help you address a few important questions, such as:
- Where do agentic targets exist, and what frontends are they served at?
- What is the agentic attack surface for a given target?
- What exposed metadata can be used to expand the attack surface?
This helps to produce a quick list of targets to probe for low-hanging fruit and misconfigurations, and can also support deeper target-focused recon (e.g., by discovering adoption trends of a specific platform by a company).
If it’s a web resource, it can potentially be indexed & discovered
This is what I love about recon: who’s to say we can discover existing resources, just because the discovery isn’t part of the platform’s official business logic, or just because specific resources weren’t considered to be potential attack surfaces?
The ChatGPT shared conversations resources recon via Google indexing issue last year and the recently reported Claude exposed conversations case are examples of how shared conversation got indexed by search engines, and could be found via Google Dorking.
Subdomain and environment discovery patterns
Platforms leave footprints. Subdomain enumeration often reveals environment-specific hostnames that anchor further discovery.
Continuing with Copilot Studio as an example from part 1 of this series, we can use what we know about the Power Platform API to expose available environments, even ones which aren’t the default ones.
How? We mentioned that the Copilot Studio creates a resource on the Power Platform API for each agent, using the same components we saw in the demo website URL (environment; solution prefix; and agent name; also explained here).
If we take a second look, we’ll notice that the environment is actually a part of the subdomain in the API, which is interesting, since subdomain enumeration is a well-known security field with existing robust tools for exploration.
So, we can use tools like Subfinder or AMASS to quickly discover subdomains, which are actually Power Platform environment & tenant IDs:
This is an example of how we can leverage existing security tools for agentic recon, if we understand an agentic platform or software well enough.
Uncovering Design Patterns to Fuzz Agent Builder
Similar concepts applied to Agent Builder agents, which is an agentic LCNC platform by OpenAI. One of the main differences here is that, although OpenAI manages the backend, published agents aren’t self-hosted on OpenAI’s platform: the builders have to manage the servers on which their agents are hosted & deployed, independently.
How recon works here
Agent discovery is still possible by similar concepts we discussed for Copilot Studio agents: scanning multiple the hosting platforms, validating agent connectivity and reconning for tools & knowledge. However, agentic resources will now be fuzzed on relevant hosting services, according to observed deployment patterns for the platform.
Show Me Your Design Patterns, and I’ll Show You How You’ll Be Reconned
In a nutshell, because there are observable and recommended design patterns for builders, we can perform some passive discovery that will later support active scanning (even though there’s a less clear approach for the hosting endpoint, at the start at least):
- We can identify several naming conventions suggested by OpenAI’s Github repositories for Agent Builders
- Some hosting platforms (and specifically ones mentioned by OpenAI documentation, like Vercel), use subdomains which are derived from Git projects’ branch names
- Git projects’ branch names are often used with slight alterations, prefixed and suffixes, and effectively can act as a starting point to discover deployed agents
- This is an out-of-the-box issue, since builders often keep the defaults and thus reduce search space significantly
Functionality testing (subsequent active scanning step)
As in other agentic SaaS platforms, there’s still an additional aspect of verifying that the agent works, even after it’s discovered as an existing resource. For Agent Builder, the most important aspect here is identifying that the agent has a verified domain connected to it. This is done as follows:
Once an agentic endpoint is verified, the agent can be probed directly (e.g., via its chat) for integrated tools, identities, or knowledge. Similarly to what was shown in part 1 for Copilot Studio: exposed documents which seem to have been added as embedded knowledge which requires no authentication, have also been found on Agent Builder in the wild, as can be seen in the exposed knowledge file below:
More about possible risks researched in Agent Builder here.
Recon Beacons: MCP Registry Diving for Target Lists
Your registry is the attacker's dumpster. As MCP adoption grows, registries become a new form of “agent directory”, which are a place to discover MCP endpoints and sometimes also tools listing.
This can effectively be used as an OSINT method to search as an open database, meaning, as used for passive scanning to identify exposure using existing indexing of what’s been deployed by collecting information from wherever it’s already being published (intentionally or not). Attackers can and will probe listed servers for authentication and capabilities directly.
How recon works here
There are multiple MCP registries, however, as an example: if you curl the modelcontextprotocol.io official endpoint for the MCP registry(https://registry.modelcontextprotocol.io/v0.1/servers), you’ll get back a JSON which will, for some MCP servers, include the backend URLs, which are effectively agentic tools endpoints that can be probed for recon and sometimes more.
Discovering AI Deployed Servers
We can identify different types of AI integration surfaces using platforms like Shodan, which scan for Internet-connected devices. For example, we can look for MCP servers using specific fingerprints (which we can later probe for unauthenticated access and tool listing); as well as exposed API interfaces for layers that sit between applications and LLM providers; etc., thus helping uncover exposed agentic components beyond the agentic endpoints themselves.
Here is an example of an exposed API wrapper with both agentic and DB methods (and apparently without authentication enforced), which was found using these techniques:
Defender guidance
AI systems are applications, and should be treated as such. Agents and the platforms that host them, including their metadata, integrations, and backends, form a real and growing attack surface. From a defender’s perspective, the goal is to reduce that attack surface and prevent agents from becoming an initial foothold in an attack chain.
Key defensive considerations include:
- Observability
Maintain visibility into deployed agents, associated resources, user activity, connected tools, and AI middleware components. You cannot protect what you cannot see. - Hard guardrails beyond prompts
Prompt-level controls & visibility are not sufficient. Enforce structural guardrails at the platform to reduce blast radius. - Authentication and authorization
Carefully review agents that do not require authentication. Validate that actions, tools, and APIs enforce proper identity and permission checks. - Identify internet-exposed agents and AI systems
Identify any publicly exposed agents and AI systems to verify & constrain which ones should actually be available publicly and what their capabilities should be. Be sure to verify expected access & authentication to any resources and tools (before attackers do).
Finally, validate your assumptions in the wild. Tools such as PowerPwn can help you assess how your agents and platforms appear from an external attacker’s perspective, and identify gaps before adversaries do.
