Forum Discussion
Unable to Connect Azure AI Foundry Agent from Fabric Notebook
- 1 year ago
Hi AyusmanBasu0604,
A 401 from the Azure AI Foundry project endpoint (*.services.ai.azure.com) almost always comes down to one of four things:
- Mismatched endpoint vs. key - using a key from one resource (or project) with a different endpoint/region.
- Wrong auth header - sending the key in Authorization: instead of the required api-key: header.
- Local auth (keys) disabled on the Foundry resource, so all key-based calls are refused.
- Workspace outbound network controls (Fabric) blocking or rewriting the call.
Quick solution
- Use the project-scoped base URL and key from the same Azure AI Foundry project:
https://<foundry-resource>.services.ai.azure.com/api/projects/<project-name>
(Find them in the Foundry portal under your Project > Settings > Keys and endpoints.) - Call the Agents REST API with the latest supported api-version, and send the key in api-key (not Authorization).
- If your org has enabled Fabric Workspace Outbound Access Protection, ask an admin to allowlist *.services.ai.azure.com.
- If the resource has Local authentication disabled, switch to Entra ID auth instead of keys.
Why your DNS test failed
socket.gethostbyname() expects a host name, not a full URL. Drop the https:// and any path:
import socket socket.gethostbyname("<foundry-resource>.services.ai.azure.com")Minimal Python example (Fabric notebook)
This pings the Agents API “whoami” equivalent (list agents) to verify auth/route:
import os, requests PROJECT_BASE = "https://<foundry-resource>.services.ai.azure.com/api/projects/<project-name>" API_VERSION = "2024-10-01-preview" # check current version in docs API_KEY = os.environ.get("AZURE_AI_FOUNDRY_KEY") or "<paste-temporarily-for-test>" headers = { "api-key": API_KEY, # IMPORTANT: use api-key header "Content-Type": "application/json" } # Example: list agents url = f"{PROJECT_BASE}/agents?api-version={API_VERSION}" r = requests.get(url, headers=headers, timeout=30) print(r.status_code, r.text)If this returns 200, your auth and networking are good; any later 401s come from a different URL/key mix-up.
Common gotchas I’ve seen
- Using an Azure OpenAI “deployment” URL (/openai/deployments/.../chat/completions) with a Foundry project key, or vice versa. Stick to one stack per call. The Agents API reference is here: Azure AI Foundry Agent Service REST API. Foundry model endpoint format is documented here: Azure AI inference endpoint (services.ai.azure.com).
- Wrong header: Azure AI Foundry (and Azure OpenAI in Foundry) want the key in api-key. Details here: Azure OpenAI in Azure AI Foundry – authentication.
- Keys disabled: If an admin disabled local authentication on the resource, any key call returns 401. Confirm and use Entra ID instead: Authenticate to Azure AI services.
- RBAC confusion: The “Azure AI User/Developer” roles grant portal/project access, but do not magically fix a mismatched key/endpoint. If you need to view keys or switch to Entra ID, check your role assignment: RBAC for Azure AI Foundry.
Fabric networking note
If your Fabric admin has enabled Workspace Outbound Access Protection, your notebook’s egress may be restricted. Ask them to allow *.services.ai.azure.com for your workspace:
- Overview: Workspace outbound access protection
- Setup: How to set it up
If you still see 401 after the steps above, grab:
- The exact URL you’re calling (mask project name),
- The auth method (key vs. Entra ID),
- The response headers, and
- Confirmation that your key came from the same Foundry project as the endpoint, in the same region.
I’ve seen these four items resolve 90%+ of cases.
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.
Hi AyusmanBasu0604,
A 401 from the Azure AI Foundry project endpoint (*.services.ai.azure.com) almost always comes down to one of four things:
- Mismatched endpoint vs. key - using a key from one resource (or project) with a different endpoint/region.
- Wrong auth header - sending the key in Authorization: instead of the required api-key: header.
- Local auth (keys) disabled on the Foundry resource, so all key-based calls are refused.
- Workspace outbound network controls (Fabric) blocking or rewriting the call.
Quick solution
- Use the project-scoped base URL and key from the same Azure AI Foundry project:
https://<foundry-resource>.services.ai.azure.com/api/projects/<project-name>
(Find them in the Foundry portal under your Project > Settings > Keys and endpoints.) - Call the Agents REST API with the latest supported api-version, and send the key in api-key (not Authorization).
- If your org has enabled Fabric Workspace Outbound Access Protection, ask an admin to allowlist *.services.ai.azure.com.
- If the resource has Local authentication disabled, switch to Entra ID auth instead of keys.
Why your DNS test failed
socket.gethostbyname() expects a host name, not a full URL. Drop the https:// and any path:
import socket
socket.gethostbyname("<foundry-resource>.services.ai.azure.com")Minimal Python example (Fabric notebook)
This pings the Agents API “whoami” equivalent (list agents) to verify auth/route:
import os, requests
PROJECT_BASE = "https://<foundry-resource>.services.ai.azure.com/api/projects/<project-name>"
API_VERSION = "2024-10-01-preview" # check current version in docs
API_KEY = os.environ.get("AZURE_AI_FOUNDRY_KEY") or "<paste-temporarily-for-test>"
headers = {
"api-key": API_KEY, # IMPORTANT: use api-key header
"Content-Type": "application/json"
}
# Example: list agents
url = f"{PROJECT_BASE}/agents?api-version={API_VERSION}"
r = requests.get(url, headers=headers, timeout=30)
print(r.status_code, r.text)If this returns 200, your auth and networking are good; any later 401s come from a different URL/key mix-up.
Common gotchas I’ve seen
- Using an Azure OpenAI “deployment” URL (/openai/deployments/.../chat/completions) with a Foundry project key, or vice versa. Stick to one stack per call. The Agents API reference is here: Azure AI Foundry Agent Service REST API. Foundry model endpoint format is documented here: Azure AI inference endpoint (services.ai.azure.com).
- Wrong header: Azure AI Foundry (and Azure OpenAI in Foundry) want the key in api-key. Details here: Azure OpenAI in Azure AI Foundry – authentication.
- Keys disabled: If an admin disabled local authentication on the resource, any key call returns 401. Confirm and use Entra ID instead: Authenticate to Azure AI services.
- RBAC confusion: The “Azure AI User/Developer” roles grant portal/project access, but do not magically fix a mismatched key/endpoint. If you need to view keys or switch to Entra ID, check your role assignment: RBAC for Azure AI Foundry.
Fabric networking note
If your Fabric admin has enabled Workspace Outbound Access Protection, your notebook’s egress may be restricted. Ask them to allow *.services.ai.azure.com for your workspace:
- Overview: Workspace outbound access protection
- Setup: How to set it up
If you still see 401 after the steps above, grab:
- The exact URL you’re calling (mask project name),
- The auth method (key vs. Entra ID),
- The response headers, and
- Confirmation that your key came from the same Foundry project as the endpoint, in the same region.
I’ve seen these four items resolve 90%+ of cases.
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.
- AyusmanBasu06041 year ago
Helper II
First of all Thanks a lot for your detailed explaination tayloramy 😀
- socket.gethostbyname() expects a host name, not a full URL. Drop the https:// and any path: <-- yep this worked!
- As for the actual issue, it was due to the incorrect endpoint and API version combination. I needed to use the domain: ".cognitiveservices.azure.com" and was able to fetch the API version from the end of the URI provided in: Models + endpoints > Model Deployments. Click on the model and then under Target URI
- matkopajko12311 months agoNew Member
Hello,
I am facing similar issue. I created a Azure AI foundry project. Inside the agent with bing search as a tool was created. Now I am trying to call the agent within the project with REST API. I managed to do it withDefaultAzureCredential(). But I need it with REST API.
Or if u can somehow navigate me, how should I make the authorization in production. My goal is to have my BE deployed which will use the agent. I can't provide for every user some special account and to the az login everytime.- v-echaithra11 months ago
Community Support
Hi matkopajko123 ,
To authenticate a backend service using the Azure AI Foundry REST API in production without manually logging in each time, you have two primary authentication options: Service Principal Authentication and Managed Identity. Both methods allow your backend application to securely authenticate and interact with Azure services without needing to store credentials or require user interaction.Service Principal Authentication
Service principals are ideal for scenarios where you need to authenticate applications programmatically, such as backend services, without interactive login. This method provides a secure way to authenticate without embedding user-specific credentials.
Step 1: Create a Service Principal
In the Azure Portal, navigate to Azure Active Directory > App Registrations.
Create a new App Registration, which will represent your backend application.
After registration, generate a Client Secret under Certificates & secrets (this will act as a password for the service principal).
Record the Application (client) ID, Directory (tenant) ID, and the Client Secret.Step 2: Grant Permissions to the Service Principal
In the Azure AI Foundry resource, go to Access Control (IAM).
Assign the Azure AI User or Contributor role to the Service Principal to ensure it has the necessary permissions to interact with the Foundry API.Step 3: Authenticate Using the Service Principal
In your backend application, use the **client credentials flow** to obtain an OAuth token, which will be used for authenticating the API requests. Below is an example of how to do this in Python:
from azure.identity import ClientSecretCredential
import requests
tenant_id = "<your-tenant-id>" # Service Principal details
client_id = "<your-client-id>"
client_secret = "<your-client-secret>"
credential = ClientSecretCredential(tenant_id, client_id, client_secret)
token = credential.get_token("https://<your-api-scope>/.default") # Get a token from Azure AD using Service Principal
headers = {
"Authorization": f"Bearer {token.token}",
"Content-Type": "application/json"
} # Set up headers with the obtained tokenurl = "https://<your-foundry-resource>.services.ai.azure.com/api/projects/<project-name>/agents" # Your Azure AI Foundry endpoint
response = requests.get(url, headers=headers)
print(response.status_code, response.text)
``` # Make the REST API requestThis method ensures that your backend service can securely interact with Azure AI Foundry without the need for manual login. Using a service principal also ensures that credentials are kept secure, separate from user-specific logins.
2. Managed Identity (Recommended for Azure Deployed Backends)
If your backend service is hosted within Azure (e.g., Azure Web Apps, Azure Functions, or Virtual Machines), Managed Identity is the recommended approach. Managed Identity eliminates the need to manually manage credentials and provides a seamless authentication process for Azure services.
Step 1: Enable Managed Identity for Your Azure Service
If your backend is hosted in an Azure Web App or Azure Function, go to the Identity section of the service and enable System Assigned Managed Identity.
Step 2: Grant Managed Identity Access to Azure AI Foundry
In the Azure AI Foundry resource, navigate to Access Control (IAM).
Assign the Azure AI User or Contributor role to the Managed Identity of your Azure service. This grants your backend the necessary permissions to access the AI Foundry API.
Step 3: Authenticate Using Managed Identity
With Managed Identity enabled, your backend service can authenticate without needing to store any credentials. Using the Azure SDK's DefaultAzureCredential will automatically authenticate using the managed identity associated with the Azure service.
Managed Identity is the most secure and streamlined option for Azure-hosted services, as it eliminates the need to handle secrets or credentials directly. It ensures that authentication is automatic and integrated with Azure's identity management system.Both Service Principal Authentication and Managed Identity offer secure and scalable solutions for backend services to interact with the Azure AI Foundry REST API in a production environment.
Service Principal Authentication is suitable for scenarios where your backend service is running outside of Azure or when you need finer control over credentials.
Managed Identity is the preferred option for Azure-based services, providing seamless, secure, and automated authentication without the need for secret management. By implementing either of these authentication methods, you can ensure secure, production-ready access to your Azure AI Foundry resources without requiring manual user logins.
Hope this helps.
Thank you. - v-echaithra11 months ago
Community Support
Hi AyusmanBasu0604 ,
May I ask if you have resolved this issue? Please let us know if you have any further issues, we are happy to help.
Thank you.