Hi @ittzzmalind,

Because the IP is in the same Azure region but not listed in the Azure Databricks control plane ranges, it’s very likely not a Databricks owned control plane IP. It’s typically either a user or service coming from another Azure resource (VPN, VM, VDI, NAT gateway, firewall, etc.), or a 3rd-party/SaaS or other tenant hosted in Azure.

You generally can’t map an IP directly to "this Databricks cluster/table/UC object" from IP lists alone. Instead, you need to correlate identity + audit logs... Would recommend the below steps unless you have already checked it out..

Check Microsoft Entra ID --> Sign-in logs filtered by that IP and the Azure Databricks application. This shows which user/service principal is authenticating, from what device/location, and whether sign-ins are succeeding or failing.

Use Databricks audit logs (system tables like system.access.audit or exported audit logs in Log Analytics) and filter on that IP. From fields like service_name, action_name, request_uri, clusterId / sqlWarehouseId / UC object names, you can see whether it’s accessing clusters, jobs, Unity Catalog, tables, etc. It is easy to query the system tables. Let me know if you want a simple query to get this from system tables.

Compare identity vs. expected users/service principals, IP vs. your known NAT/firewall/VPN IPs, and actions vs. what that identity should normally be doing (and when).

If it’s an unknown identity from an unknown Azure IP doing unusual or failing actions, treat it as suspicious and consider blocking it via context-based ingress controls, workspace IP access lists, or your firewall, and rotate any involved credentials.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.