Enterprise data agents now need three separate control planes: identity, egress and tool scope

Three enterprise agent releases from Microsoft, Databricks and Snowflake point to the same operational lesson: granting access to an agent is no longer one decision. Platform teams must review whose identity executes, where request content travels, and which actions the client can discover as separate control planes.

Identity: who does the query run as?

Microsoft’s Fabric Data Agent integration with Copilot Studio makes the identity choice explicit. In User mode, the person chatting with the agent must have access to the Fabric data agent and its underlying sources. In Maker mode, calls use the credentials of the person who configured the Copilot Studio agent, so consumers see data through that maker’s access. Microsoft also warns that returned responses may leave Fabric’s compliance boundary or geographic region and then fall under Copilot Studio’s handling policies. Those are two different reviews: delegation and data movement. Microsoft’s implementation guide documents both choices.

A practical release gate is to write down the full principal chain: end user, orchestrating agent, connector or maker identity, data agent and underlying source. If the chain changes between environments, authorization tests must change with it.

Egress: what content leaves the platform?

Databricks’ external service policies add third-party guardrails to model and MCP traffic, but the guardrail itself becomes an egress path. For MCP services, Databricks can send the tool name and arguments before execution, then the tool result and originating call after execution. The vendor receives content rather than the caller’s identity. Databricks says a Unity Catalog connection stores endpoint and OAuth machine-to-machine credentials, but does not by itself restrict reachable network destinations; it recommends a restricted network policy for approved endpoints. The external-policy documentation describes the payloads, authentication and network boundary.

That means “add a DLP check” is not automatically data minimization. Teams should classify tool arguments and results, approve the destination, and test the policy first in Log mode. They should also account for fail-closed behavior: Databricks denies governed calls when the vendor times out, errors or returns an invalid verdict.

Tool scope: what can the client discover and invoke?

Snowflake’s Cortex Tools controls which MCP capabilities reach clients such as ChatGPT, Claude, Cursor and CoCo. Disabled tools are hidden and cannot be invoked—but Snowflake says that if administrators do not configure tool availability, all tools are available by default. Policies can allow specific tools, all currently published tools, or all current and future tools. Snowflake’s tool-policy guide defines those modes, while the Cortex Tools overview separates gateway access from end-user authorization with the third-party service.

The shared rollout model is therefore a three-column register for every agent connection: execution identity, content destinations, and allowed tools. Test each independently. A least-privilege identity cannot compensate for unrestricted egress; a restricted endpoint cannot compensate for write and delete tools; and a narrow tool list cannot fix a shared maker credential that exposes more data than the user should see.