Yes. The question can Microsoft Foundry agents expose data through tools or code execution has a direct answer: a Foundry agent can move sensitive data through tool calls, code interpreter sessions, Model Context Protocol (MCP) connections, and agent-to-agent handoffs. For enterprises, the main risk is unreviewed data movement across those execution layers. Security teams need interaction-level controls on every agent action before it fires. Aurascape inspects and enforces policy on each tool call in full conversation context.

Last updated: July 2026.

The thesis: data exposure in Foundry agents happens at the execution moment, not the network edge, so governance has to inspect and enforce policy on every agent-to-tool action, not just the initial prompt or the login. Microsoft Azure AI Foundry builds, deploys, and runs AI agents that reason, retrieve data, call tools, and take actions (Microsoft, 2026). Those same capabilities define the exposure surface.

How Foundry Agents Move Data Through Tools and Retrieval

A Foundry agent earns its value by reaching outside the model. It calls external APIs, queries knowledge stores, connects to tools, and retrieves documents to finish a task. Each connection carries data in and pulls data out. When an agent passes a customer record to a summarization tool or sends a repository snippet to an external service, that content leaves the model boundary and enters another system with its own retention and logging behavior.

The exposure path is concrete. An agent can pass sensitive context to a tool approved for one task but manipulated for another. The tool call is the control point. It fires after authentication, inside an application session that destination-focused controls may not decode at the interaction layer.

Prompt injection amplifies this. OWASP ranks Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), and Excessive Agency (LLM06) among the top risks for applications built on large language models (OWASP, 2025). Foundry agents often use retrieval-augmented generation (RAG): they query a knowledge base, receive retrieved content, and fold it into reasoning before calling a tool. That retrieved content is an injection surface. Indirect prompt injection via retrieved documents means malicious instructions embedded in a retrieved file, web page, search result, or database record are processed as agent input. The agent then forwards data to a destination or takes an action that was never part of the original task. Because the injection arrives through a sanctioned retrieval channel, it slips past filters that screen direct user prompts. A perimeter control may record the connection, but it usually does not evaluate whether the agent’s tool action matches the user, task, data, and intended outcome. The control that closes this layer evaluates the intended tool call in context before it fires.

Code Interpreter Sessions, Data Boundaries, and Retention

Foundry runs generated code in a hosted runtime through a code interpreter capability. Sandbox isolation limits process escape, but it does not govern what data enters the runtime, what transformations the generated code applies, or what leaves as output. Code execution risk runs both directions: uploaded files, generated code, intermediate files, transformed datasets, and returned artifacts are all data-handling events. Any of them can carry proprietary and confidential data past the intended boundary.

Take a concrete source code scenario. A Foundry agent retrieves a repository snippet from a connected store, sends it to a code interpreter to generate a build artifact, then calls an external ticketing or storage tool to file the result. Proprietary code and any secrets inside it traverse three surfaces in one task: the retrieval channel, the runtime, and the outbound tool call. A hard-coded credential riding along in the snippet reaches the external tool unless the payload is classified and the sensitive value redacted before the call executes.

Data retention deserves the same scrutiny. Prompts, tool payloads, retrieved documents, code interpreter inputs and outputs, and connected-service responses may each land in different systems with different retention windows. Architects should audit each data-handling surface in their own deployment and not assume a single policy covers the full execution chain.

MCP Connections, Identity Scopes, and Multi-Agent Propagation

Foundry agents connect to tools over MCP. MCP is one common tool-execution pattern, not the entire agent access-control problem, but it widens the trust surface fast. Censys found more than 12,520 internet-accessible MCP services, mostly unauthenticated, and the protocol does not require authentication by default (Censys, 2026). An orchestrator that trusts an MCP server implicitly inherits whatever that server does with the data it receives. When an agent decides to call a tool, a tool description it reads at runtime drives that decision. A manipulated description can redirect agent behavior without changing any platform permission or network rule.

Identity sits underneath all of this. Microsoft Entra authentication establishes which agent or workload can reach Azure resources. Runtime policy determines whether a specific tool call should use that access for this task, with this data, at this moment. Least privilege for AI agents means granting each agent only the data access, tool set, and action scope a specific task requires, and enforcing that boundary the moment the tool call fires, not only at enrollment. An overprivileged scope hands broad reach to every downstream action.

Multi-agent designs raise the stakes. Human-to-agent delegation is one relationship: a person hands work to an agent. Orchestrator-to-subagent propagation is another: when an orchestrator hands a subtask to a subagent, context flows along the chain, and a subagent with a narrow purpose can still receive sensitive input, then pass it to a tool the security team never mapped to it. The Cloud Security Alliance found that 82% of organizations have unknown AI agents in their environments (Cloud Security Alliance, 2026). Shadow Foundry deployments and unregistered agent connections make that propagation path hard to reconstruct during audit or production review.

Responsible AI Content Filtering Versus Security-Layer Data Control

These two controls solve different problems, and conflating them leaves a gap. Responsible AI content filtering evaluates whether generated content is harmful, disallowed, or unsafe: hate, violence, self-harm, and similar categories. It does not classify whether a customer record, a source file, a credential, or a regulated field sits in a prompt, a tool payload, a code interpreter output, or a generated artifact.

AI data loss prevention (DLP) and runtime policy answer the second question. They classify enterprise data as it moves through each interaction and apply a decision to it. A content safety filter can pass a response that is perfectly safe by harm standards while that same response carries a block of proprietary code to an external tool. Security teams need both layers: content safety for harmful output, and data classification with enforcement for sensitive enterprise data in every payload the agent handles.

What Platform Logs Capture Versus Interaction-Layer Evidence

Infrastructure and platform logs record resource and request events, and they carry useful security signal. Compliance teams also need a different evidence layer: a record of what data each agent handled at the interaction layer, per action, per tool, per policy decision. The required chain of custody maps directly to the agentic execution sequence:

ISACA reports that 90% say employees use AI tools, but only 38% have a formal, comprehensive AI policy and 25% have none (ISACA, 2026). Policy without an enforceable, per-interaction record is hard to prove and harder to defend in an audit.

A Deployment Sequence for Governing Foundry Agent Risk

Runtime policy for Foundry agents means applying data classification and enforcement at each interaction point in the agent’s execution path, not only at login or the network edge. This sequence gives Azure architects, AI developers, and security teams a practical operating model for assessing Foundry deployments before and during runtime.

1. Inventory agents and connections. Discover every Foundry agent deployment, including shadow and unregistered instances, across network, endpoint, and API planes. Proactive discovery finds tools and agent connections before they surface in an audit.
2. Map identities and scopes. For each Foundry agent, document the connected tools, API permissions, retrieval sources, code interpreter access, and downstream services that can receive agent output. Find overprivileged scopes and cut them to the minimum each task requires.
3. Approve and sign tool connections. For each tool and MCP server the agent can invoke, decide whether the connection is sanctioned. Sign approved tool calls cryptographically; configure the enforcement point to block unsigned ones at the circuit-breaker layer.
4. Set code interpreter data boundaries. Define which data classifications may enter a code interpreter session, which artifacts may leave as output, and which downstream agents may receive that output. Redact sensitive rows, fields, or embedded secrets inline before they propagate.
5. Screen retrieval sources for injection risk. For each knowledge base, document store, or external search source the agent retrieves from, judge whether retrieved content could carry injected instructions, then inspect the intended tool call after retrieval, in context.
6. Configure runtime policy actions. For each data type and tool combination, set the action: allow, coach, warn, block, or redact. Apply these at the tool call layer, not only at the session boundary.
7. Verify the audit record. After the first test run, confirm the interaction record reconstructs the full execution path. If any link is missing, treat that gap as a compliance exposure before moving to production.

How Aurascape Governs Foundry Agents at Runtime

For a Foundry deployment, the data-exposure decisions land while the agent runs. Aurascape operates there. Aurascape discovers and secures local AI agents and their interactions, and adds a Zero-Bypass MCP Gateway that cryptographically signs approved tool calls and blocks unsigned ones, governing the agent-to-tool execution path inline rather than observing it (Aurascape, 2026). Aurascape applies 600+ real-time data classifiers to inspect the content moving through each interaction and enforces context-aware policy actions across the sequence (Aurascape, 2026). At the tool call layer, a code interpreter output carrying sensitive rows gets redacted before it reaches a downstream agent, and an unsigned MCP call to an unmapped server gets blocked the moment it fires.

Proactive discovery finds shadow AI apps, unregistered agent connections, and unmanaged Foundry deployments, so security teams hold a complete asset inventory. The result: an interaction-layer record of every agent action, tool invocation, and data exchange, governed by role-based access control (RBAC) for privacy, which supplies the forensic chain infrastructure logs alone do not.

The business case follows the evidence. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value, or inadequate risk controls (Gartner, 2025). Teams with interaction-level evidence approve agent use on clearer controls and audit proof instead of static policy alone. The EU AI Act sets obligations for high-risk AI systems that include logging, human oversight, and traceability of system behavior (EU AI Act, 2024). Traceability means reconstructing which data an agent handled and what it did with it, per interaction. Aurascape is additive to an existing SSE, SASE, CASB, DLP, or SWG stack, with no rip-and-replace.

For a broader evaluation approach, see how to evaluate AI compliance tools. For related source code risk patterns, see risks of using AI tools with company source code. On governing agents in Copilot Studio, see Copilot Studio agents, DLP, and compliance policies.

Frequently Asked Questions

Where can Foundry agents expose source code or secrets?

Source code and secrets can travel through a retrieval channel into the agent, through a code interpreter runtime that transforms them, and out through a tool call to an external service. A hard-coded credential inside a retrieved snippet reaches that external tool unless the payload is classified and the sensitive value redacted at the interaction layer before the call runs.

Does the code interpreter sandbox prevent data loss in Foundry?

Isolation limits process escape, but it does not decide what data enters the runtime or leaves as output. Generated code and returned artifacts remain data-handling events. Classifying those payloads and enforcing a policy action on them is a separate control the sandbox does not provide.

How does indirect prompt injection cause data exposure in Foundry agents?

Instructions hidden in a retrieved document, search result, or knowledge-base entry are processed as trusted agent input, so the agent takes an action the injected text directed. Because the text arrives through a sanctioned channel, direct-prompt filters miss it. Defense in depth helps, anchored by runtime enforcement that inspects the intended tool action in context.

How do Microsoft Entra identities relate to Foundry data exposure?

Microsoft Entra authentication establishes which agent or workload can reach a given Azure resource. That answers access, not appropriateness. Runtime policy still decides whether a specific tool call should use that access for this task, with this data, at this moment, which is where data exposure is actually governed.

Are MCP connections a data-loss risk for Foundry?

They can be. Most internet-accessible MCP services are unauthenticated, and the protocol does not require authentication by default. An agent that trusts a compromised or manipulated server can send sensitive data to an unintended destination. Signing approved tool calls and dropping unsigned ones removes implicit trust at that execution point.

What evidence do platform logs miss in an agentic audit?

Platform logs give useful resource and request signal. They typically do not record the data content passed to a tool, what the tool returned, whether a retrieved document carried injected instructions, or which policy decision applied at the interaction layer. An interaction-layer record fills those gaps for compliance evidence.

How does Aurascape govern Foundry agents at runtime?

Aurascape sits inline and inspects each agent-to-tool interaction in context, applying 600+ real-time data classifiers and the five policy actions (allow, coach, warn, block, redact) at the tool call layer. It discovers unregistered agents and shadow connections for a complete inventory, and it records each agent action, tool call, and data exchange under RBAC for compliance evidence.

Aurascape governs Microsoft Foundry data exposure where it happens: the tool call, the code interpreter output, the MCP connection, and the agent-to-agent handoff. With inline inspection, real-time data classification, signed tool-call enforcement, and interaction-layer audit evidence across the full execution sequence, security teams approve Foundry agent use with proof instead of blocking it wholesale.

See how Aurascape governs agent tool calls and code execution →