Listen to this Post
Introduction:
A seemingly innocuous feature within Microsoft’s Copilot Studio—the Dataverse searchQuery unbound action—is quietly revolutionizing how developers build AI agents, but it’s also creating a massive blind spot for security teams. This functionality allows makers to connect to external Dataverse environments and perform table searches without requiring end-user authentication, effectively creating a public-facing data interface that bypasses standard permission models. While incredibly powerful for low-code development, it introduces critical risks related to data exposure, unauthorized access, and compliance drift if not meticulously configured.
Learning Objectives:
- Understand how the Dataverse searchQuery action operates in unauthenticated scenarios within Copilot Studio.
- Identify the security implications of using maker-auth and cross-environment connections.
- Implement auditing, monitoring, and hardening techniques to prevent data leakage via AI-powered agents.
You Should Know:
- Understanding the “Hidden Gem”: Dataverse SearchQuery in Unauthenticated Scenarios
The core of this discovery lies in a functionality detailed by Microsoft’s Karima Kanji-Tajdin, which allows Copilot Studio makers to leverage the `searchQuery` unbound action against Dataverse tables. In traditional Copilot Studio setups, when a user interacts with a bot, the system runs within a security context—either the user’s identity or a system account. However, this “hidden gem” enables developers to perform searches against Dataverse tables in a manner that can be configured to require no end-user authentication at all.
The step-by-step guide to configuring this involves:
- Accessing Copilot Studio: Navigate to your bot’s topic creation area.
- Adding an Action: Instead of using standard Dataverse connectors, developers add a new action and select “Dataverse Search.”
- Selecting the Search Query Action: Within the action configuration, they choose the `searchQuery` unbound action, which is often overlooked in favor of standard list rows operations.
- Configuring the Connection: Here lies the critical security decision. The developer can specify a “Connection” for the action. By selecting a connection tied to a maker account (maker-auth) or by configuring it for unauthenticated use (a scenario common in public-facing websites or POCs), the bot effectively acts as a proxy, allowing any end-user to query data without their own identity being validated.
This is particularly powerful for scenarios where a bot needs to search across multiple environments (e.g., a production bot searching a test environment) or where the maker wants to avoid complex user authentication flows. However, from a security perspective, this transforms the bot from a simple conversational interface into an unauthenticated API endpoint. If misconfigured, an attacker can interact with the bot and perform arbitrary searches across Dataverse tables that the maker account or the unauthenticated service principal has access to.
- The Security Implications of Maker-Auth and Cross-Environment Connections
The LinkedIn comments by Henry Jammes highlight a crucial nuance: the ability to connect to a different Dataverse environment using “maker-auth.” This is a significant security divergence. Normally, bot users inherit permissions based on their own Azure Active Directory (Azure AD) identity. When a bot uses maker-auth (the credentials of the developer who built the bot), it elevates the privileges of every single user interacting with that bot to that of the developer.
This creates a privilege escalation vector. If a developer has read access to sensitive tables like “Customer Financials” or “Employee Records” in Dataverse, any user who can talk to the bot can potentially query those tables. The bot cannot differentiate between a legitimate query and a malicious one because the authentication context is static.
To audit for this misconfiguration in a tenant, security teams can use PowerShell with the Dataverse SDK or the Microsoft Graph API to inspect bot configurations. While not a direct command, the logic involves:
PowerShell (using Microsoft.PowerApps.Administration.PowerShell module):
Connect to the Power Platform admin center
Add-PowerAppsAccount
Get all bots in an environment
$bots = Get-AdminPowerApp -EnvironmentName "your-environment-id" -IncludeDisplayName | Where-Object {$_.AppType -eq "Bot"}
For each bot, you would need to inspect the bot definition (JSON) for the specific action.
This requires parsing the bot content which can be exported via the API.
The key is to look for actions where "connectionReference" is used without a user context or with a fixed service principal.
Linux/macOS (using curl with Azure CLI to query the API):
Obtain an access token az account get-access-token --resource https://api.powerapps.com --query accessToken -o tsv Use the token to query bot definitions (simplified) curl -X GET "https://api.powerapps.com/providers/Microsoft.PowerApps/apps?api-version=2016-11-01" -H "Authorization: Bearer <your_token>"
These scripts are starting points. The real audit requires examining the bot’s JSON definition for the `searchQuery` action and verifying the associated connection references to ensure they are not utilizing a shared, high-privilege user account in an unauthenticated context.
- How to Audit This Exposure Using Power Fx and Admin Tools
Given the low-code nature of Copilot Studio, the responsibility for securing these connections often falls on citizen developers, which is a recipe for disaster. Security teams must operationalize the auditing of these unauthenticated search endpoints. One method is to utilize the Power Platform Center of Excellence (CoE) Toolkit, which can extract and analyze app and bot metadata at scale.
A step-by-step guide for an automated audit:
- Install the CoE Toolkit: Deploy the Center of Excellence (CoE) Starter Kit to a dedicated Dataverse environment. This kit includes Power Apps and Power Automate flows that inventory all resources across the tenant.
- Analyze Bot Components: Within the CoE’s “Apps” table, look for records of type “Bot.” The toolkit doesn’t natively parse bot JSON, but it flags the environments and owners.
- Use the Dataverse API to Scan: For high-risk environments, use a script to iterate through all bot definitions. The key is to search for `”unboundaction”` with `”searchQuery”` and check if the `”connectionreference”` is configured with an `”authentication”` property set to `”oauth”` without a user requirement, or worse,
"none". - Review Environment Security: Cross-reference any bot found using `searchQuery` in an unauthenticated context with the environment’s security groups. Ensure that the maker’s account used for the connection has the absolute minimum permissions (read-only, scoped to specific tables) and is not a global administrator or Environment Admin.
4. Hardening and Mitigation: Restricting Dataverse Search Exposure
Once identified, securing this feature requires a layered approach that combines technical controls with policy enforcement. Developers should be forced away from using maker-auth for unauthenticated scenarios and toward using service principals (application users) with least-privilege access.
Mitigation steps:
- Create a Dedicated Service Principal: In Azure AD, create a service principal specifically for the bot’s Dataverse operations. Grant this principal a security role in Dataverse (e.g., “Basic User” or a custom role) that only has read permissions to the specific tables required for the search functionality.
- Modify the Action Connection: In Copilot Studio, edit the action using
searchQuery. Instead of selecting a connection tied to a user, add a new connection using the service principal’s client ID and secret (via the Power Platform admin center). - Restrict Data via Views: Configure the Dataverse search to use specific, filtered views. Even if the service principal has access to a table, the search query should be constrained to a view that excludes sensitive columns (e.g., salary, SSN) and rows (e.g., terminated employees).
- Implement Azure Policy: Create an Azure Policy definition for the Power Platform to audit or deny the creation of connections that are set to “unauthenticated” or that use high-privilege user accounts. This policy can be scoped to specific environments (e.g., Production) to enforce compliance.
Example of a custom Dataverse security role YAML definition (conceptual) for the service principal:
Custom Role: Bot_Search_Reader name: Bot Search Reader privileges: - privilege: prvReadAccount level: Organization Limits to org level, but can be more granular - privilege: prvReadContact level: Organization - privilege: prvReadLead level: User Limits to records owned by the bot user? Not ideal. Better to use scoping. It's critical to use column-level security to mask sensitive fields. No write, create, delete, or share privileges.
5. Exploitation and Detection: Simulating an Attack
Understanding how an attacker might exploit this misconfiguration is key to building effective detections. An attacker would likely engage the bot with simple natural language queries to map the data schema.
Simulated Attack Flow:
- Discovery: The attacker finds the public-facing Copilot Studio bot (e.g., embedded on a website).
- Reconnaissance: They ask questions like “Show me all customers,” “List employees,” or “What is the latest order?”
- Data Exfiltration: If the bot is configured with `searchQuery` and maker-auth, the attacker could pivot to asking, “Find all records where city is ‘New York’ and show me email addresses,” effectively using the bot as a search engine for sensitive data.
- Schema Mapping: If the bot returns errors when querying non-existent tables, the attacker can infer the underlying Dataverse schema.
Detection via Log Analytics:
Microsoft 365 Defender and Power Platform logs can be used to detect anomalous search behavior. Configure alerts for:
– High Volume of Searches: If a bot’s `searchQuery` action is invoked hundreds of times by a single user session (or anonymous IP) within a short period.
– Anomalous Search Terms: Monitor for searches containing SQL-like syntax (e.g., SELECT, WHERE, OR) or terms that deviate from typical conversational patterns.
– Cross-Environment Queries: An alert when a bot accesses a Dataverse environment that is not the primary environment associated with its standard operations.
KQL Query for Microsoft 365 Defender:
// Query for Copilot Studio action executions PowerPlatformDataverseActivity | where OperationName == "ExecuteAction" | where ActionName == "searchQuery" // The specific unbound action | extend BotName = tostring(AdditionalProperties.botName) | extend UserAgent = tostring(AdditionalProperties.userAgent) | where UserAgent contains "CopilotStudio" or UserAgent contains "Bot" | summarize RequestCount = count() by BotName, UserId, ClientIp, bin(TimeGenerated, 1h) | where RequestCount > 50 // Threshold for potential scraping
What Undercode Say:
- Data Exposure is a Configuration Problem: The `searchQuery` unbound action itself is not a vulnerability; it’s a powerful feature. The risk lies entirely in its misconfiguration—specifically the use of maker-auth in unauthenticated bot scenarios.
- The Rise of AI as a Security Perimeter: AI agents like Copilot Studio bots are becoming the new “public API.” Traditional security models that focus on UI access or direct API calls are insufficient. Security teams must extend their governance to include bot definitions, action connections, and service principal permissions.
- Auditability Must Be Low-Code, Too: The explosion of low-code development requires low-code security tooling. Organizations must invest in the CoE Toolkit and automated pipelines to inspect bot configurations at scale, moving beyond manual reviews that are unsustainable in a citizen developer ecosystem.
Prediction:
The convergence of generative AI with low-code platforms will dramatically accelerate the “shadow API” problem. Within 18 months, we will see the first major data breach attributed to a misconfigured Dataverse search action in a production Copilot Studio bot. This will force Microsoft and other vendors to implement “security defaults” for AI agents—such as mandatory approval workflows for cross-environment connections and automatic audit logs for all unauthenticated actions—turning what is currently a hidden gem into a tightly controlled, high-friction feature for developers.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Adilei Copilotstudio – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
