Proposal: per-team row-level security for hubs, and a "dashboard first" rule for the hub agents

[Keerthi Math (keerthimath)]

Hi FinOps toolkit team,

I run FinOps hubs (v14, Azure Data Explorer) and have built two things on top of it that I'd like to contribute. Before opening issues and PRs, I'd like your view on whether they fit and in what form.

1. Row-level security: scope hub data by subscription

Problem: anyone with Viewer on the hub databases sees all cost data, so a hub can't be shared across teams who shouldn't see each other's spend.

What I've done: I enabled Azure Data Explorer row-level security on the eight final tables in Ingestion that carry SubAccountId (Costs, CommitmentDiscountUsage, Recommendations, Transactions, each _v1_0 and _v1_2), one function per table: an allow-all list (admins, the Data Factory identity, alert identities) plus per-team subscription lists. Because it runs in the database, it applies to KQL, dashboards and AI agents that query with the user's identity. I check the blockers first, test with set query_force_row_level_security before enabling, and keep a rollback.

Things I learned that would belong in the docs:

• SubAccountId must be matched exactly (/subscriptions/<id>, lowercase); rows with an empty SubAccountId (billing-level purchases, shared reservations) are only visible to the allow-all list.
• Team members need Viewer on both Hub and Ingestion: the Hub functions read Ingestion as the caller (with Hub only, queries fail with SEM0056 ... Access denied).
• RLS can't be enabled on the *_raw tables, but at the default raw retention (0 days) they hold no data, so Viewer on Ingestion exposes nothing unfiltered. Only hubs with raw retention above 0 need restricted view access on them.
• I verified the team path with a test team: the member saw only their team's subscription, the same user saw no rows once the team didn't own the data, and admin access was unchanged; ingestion kept working with RLS enabled.
• Any service identity (ingestion, report refresh, alert rules) must be in the allow-all list, or it silently sees nothing.

Proposal: start with a docs page, "Configure row-level security for FinOps hubs", under FinOps hubs (draft ready). Later, if useful, a PowerShell command to generate and apply the functions from a team-to-subscriptions config (I have a working Python version and would port it).

Questions:

• Is a docs page the right first step, or would you prefer this in the hub template (for example an optional setup script)?
• For hubs with raw retention above 0, is restricted view access on the *_raw tables the approach you'd recommend, or is there a better one?

2. "Dashboard first": let the hub agents use the dashboard's queries

Problem: the hub agents (Copilot instructions, Copilot Studio template, agent plugin) use the 37-query catalog in src/queries/catalog, while the Data Explorer dashboard (src/templates/finops-hub/dashboard.json) has its own 87 queries. The agent can answer a question with different logic than the dashboard tile the same user looks at, so the numbers may not match. Teams that customize the dashboard (their own tag conventions, egress rules, allocation logic) also don't get those definitions in the agent.

What I've done: in my own agent, the dashboard's tiles are exposed through one tool: the model picks a tile, sets its parameters, and can add a scope (subscription, resource group, resource type) that's applied as a filter on Costs(). The prompt says: if a tile matches the question, run it before writing your own KQL, and name the tile in the answer. Answers now match the dashboard, and team-specific definitions come for free.

Proposal:

1. A build step (extend Build-QueryCatalog.ps1, or a sibling script) that turns dashboard.json into an agent knowledge file: one entry per tile with its page, title, parameters and defaults, and the KQL with base queries and parameters resolved. It should also run on a customer's exported dashboard, so customized dashboards feed the agent.
2. One rule in the agent instructions: prefer a matching dashboard query over writing new KQL, and say which tile the answer came from.

Lessons from doing this: dashboard parameters need defaults resolved (an "all" multi-select becomes dynamic(null)), some tiles read tag columns that only exist on some hubs (bag_unpack), and a tile should only be run once per answer.

Questions:

• Would you take the build step plus the instruction rule? Which agent surface should go first (Copilot Studio knowledge, the agent plugin, or the Copilot instructions)?
• Should the shipped dashboard queries and the catalog stay separate, or should some catalog entries point to the dashboard tile instead?

I'm happy to open separate issues for each and keep the PRs small. I can also join office hours or the contributor sync to walk through either.

Thanks!

[Roland Krummenacher (RolandKrummenacher)]

🤖 [AI] Thanks for writing this up before opening PRs. A few thoughts from the maintainer side.

Row-level security. We'd see this as an optional add-on, not the default setup:

• "Team" means different things per customer. Subscription works for some; others split by resource group, tags, or management group, so a fixed SubAccountId rule won't generalize.
• Enabling RLS only on the final Ingestion tables leaves the raw tables uncovered. Short or zero retention narrows the window but doesn't close it. RLS on raw tables that feed an update policy only works when the update policy runs under a managed identity (see row level security policy), which the hub doesn't do today.
• Every RLS constraint also limits how the toolkit can evolve its tables and functions, so the full list of limitations needs to be understood before committing to it.

The practical path: open a feature issue for optional RLS in FinOps hubs with your gotchas (exact SubAccountId match, Viewer on both databases, empty SubAccountId rows, service identities in the allow list). The notes are useful as documentation even if a script comes later. Please include the hub version (v14) and that it's an ADX deployment.

"Dashboard first" for agents. Aligning the dashboard queries and the agent query catalog is a fair point. We're not convinced it needs to be a hard rule, because it would constrain both the dashboards and the agents to each other's scope. Please open it as a separate issue so it can be discussed on its own.

[Keerthi Math (keerthimath)]

Thanks, Roland, that makes sense. I've opened the two issues so each can be discussed on its own:

• Optional row-level security for FinOps hubs: Optional row-level security for FinOps hubs #2372
• Dashboard queries as optional agent knowledge: Dashboard queries as optional agent knowledge #2373

On your points: RLS is written up as opt-in only, with subscription as the common case and the scoping column configurable. On raw tables, I tested that at the default raw retention (0 days) they hold no data, so Viewer on Ingestion doesn't expose unfiltered rows; the docs call out restricted view access for hubs that keep raw data. And I agree on the upgrade constraint: the docs say to re-check RLS after upgrading. For dashboard first, I've reframed it as optional knowledge and guidance rather than a rule.

Happy to open a docs PR for the RLS issue if you're OK with that.