GoodData makes metric permissions follow the query into MCP and its AI Assistant

GoodData has introduced beta object-level permissions for saved metrics, extending the same access policy across its metric editor, catalog, dashboards, API, Python SDK, MCP server and AI Assistant. The release gives administrators a narrower alternative to workspace-wide management rights, but GoodData explicitly says the beta should not be used in production yet. (GoodData documentation)

Creation is separate from access

The model splits metric creation from access to an existing metric. A new Workspace.CREATE_METRIC capability controls whether a user can save a metric; it can be added to VIEW or ANALYZE without granting full workspace management. A user with VIEW + CREATE_METRIC can create through the AI Metric skill, MCP create_metric, the API or Python SDK, while ANALYZE + CREATE_METRIC also enables creation in the user interface. Calls without the creation capability return 403 Forbidden. (GoodData documentation)

After creation, each metric has VIEW, SHARE and EDIT grants. New metrics default to restricted visibility, with EDIT assigned to the creator; existing metrics remain visible to all workspace members unless an administrator narrows them. VIEW exposes the definition and permits use, SHARE adds the ability to grant access, and EDIT permits definition changes and deletion. (GoodData documentation)

The important boundary is the dependency chain

A grant on a metric does not grant access to the facts, attributes, labels or other metrics it references. If any dependency is inaccessible, GoodData says the metric cannot be computed—even when the metric itself is shared with the user. Dashboards and visualizations cannot use a shared metric to route around that restriction, and the engine does not return a partial value with protected inputs omitted. (GoodData documentation)

GoodData also deliberately hides whether a protected object exists. Requests for an inaccessible metric return 404 Not Found; a new metric definition that references an inaccessible dependency also fails as not found rather than identifying the restricted object. That reduces metadata disclosure, but it means operators must distinguish a bad identifier from missing permission during troubleshooting. (GoodData documentation)

Why it matters for data agents

The same policy applies when the caller is an MCP client or the GoodData AI Assistant: those interfaces use the identity making the request and receive no additional access. Service accounts that create metrics through pipelines also produce restricted objects by default and must share them explicitly before other users can consume them. (GoodData documentation)

For teams exposing semantic layers to agents, that is the practical change: the governed metric is no longer merely a shared formula. Its definition, its use and every object below it have separate authorization checks. The feature is still beta and GoodData warns against production use, so the immediate task is evaluation—not rollout. (GoodData documentation)