.NET: [Feature]: provide an official sandbox abstraction for command/tool execution

[soul-soft]

Proposal: sandboxed command execution to reduce approval fatigue

Summary

I would like to suggest adding an official sandbox abstraction for command/tool execution.

This is a practical pattern. DSH uses this direction, and local experiments show that it can significantly reduce approval frequency: run commands in a restricted sandbox by default, and only ask the user for approval when the command needs to exceed the sandbox policy.

Why

For coding agents and local automation, asking the user to approve every command is too noisy. Many commands are safe if they are constrained:

• read-only commands
• commands that only write inside the workspace
• commands that cannot modify files outside the workspace
• commands whose child processes are killed with the run

When a command is blocked by the sandbox, the tool can return a structured restriction result. The agent can then ask for a scoped elevation, such as retrying this one command with broader permissions.

This gives a better flow:

1. Run safely by default.
2. Avoid approval for normal safe operations.
3. Ask for approval only when sandbox limits are hit.
4. Keep elevation explicit and scoped.

Windows reference

On Windows, one possible implementation is based on OS security primitives:

• restricted token
• restricting/capability SIDs
• workspace ACL grants
• private temp directory grants
• Job Object cleanup

This approach is worth referencing because it is not just command-string filtering. It uses the OS permission model to enforce the boundary.

Proposal

Could MAF provide a common sandbox contract that command tools can use?

For example:

public interface IAgentCommandSandbox
{
    Task<SandboxResult> RunAsync(
        CommandRequest request,
        SandboxPolicy policy,
        CancellationToken cancellationToken);
}

MAF could provide a default implementation or sample implementation, while still allowing developers to plug in their own backend: Windows restricted token, container, remote executor, enterprise policy service, etc.

This could work well with AIContextProvider and ToolApprovalAgent: the provider exposes command tools with the current request/workspace policy, and approval is only needed when the sandbox reports that elevation is required.

Questions

• Is this kind of sandbox abstraction in scope for MAF?
• Could MAF provide an official contract, even if platform implementations remain pluggable?
• Should sandbox restriction results integrate with tool approval so agents can request scoped elevation?

I think this would satisfy many local-agent use cases by reducing repeated approvals while still keeping risky actions explicit.