Require Admin Approval When a Building Block Definition Version Increases Ephemeral API Key Permissions
Jelle den Burger
## Problem / Use Case
When a platform team releases a new version of a building block definition that grants the ephemeral API key
more permissions
than the previous version, there is currently no guardrail: the new version can be released and becomes active immediately without any review by the central admin team.This creates a governance and security risk. A building block with elevated permissions can take actions on behalf of the workspace — such as provisioning additional resources or modifying meshStack objects — and central administrators have no visibility or control over when these permissions are expanded.
For example: a building block that previously only read workspace metadata is upgraded to a new version that can also create new building blocks or modify IAM configurations. Today, this change goes live without any admin awareness or approval.
## Value / Impact
Introducing an approval gate for permission-increasing releases would:
- Give central admin teams visibility and control over when building blocks gain elevated access to the meshStack API.
- Reduce the risk of unintended or malicious permission escalation through building block version updates.
- Align the release lifecycle of permission-sensitive building block versions with the existing workspace services approval system, creating a consistent governance model.
- Enable platform teams to continue shipping non-sensitive updates (versions that do not increase permissions) without additional overhead.
The approval requirement should only trigger when the new version's ephemeral API key permission set is a
strict superset
of the previous version — so routine updates remain frictionless.