.NET: [Bug]: Foundry Toolbox granular require_approval object is treated as unsupported, so every tool requires approval #10097

Observed Behavior

A Foundry Toolbox version can store a granular approval policy for one MCP tool entry, where require_approval is an object with per-tool-name lists instead of the string always/never. The Foundry service accepts and returns it unchanged. FoundryToolboxService only understands the two string values, so for such a version every tool exposed by that entry requires approval, including the ones listed under never.

Toolbox version as returned by the service (azd ai toolbox show <toolbox> --version 3 --output json, names sanitized):

{
  "type": "mcp",
  "server_label": "my-mcp-server",
  "project_connection_id": "my-mcp-connection",
  "require_approval": {
    "always": { "tool_names": ["create_item", "delete_item"] },
    "never":  { "tool_names": ["get_items", "get_item_details"] }
  }
}

With that version set as the toolbox default_version, a read tool listed under never still pauses for approval in the caller (approval prompt shown for my-mcp-server___get_items).

The cause appears to be the approval check in dotnet/src/Microsoft.Agents.AI.Foundry.Hosting/FoundryToolboxService.cs, introduced by #9662. It reads _meta.tool_configuration.require_approval of each discovered tool and returns true/false only for the string values "always"/"never". Any other shape, including an object, falls through to the last branch, which logs "has an unsupported approval configuration; requiring approval for every call" and returns true.

Expected Behavior

Either of these would be reasonable, and I would like the maintainers' preference:

1. The framework honors the granular form: a tool whose name is listed under never runs without approval, a tool listed under always requires approval, and a tool listed in neither keeps the safe default of requiring approval.
2. If the granular form is not meant to be supported on the client, the supported contract is documented, so users know the service can store a policy the .NET hosting layer cannot apply.

The Microsoft Learn toolbox pages document only the strings always and never for require_approval, but the Foundry portal's MCP tool configuration exposes "Always auto-approve specific tools" with a list of tools that don't require approval, which maps to the stored object form above.

Steps to Reproduce

1. Create a toolbox with one MCP tool entry backed by an MCP server that exposes both read and write tools.
2. Create a new toolbox version through the REST create-version call (POST .../toolboxes/{name}/versions?api-version=v1) whose single MCP tool entry has the object-form require_approval shown above. The service accepts it.
3. Promote that version with azd ai toolbox publish <toolbox> <version>.
4. Run a .NET hosted agent that registers the toolbox with AddFoundryToolboxes, and ask it to call a read tool listed under never.
5. Observe an approval request for the read tool.

Minimal Reproduction

var builder = AgentHost.CreateBuilder(args);
// toolbox name comes from the TOOLBOX_NAME environment variable;
// FOUNDRY_PROJECT_ENDPOINT points at the Foundry project
builder.WebApplicationBuilder.AddFoundryResponses(agent);

The agent only registers the toolbox (AddFoundryToolboxes) and has no custom approval middleware. The reproduction depends on the toolbox version stored in Foundry, not on agent code, so there is no smaller standalone sample. A unit-level reproduction would be a toolbox MCP server whose tools/list returns {"tool_configuration":{"require_approval":{"never":{"tool_names":["get_items"]}}}} in a tool's _meta, next to the string cases already covered in FoundryToolboxApprovalTests.cs.

Error Messages and Stack Traces

No exception. The behavior comes from the final branch of the approval check, whose warning text in the source is:

Tool '{ToolName}' in toolbox '{ToolboxName}' has an unsupported approval configuration; requiring approval for every call.

Package Versions

Microsoft.Agents.AI.Foundry: 1.27.0-preview.261030.1, Microsoft.Agents.AI.Foundry.Hosting: 1.27.0-preview.261030.1, Microsoft.Agents.AI.Abstractions: 1.27.0

.NET Version

.NET 10.0

Operating System

Windows

Regression

Unknown

Additional Context

• Before .NET: Apply toolbox tool approval configuration #9662 the toolbox approval metadata was not applied at all, so this is not a regression of a previously working feature, only a gap in what .NET: Apply toolbox tool approval configuration #9662 recognizes. I did not test an earlier package version.
• I could not confirm what the service puts in each tool's _meta.tool_configuration.require_approval in tools/list for such a version (the service-side stored shape above is confirmed). If the service copies the whole object into every tool's _meta, the framework cannot tell which tools are exempt without parsing the object; if it resolved the policy to a per-tool string, this issue would not occur.
• A workaround that works today with the string contract: keep require_approval as "always" and add UseToolApproval AutoApprovalRules that approve the read tools by name.
• Related: .NET: Apply toolbox tool approval configuration #9662 (introduced the approval handling), .NET: Preserve MCP execution contracts in Foundry hosting #10007 (open, touches the toolbox approval client).

Acknowledgements

• I searched existing issues and did not find a duplicate.
• I personally verified this behavior and the reproduction details are authentic.
• I will wait for explicit maintainer agreement before starting implementation of a non-trivial change.