Pull request overview

This PR strengthens defense-in-depth guidance around tool auto-approval by documenting that several built-in auto-approval rules rely on tool names, and that name collisions can silently bypass the intended human-approval boundary (notably for configurable-name tools like the Harness shell tool).

Changes:

• Expanded XML docs for built-in provider auto-approval rules (skills + file access) to enumerate the approved tool names and highlight collision risk.
• Added security warnings to tool-approval configuration and to shell-tool naming surfaces (AsAIFunction(...), ShellToolName) to discourage name collisions.
• Updated relevant .NET samples to call out the same collision hazard when using read-only auto-approval rules.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 5 comments.

Automated Code Review

Reviewers: 5 | Confidence: 85%

✓ Correctness

This PR adds documentation warnings about tool-name collision risks in auto-approval rules. All changes are XML doc comments, README additions, and no code logic is modified. The documented tool names and set memberships are verified to be accurate against the actual source constants and HashSet definitions.

✓ Security Reliability

This PR is purely a documentation change adding security warnings about tool-name collisions in auto-approval rules. All documented claims (tool names, matching behavior, and rule semantics) have been verified against the actual source code and are accurate. The warnings correctly describe a real defense-in-depth concern: auto-approval rules match solely by tool name, so a configurable-name tool (like the shell executor) could inadvertently be auto-approved if assigned a colliding name. No code logic is changed, no new vulnerabilities are introduced, and the documentation accurately reflects the existing behavior.

✓ Test Coverage

This PR is entirely a documentation change — adding XML doc comments and README security warnings about tool-name collisions in auto-approval rules. No runtime code was modified. The existing test suite already verifies the name-based matching behavior (approving known names, rejecting unknown ones) that these warnings document. No new test coverage is needed for documentation-only changes.

✓ Failure Modes

This PR adds only documentation: XML doc comments and README warnings about tool-name collision risks in auto-approval rules. There are no functional code changes — no new logic, no modified behavior, no altered control flow. No failure modes are introduced or preserved by this diff.

✓ Design Approach

The PR’s overall direction is sound, but one of the new central API warnings overstates how auto-approval works. ToolApprovalAgentOptions.AutoApprovalRules accepts arbitrary predicates over FunctionCallContent, so documenting the feature as inherently name-only misdescribes the design and may steer users away from safer argument-aware rules. I did not find a code-path or test-backed reason to request changes beyond tightening that wording.

Suggestions

• In dotnet/src/Microsoft.Agents.AI/Harness/ToolApproval/ToolApprovalAgentOptions.cs:44-48, scope the warning to the built-in name-based rules rather than all AutoApprovalRules, because the contract at ToolApprovalAgentOptions.cs:34-36 allows rules to inspect the full FunctionCallContent, and ToolApprovalAgent.AllToolsAutoApprovalRule is explicitly name-agnostic at ToolApprovalAgent.cs:95-96.

Automated review by westey-m's agents