Hello Mohamed, Rihan,
Greetings! Thanks for raising this question in the Q&A forum.
The IMDS (169.254.169.254) connection error is almost always related to Microsoft Entra ID token acquisition through Managed Identity, not to the image content itself. When your agent's underlying compute or connection tries to authenticate using DefaultAzureCredential (or an equivalent SDK-managed credential chain), it attempts several credential sources in order, and ManagedIdentityCredential is one of the first it tries. If the environment cannot reach IMDS, either because no managed identity is enabled or the network path to the metadata endpoint is blocked, that specific credential attempt fails and logs the connection error you're seeing. Whether this is harmless noise or a real blocker depends entirely on which downstream call is relying on that token.
I noticed the error block in your post came through empty, so I can't see the exact exception text or correlation ID. Based on the symptom pattern (text queries succeed, image queries fail, IMDS shows up in App Insights), here is the most likely cause and how to confirm it.
Check which resource actually processes the image. In Foundry Agent Service, image understanding for an uploaded file is typically routed either through the multimodal capability of the deployed chat model (for example GPT-5 with vision input) or through a separate connected resource such as Azure AI Vision or Content Understanding for OCR. Go to Foundry portal > Your project > Connected resources and confirm which resource is wired up for image/document processing.
Confirm the authentication mode on that connection. Under Connected resources > [resource name] > Authentication, check if it's set to API key or Microsoft Entra ID (managed identity). Only the Entra ID/managed identity path will attempt to reach IMDS. If your AI Search connection uses an API key but the vision/OCR resource is configured for Entra ID, that mismatch explains why text queries (Search-based) succeed while image queries (vision/OCR-based) fail.
Verify managed identity is actually enabled and has role assignments. Go to Foundry project > Settings > Identity and confirm a system-assigned (or user-assigned) managed identity is turned on. Then in the target resource (Azure AI Services, Computer Vision, or Content Understanding), go to Access control (IAM) and confirm the project's managed identity has at minimum the Cognitive Services User role, or Azure AI User if you're on the newer Foundry RBAC model. A missing role assignment will not stop the IMDS call from happening but will cause the subsequent authorized call to fail with a 401/403 right after.
Check network restrictions. If your Foundry project or the target Cognitive Services resource sits behind a private endpoint or has public network access disabled, and the hosted agent's compute doesn't have a route to IMDS or to the target resource's private endpoint, the token request or the downstream call will fail. Review Networking on both the Foundry resource and any connected Cognitive Services resource.
Confirm the model deployment supports vision input in your region. Even with authentication resolved, image processing will silently fail if the specific GPT-5 deployment or SKU you're using doesn't have multimodal input enabled for your subscription and region. Check Foundry portal > Model catalog > Your deployment > Capabilities to confirm vision/image input is listed.
Capture the full exception. In Application Insights, run this query to pull the complete stack trace and any CorrelationId tied to the failed image request, since that will confirm exactly which SDK call is generating the IMDS attempt.
traces
| where timestamp > ago(24h)
| where message has "169.254.169.254" or message has "IMDS"
| project timestamp, message, severityLevel, operation_Id, cloud_RoleName
| order by timestamp desc
To directly answer your four questions: the IMDS error itself is expected behavior when any part of the pipeline uses managed identity based authentication, so it is not inherently a bug, but it does indicate that a token acquisition attempt failed somewhere in that request path. Yes, it can block image processing or OCR if the specific resource handling that step depends on the failed token. Azure AI Foundry does require managed identity or IMDS access only for the connections you've explicitly configured to use Entra ID auth, not universally, so this is a configuration choice rather than a hard platform requirement. And the configuration to verify is the connection authentication type, the RBAC role assignment on the target resource, and network reachability, as outlined in steps 2 through 4 above.
If you can share the full error text and the CorrelationId from Application Insights, I can help pinpoint the exact failing call. If after these checks the issue persists, please open a support ticket through the Azure portal with the CorrelationId attached, since a persistent IMDS timeout inside a fully managed hosted agent environment (not a customer-managed VM) would point to a platform-side networking issue that needs the Foundry Agent Service team to investigate directly.
If this answer helps you kindly accept the answer which will help others who have similar questions.
Best Regards,
Jerald Felix.