Copilot Studio agent sandbox keeps external actions governed
Diesen Beitrag auf Deutsch lesen
Copilot Studio agents run code in a temporary sandbox with no network egress. Knowledge and configured Tools are the only external paths.
TL;DR
Copilot Studio agents using the GitHub Copilot harness run Python and shell work in a managed, temporary container. The sandbox has no outbound network access, so API calls, email, and SharePoint writes cannot leave it. External access occurs only through configured Knowledge sources and Tools, which remain subject to governance controls and data policies.
Original by Chris Garty, on The Custom Engine. Read the original
This is our own summary, not a republication or full translation.
Governance takeaway
- Makers: Use reviewed Skill scripts for repeatable file or calculation work, while allowing generated code for novel tasks.
- Admins/CoE: Configure Knowledge and Tools deliberately because they are the only routes for agent access beyond the sandbox.
- Security/Compliance: Treat the lack of sandbox network egress as a boundary, then govern configured external paths through data policies.
- Leadership/Business: Do not rely on sandbox files as storage because the work area is temporary and outputs must be returned or saved through a configured Tool.
Frequently asked questions
Can Copilot Studio agent sandbox code call an API or send email?
No. The sandbox has no outbound network route, so external API calls and email cannot leave the environment.
How do Copilot Studio agents access external data from the sandbox?
They use configured Knowledge sources for grounded information and Tools such as connectors or MCP servers for live data and actions.
Where should a Copilot Studio sandbox file be saved for later use?
Return the file to the user or save it through a configured Tool. Sandbox storage does not persist across conversations.