Clarify validation before tool approval

[Trym Håkansson (trymhaak)]

Summary

Clarify that human approval is scoped to the exact tool call in the approval request.

The added note tells readers to:

• validate the requested function name and arguments against the application's allowlist and current authorization policy;
• require a new approval if the tool call changes.

This keeps the guidance next to the existing description of ToolApprovalRequestContent / function_approval_request without changing any language-specific API examples.

Validation

• confirmed the target paragraph occurs exactly once on current upstream main
• git diff --check passes
• change is limited to one three-line Microsoft Learn callout

[learn-build-service-prod]

Learn Build status updates of commit d7b337d:

✅ Validation status: passed

File	Status	Preview URL	Details
agent-framework/workflows/human-in-the-loop.md	✅Succeeded

For more details, please refer to the build report.

[learn-build-service-prod]

Learn Build status updates of commit aee5703:

✅ Validation status: passed

File	Status	Preview URL	Details
agent-framework/workflows/human-in-the-loop.md	✅Succeeded

For more details, please refer to the build report.

[westey (westey-m)]

Before sending an approval response, validate the requested function name and arguments against the application's allowlist and current authorization policy

I'm not sure about this advice. After all, the application really shouldn't advertise functions that are against the application's allowlist in the first place. That seems like more sensible advice, since it wouldn't result in unnecessary of tools for approval, that cannot be executed anyway.

Doing additional validation against the arguments may make sense though, but mostly if validation couldn't happen in the funciton tool itself.