The access surface of one skill — databricks-cost-leak-hunter v2.27.0, one of five skills in the Databricks pack — read off its own allowed-tools frontmatter and the calls its instructions make. Six asset groups, three verbs, and the intersections it never asks for.
What you are looking at. Each row is an asset a Databricks security reviewer
asks about; each column is one of the three verbs. Only two cells are populated, both in the
read column — a SELECT on system.billing, accented because it is the
deepest access requested anywhere and the one needing a metastore-admin grant chain, and a read
of cluster and pool configuration from system.compute plus five read-only workspace
MCP tools. Two more cells are dashed rather than empty because the honest answer is narrower
than either yes or no: a warehouse id and a job id are handled, but neither object is ever
fetched. Everything else is deliberate negative space — no notebook source, no secret scope, no
row from any catalog of yours, and not a single entry in the write or delete columns.
Three caveats, stated rather than hidden. First, the grid covers Databricks
assets, and the skill's allowed-tools does grant Write and
Edit — those act on your local filesystem, not your workspace: Step 7
writes the ranked report and the per-category leak-*.json into a working directory
and edits the report only if you ask for the headline spend rescaled. Nothing is written back to
Databricks. Second, the package's setup reference carries the only mutating commands anywhere in
the skill — the GRANT chain and the api put that enables the
system schemas. Those are metastore-admin prerequisites you run: when the
grant probe fails, Step 1 reports the missing chain and stops rather than issuing it. Third, the
granted Bash scope is databricks:*, broader than the calls the skill actually makes
and broad enough to permit those admin commands, so narrow it in your own settings if your
review requires the permission and the behaviour to match exactly.