Sandboxes¶
Target
This page describes intended behaviour or structure. No implementation is claimed unless a section is explicitly marked Current implementation or Evidence.
Models never receive uncontrolled access to a host. Every side effect flows agent → tool request → tool gateway → policy check → approval if required → sandbox → execution, and is captured in audit traces.
Requirements¶
| Control | Requirement |
|---|---|
| Filesystem isolation | Ephemeral workspace per run or attempt; read-only mounts for inputs; no host filesystem |
| Network isolation | Explicit allow-list (for example dev.azure.com, github.com, api.nuget.org); deny by default; policy varies by tenant, project, agent, environment, tool and task |
| Resource quotas | CPU, RAM, GPU, execution timeout, process restrictions |
| Credentials | Temporary, scoped credentials injected by the secret broker; expire with the sandbox; never root shell, cloud admin credentials or production secrets |
| Implementations | Containers, microVMs, Kubernetes jobs, isolated Windows environments or restricted runners, selected per profile |
| Evidence | Every command, its arguments, duration and result are recorded in the run journal and audit trail |
Governed shell¶
| Usually low risk (execute, in sandbox) | Blocked or approval-gated |
|---|---|
dotnet restore, dotnet build, dotnet test, git diff, git status, npm test |
terraform destroy, az group delete, kubectl delete namespace, DROP DATABASE, rm -rf outside the workspace |
Classification is policy (tool policies), not a hard-coded list; the table shows the intent.
Current implementation¶
No sandbox, workspace manager, egress control or secret broker exists. The agents framework's file-skill script runner is disabled (throws NotSupportedException). The legacy ConnectSoft.SemanticKernel.Plugins.ProductManagement runs Git and dotnet processes on the host; it is evidence of needed behaviour, not an execution path to keep.