Configure Azure AI Foundry agents and function calling

1. Choose a supported agent architecture

For Azure Government, Microsoft currently documents prompt agents, function calling, Azure AI Search, and several other tools as available. Hosted agents, web search, Grounding with Bing, and browser automation are listed as unavailable; workflows are listed as Preview. Availability alone does not establish inclusion in the authorization package.

Two patterns are useful: a managed prompt agent with approved tools and state storage, or an application-hosted orchestration loop on an approved runtime calling an approved model. The second pattern is not the managed Foundry “hosted agents” feature and has its own runtime controls.

Record each selected capability’s release status and data behavior. Omit unapproved preview features and external tools. A commercial tutorial that adds web browsing or a model from the broader catalog is not a Government authorization design.

2. Configure state, networking, and permissions before use

Microsoft’s Standard setup uses customer-managed Storage for files, Search for vector data, and Cosmos DB for conversation and agent state. Match the runtime generation to the documented setup and container layout; current and classic runtimes use different stores. Confirm that the selected setup is supported in your target cloud.

Provision private endpoints for those stores, configure the supported outbound networking at resource creation, and grant the project/runtime identity only its documented data-plane roles. Deployment caller permissions and runtime permissions are separate. Current capability-settings documentation includes preview APIs; do not treat a preview provisioning path as approved simply because a sample compiles.

Define conversation retention, file retention, deletion, backup, and review access. Deleting an agent definition alone does not prove that conversations, uploaded files, traces, or backing-store records have been deleted.

3. Configure a Government project client correctly

The current Government SDK documentation requires azure-ai-projects 2.0.0 or later and uses a Government project endpoint with an explicit scope. This connection excerpt uses a deterministic system-assigned managed identity; use an approved workload identity if the runtime does not support managed identity.

import os
from azure.identity import ManagedIdentityCredential, get_bearer_token_provider
from azure.ai.projects import AIProjectClient

scope = "https://ai.azure.us/.default"
with ManagedIdentityCredential() as credential:
    with AIProjectClient(
        endpoint=os.environ["APPROVED_FOUNDRY_PROJECT_ENDPOINT"],
        credential=credential,
        credential_scopes=[scope],
    ) as project:
        token_provider = get_bearer_token_provider(credential, scope)
        with project.get_openai_client(api_key=token_provider) as client:
            # Use the approved API and deployment for a synthetic acceptance request.
            # Provision agents/conversations only after package and retention review.
            pass

View the Government synthetic inference check on GitHub for a runnable model request after networking, identity, and package approval. It requires a deployed model supporting the selected Responses parameters and can incur token charges. The store=False setting does not disable provider abuse monitoring or guarantee zero retention.

The reviewed direct dependency versions were checked for client initialization; resolve and pin transitive packages through your approved release process.

python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
# Set approved project/deployment and managed-identity configuration in your runtime.
.venv/bin/python government_client.py

The excerpt above is an authentication connection pattern, not an end-to-end deployment. Pin and review SDK versions with your release process. A token for the project API is not automatically valid for a tool backend. For commercial Azure or a classic endpoint, use that interface’s documented endpoint and scope instead.

4. Define a narrow read-only tool and server-side dispatcher

Start with one tool, such as reading case status. The schema accepts an identifier, not a URL, SQL fragment, shell command, or credential. Resolve the caller’s allowed record set from trusted application authorization before dispatch.

{
  "name": "read_case_status",
  "description": "Read status for an authorized internal case",
  "parameters": {
    "type": "object",
    "properties": {"record_id": {"type": "string"}},
    "required": ["record_id"],
    "additionalProperties": false
  }
}

from security_patterns import dispatch_read_only_tool

result = dispatch_read_only_tool(
    model_tool_name,
    model_argument_json,
    authorized_record_ids=server_resolved_record_ids,
    lookup=read_status_from_fixed_internal_api,
)

Use the tool envelope expected by your selected Responses or Agent API; the schema above is the function definition, not an entire API request. The dispatcher example rejects unknown tools, extra fields, oversized arguments, and unauthorized identifiers before invoking the backend.

The backend must authenticate the dispatcher identity and enforce the intended access semantics. If using an on-behalf-of flow, configure and validate that flow explicitly. If using a service identity, the application must still enforce the user’s record permissions. Do not trust user identity supplied by the model.

5. Bound loops, approvals, and external protocols

Limit tool iterations, execution time, result size, and token consumption. Return minimal tool data, and treat tool responses as untrusted content. The model’s next tool proposal must pass authorization again; previous success does not widen its permissions.

For writes, bind human approval to a specific canonical action payload, record the approving principal, check the payload again at execution, and use idempotency controls. A general “continue” message should not authorize an arbitrary later transaction.

MCP and OpenAPI are tool integration mechanisms, not trust boundaries. Approve each server, endpoint, operation, authentication path, and data flow. Discovery must not silently expose new tools. Keep credentials in the trusted dispatcher and never pass them as model-visible context.

6. Test denied actions and state lifecycle

• Unknown tools, additional arguments, and model-provided URLs fail before a backend call.
• A valid tool request for another user’s record is denied on the allowed network.
• Prompt or tool-result injection cannot add tools or bypass required approval.
• A loop stops at the configured execution and budget limits.
• Revoked access blocks the next action, even in an existing conversation.
• Conversation and file cleanup follows the documented storage and backup lifecycle.

Capture allowlist configuration, backend permissions, denied-action tests, versioned agent definitions, and lifecycle evidence. Read the evaluation and observability guide for release gates and model and cost planning for token and state-storage budgets.

Sources and technical review

Technical review: October 7, 2026. Microsoft documentation changes over time; recheck feature availability and your authorization package before deployment.

• Agent Service feature availability in Azure Government
• Microsoft Foundry in Azure Government
• Standard agent setup and customer-managed stores
• Foundry agent capability settings
• Foundry agent function calling
• Data, privacy, and security for models sold by Azure

Confirm the offering and applicable authorization status in the FedRAMP Marketplace and review the provider package and your system security plan. Service availability is not an authorization determination.