Agent oversight: approvals, constraints and tool-access controls

Agents can call tools and take real-world actions, so beyond content filtering you need controls over which tools they may call, who approves a call and what credentials they use. These settings live on the tools and guardrails in Foundry Agent Service.

MCP tool approval and allowed tools

MCP tool approval (Foundry Agent Service mcp tool): require_approval defaults to always. You can also set it to never, {"never": [tools]} (listed tools skip approval) or {"always": [tools]} (only listed tools need approval).
When approval is needed, the response contains an mcp_approval_request item with the tool name and arguments. The app replies with previous_response_id and approve: true (or rejects the call).
allowed_tools restricts which tools on an MCP server the agent may call. If you leave it out, every tool on the server is allowed.

Toolbox with a hosted agent

Each tools/list entry carries _meta.tool_configuration.require_approval. The toolbox MCP endpoint does not block tools/call, so your agent runtime must pause, show the tool and arguments, and resume or reject that exact call.
A system-prompt instruction alone doesn’t enforce approval. Use never unless your runtime can do this.

Common trap: Assuming require_approval: always on a toolbox tool stops the call server-side - the toolbox endpoint still executes the call unless your agent runtime enforces the approval.

Credentials and identity

Keep downstream API keys and OAuth tokens on the project connection the tool references, never in agent code.
The agent reaches the toolbox with its Microsoft Entra ID (Azure AD) identity (scope https://ai.azure.com/.default). A per-agent identity keeps the tool’s permissions scoped to that agent (least privilege).

Guardrail controls on actions

Tool call and tool response intervention points (preview) scan what the agent sends to, and receives from, supported tools: Azure AI Search, Azure Functions, OpenAPI, SharePoint grounding, Fabric data agent, Bing grounding and Bing Custom Search, and Browser Automation. They have no effect on other tools. Each intervention point adds roughly 50–100 ms of latency.
Guided guardrail setup (preview) builds controls from how you describe the agent:
- If the agent calls external tools, it adds tool-response validation and spotlighting.
- If it takes real-world actions, it adds task adherence and action validation.
- If it writes or runs code, it adds protected-material and code-safety controls.
Network egress controls (preview, hosted agents only) in the same guardrail limit which destinations the agent can connect to.
Workflow oversight: a human-in-the-loop node (Ask a question) pauses a Foundry workflow until a person answers.

More AI-103 study notes

Guardrails in Microsoft Foundry: intervention points, Prompt Shields and actions
Where guardrails check an agent run, what Prompt Shields catch, and when to block or annotate.
Choosing agent tools in Foundry Agent Service
File search, Azure AI Search, Bing grounding, function, OpenAPI, MCP and code interpreter tools compared.
Prompt engineering techniques for Azure AI apps
System messages, few-shot examples, chain of thought and grounding, and which fix suits which prompt problem.
Azure AI Search indexers, skillsets and the knowledge store
The indexer pipeline stages, built-in and custom skills, and knowledge store projections.
Vector, hybrid and semantic search in Azure AI Search
Vector fields and profiles, HNSW vs exhaustive KNN, hybrid queries with RRF, and the semantic ranker.
Azure Content Understanding: analyzers, modes and structured output
Prebuilt and custom analyzers, field extraction methods and Markdown output for RAG.
Video generation with Sora 2 in Microsoft Foundry
What Sora 2 can generate, its parameters and limits, and how the asynchronous jobs work.