From the screenshot it does show:
That’s good, but this must come from your databricks.yml. If you only added it via the UI, but the bundle doesn’t declare it, a redeploy can put things out of sync.
Key points:
For serving endpoints → CAN_QUERY is correct.
For Genie spaces → you need CAN_RUN, not CAN_QUERY.
Put the permission on app: ${bundle.app_id} so the app identity, not just you as a user, can call Genie.
If Genie was only granted to you or another user in the UI, the multi-agent (running as the app identity) still won’t be able to use it.
Permissions alone aren’t enough; the Multi Agent Supervisor needs Genie explicitly defined as a tool in its agent spec.
You should have something like:
"tools": [
{
"type": "agent",
"agent_id": "knowledge-assistant",
"name": "knowledge_assistant"
},
{
"type": "ai_bi_genie",
"name": "genie",
"genie_space_key": "genie-space" // must match the app resource key
}
]
Common mistakes:
If the key doesn’t match, the app starts fine but the supervisor can’t resolve the Genie tool at runtime.
Go to the App → Logs tab and look for messages when the supervisor tries to use Genie:
If you see PERMISSION_DENIED / 403 / “no access to genie space” → it’s a permissions / app-identity issue → fix CAN_RUN for the app as above.
If you see something like “tool not found” / “unknown tool” / “no resource genie-space” → it’s a wiring issue → fix the tools configuration and/or the genie_space_key.
This will tell you very quickly whether it’s auth or config.
Also, don't forget about the underlying permissions.
Even if the app can “run” the Genie space, Genie still needs access to:
Make sure the app principal (same identity you gave CAN_RUN on Genie) has:
SELECT / USE CATALOG / USE SCHEMA on the relevant UC objects, or
CAN_USE on semantic models if you’re using them.
Otherwise the supervisor might reach Genie, but Genie will fail to answer because it can’t see the data.
Hope it helps!