Based on what's currently documented, here's where things stand:
1. Is OBO supported for the new standalone Unity AI Gateway (the Beta one in the left nav, distinct from classic "AI Gateway on a serving endpoint")?
Not yet, as far as the public documentation shows. The UserAuthPolicy.api_scopes list that databricks-agents/MLflow's AuthPolicy recognizes is built from a fixed enum of REST API scope strings (things like serving.serving-endpoints, vectorsearch.vector-search-endpoints, dashboards.genie, sql, etc.), and ai-gateway isn't one of them which is exactly the validation error you're hitting. The standalone Unity AI Gateway (the one that logs to system.ai_gateway.usage and lives under the "AI Gateway" left-nav item, as opposed to the classic per-serving-endpoint AI Gateway) is itself still Beta, and OBO/per-user identity propagation into it from a Mosaic Agent Framework deployment doesn't appear to be wired up yet in databricks-agents==1.11.0 / mlflow==3.12.0.
2. What scope string should you use?
There isn't a published one yet. ai-gateway is not valid (as you found), and there's no ai-gateway.*-style scope documented alongside the others in the agent-authentication scope table.
3. Is there an MLflow resource type for it?
No, mlflow.models.resources currently only exposes DatabricksServingEndpoint, DatabricksVectorSearchIndex, DatabricksSQLWarehouse, DatabricksFunction, DatabricksGenieSpace, DatabricksTable, and DatabricksUCConnection. There's no DatabricksAIGateway/equivalent resource type for SystemAuthPolicy or UserAuthPolicy yet.
4. Workarounds people are actually using right now:
- If what you're really trying to reach is a Foundation Model API / model serving endpoint that happens to have AI Gateway features turned on (rate limits, guardrails, usage tracking, inference tables), that's still just a serving endpoint under the hood query it with the serving.serving-endpoints scope and DatabricksServingEndpoint resource, same as any other Model Serving OBO call. The "AI Gateway" branding on that endpoint doesn't change the auth path.
- If you specifically need the standalone Unity AI Gateway product (the one governing MCP servers, external models, coding-agent routing, etc.), OBO from a deployed Agent Framework model isn't supported yet โ the documented pattern (Databricks Apps with user_api_scopes in databricks.yml/UI, e.g. serving.serving-endpoints, dashboards.genie) is for Databricks Apps, not agents.deploy(). So today the practical option is to either (a) call it with system/service-principal auth instead of OBO, accepting that you lose per-user attribution, or (b) move that piece of the workflow into a Databricks App, which does support broader, more granular OAuth scopes including newer ones as they roll out.
- Since this is a Beta feature, scope support is actively changing worth filing this directly with your Databricks account team / support, since ai-gateway OBO scopes for Agent Framework deployments sound like exactly the kind of gap they'd want a paying-customer signal on.
I'd treat this as "not supported yet" rather than "you're missing a flag" nothing in the current docs shows a valid scope value for it. If you want, I can help you check via databricks api get or the SDK whether your workspace's scope enum has anything AI-Gateway-related that isn't yet in public docs.