Double Agents: Exposing Hidden Threats in AI Agent Platforms

Double Agents: Exposing Hidden Threats in AI Agent Platforms

Speakers: Michael Katchinskiy; Hagai Kestenberg

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=NgrpxhCDdrM

Overview

Michael Katchinskiy and Hagai Kestenberg, security researchers from the Microsoft Defender for Cloud Research team, presented remote research into the security of AI agent-building platforms, focusing on how attackers can discover, access, and exploit customer-facing conversational agents. The research demonstrated a complete attack methodology -- from reconnaissance (finding agent identifiers in public GitHub repositories) through access (interacting with anonymous agents or bypassing domain allow-list restrictions) to data exfiltration (extracting sensitive organizational data from agent knowledge bases). The primary demonstration was against Google's Vertex AI Agent Builder, where the researchers bypassed the allowed domains restriction for search agents using a simple local hosts file modification. Google responded that they do not treat the allowed domains feature as a security control. The findings extend across multiple platforms including IBM Watson X, WordPress AI, and Microsoft Copilot Studio.

Background

▶ Watch: 50+ agent platforms launched in the past year, most no-code and security-light (2:00)

The rapid proliferation of AI agent-building platforms has created a new attack surface. More than 50 platforms have launched, most within the past year, from major cloud providers (Google Vertex AI, Microsoft Copilot Studio/AutoGen, Amazon Bedrock, IBM Watson X) to independent companies. Most platforms are designed as no-code or low-code tools, enabling non-technical employees to deploy AI agents without security review. This accessibility is both the value proposition and the risk.

Conversational AI agents -- the focus of this research -- interact through natural language chat, cover roles from customer support to personal assistants, execute multi-step workflows, and preserve context between interactions. They are created through a straightforward process: select a base model, define purpose via system prompt, connect data sources and tools, and publish. The publication step is where the security problems begin.

Most platforms offer a web integration that consists of an HTML snippet containing only a static identifier (project ID and agent ID). No tokens, no authentication flows -- just an ID embedded in HTML. This simplicity enables rapid deployment but creates a discoverable, often unprotected entry point to organizational data.

Key Findings

▶ Watch: Finding hundreds of exposed Vertex AI agent IDs on GitHub (8:00)

Agent Discovery at Scale. The researchers searched GitHub and SourceGraph for HTML snippet patterns matching Vertex AI agent integrations and found hundreds of public repositories exposing agent identifiers (project ID and agent ID). Many developers assumed their agents were safe because they were embedded within internal or authenticated websites. The critical gap: website authentication does not apply at the agent level. If an attacker finds the identifiers, they can interact with the agent directly by dropping the HTML snippet into any local HTML file.

Anonymous Agent Access. Using the discovered identifiers, the researchers were able to access multiple anonymous agents within minutes. Some agents returned sensitive organizational data including financial information, with no access controls whatsoever. The agents were configured with anonymous/public API access, and many developers appeared to rely on the assumption that embedding the agent on an internal website provided sufficient protection.

Allowed Domains Bypass for Search Agents. Vertex AI's search agents (which typically work with more sensitive internal data) enforce an allowed domains restriction even when configured with anonymous API access. The researchers bypassed this control by editing their local /etc/hosts file to map the suspected allowed domain (found by browsing the same GitHub repository) to localhost, then serving the HTML snippet from a local HTTP server on that domain. The browser resolved the spoofed domain to localhost, and Vertex AI accepted the request as coming from the allowed domain. This bypass required no special tools -- just a hosts file edit and a basic HTTP server.

Cross-Platform Applicability. The same pattern -- static identifiers in HTML snippets, discoverable via public code repositories -- applies across multiple platforms. The researchers found thousands of exposed agent identifiers across IBM Watson X, WordPress AI, and other platforms using similar GitHub searches. Microsoft Copilot Studio has a related issue: a demo website is automatically created when any agent is built, regardless of publication settings, and external research (by Doratias) has demonstrated how these demo websites can be discovered and accessed.

Post-Access Exploitation. Once an agent is accessible, extracting sensitive data is straightforward. Prompt-based discovery reveals the agent's tools, knowledge bases, connected data sources, and even other linked agents. The agent will often return document content and direct links to source materials, even when the attacker cannot access those links directly. Beyond data exfiltration, exposed agents face denial-of-service and denial-of-wallet risks, as agents that scale automatically can be driven to excessive resource consumption.

Technical Deep Dive

▶ Watch: Bypassing allowed domains restriction via /etc/hosts spoofing (12:00)

The Vertex AI agent access model has three configurations:

1. Anonymous access: No authentication required. Intended for customer-facing agents on public websites.
2. Hybrid model: Agent is anonymous but embedded on an authenticated website. The website authentication is assumed to provide access control, but this is a false assumption -- the agent itself remains unprotected.
3. Authenticated API (OAuth/JWT): Every interaction requires authentication. This is the recommended best practice.

For Vertex AI search agents specifically, even with anonymous API configured, the platform enforces an allowed domains list. The domain validation appears to check the referrer or origin of the request against the allow list. The bypass works because:

1. The attacker identifies the likely allowed domain from the same repository where the agent snippet was found
2. The attacker maps that domain to 127.0.0.1 in /etc/hosts
3. The attacker hosts the agent HTML snippet on a local HTTP server
4. The browser navigates to the spoofed domain, which resolves locally
5. The request to Vertex AI carries the spoofed domain as the referrer/origin
6. Vertex AI accepts the request because the domain matches the allow list

Standard Burp Suite header manipulation (replacing the Referer header) did not work -- Google performs some validation beyond simple header checking. The hosts file approach succeeds because the browser genuinely believes it is on the allowed domain.

Google's response was that allowed domains is not treated as a security control. Their documentation states that setting public access allows anyone to access the agent. The allowed domains feature is described as a convenience layer, not a security boundary -- similar to Microsoft's characterization of the SharePoint pre-auth feature as a "guard rail" in the fcs25-021 talk.

Demo / Proof of Concept

▶ Watch: Post-access exploitation: prompting agents to reveal tools and knowledge bases (14:00)

The researchers demonstrated the full attack chain through a pre-recorded walkthrough: creating agents in Vertex AI, finding HTML snippets on GitHub, copying snippets into a local HTML editor to access anonymous agents, modifying /etc/hosts to bypass allowed domain restrictions for search agents, and extracting sensitive data by prompting agents to reveal their knowledge bases and connected data sources.

Defensive Implications

▶ Watch: Mitigations: treat agent IDs as secrets, enforce OAuth, maintain agent inventory (18:00)

Organizations deploying AI agents should implement the following controls:

1. Use authenticated API (OAuth/JWT) for all agents -- anonymous access should be avoided for any agent connected to internal or sensitive data
2. Treat agent identifiers as secrets: include Vertex AI, Copilot Studio, Watson X, and other platform HTML snippet patterns in secret scanning pipelines to prevent identifier exposure in public repositories
3. Maintain an inventory of all deployed AI agents, including what data sources they access and what platform they run on -- the no-code nature of these platforms means agents can be created by anyone in the organization without security team awareness
4. Enforce platform-level policies where available to prevent creation of unauthenticated agents (e.g., admin-level settings in Vertex AI to disable anonymous API mode)
5. Implement rate limiting and usage monitoring to mitigate denial-of-wallet attacks against exposed agents
6. Educate all users -- not just developers -- since no-code platforms enable non-technical employees to deploy agents that may inadvertently expose organizational data

Key Takeaways

• AI agent platforms embed agents via HTML snippets with static identifiers that require no authentication -- these identifiers are widely exposed in public GitHub repositories
• Hundreds of agent identifiers were found on GitHub for Vertex AI alone, with thousands more across other platforms -- many providing direct access to sensitive organizational data
• Vertex AI's allowed domains restriction for search agents can be bypassed with a simple /etc/hosts modification -- Google does not consider it a security control
• The hybrid model (anonymous agent on an authenticated website) provides a false sense of security -- website authentication does not protect the agent itself
• No-code agent platforms enable non-technical employees to deploy data-connected agents without security review, creating shadow AI infrastructure
• Agent identifiers should be treated as secrets and included in repository scanning pipelines

About the Speaker(s)

Michael Katchinskiy and Hagai Kestenberg are security researchers on the Microsoft Defender for Cloud Research team. Their work focuses on cloud-native security, Kubernetes threat protection, and AI security. They presented remotely and were unable to attend the conference in person.