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!