What breaks when Prometheus queries are filtered by label but not authorized at the request level?

When label filtering exists without request-level authorization, the control can still return the right slice of data to the wrong caller. The failure is not query correctness, but access control. In shared observability environments, that creates a confidentiality gap because the proxy may enforce tenancy in the result set while leaving entitlement unverified.

Why request-level authorization is the missing control

Label filtering can narrow what a query returns, but it does not prove the caller was entitled to ask for that data in the first place. If the proxy only rewrites or filters results, the security decision is still happening after the request has already been accepted. That leaves a gap between data selection and access control, which is the part that determines who may query what.

In a multi-tenant observability stack, that distinction matters because authorization is about the request, not just the output. A user or workload can still probe labels, discover tenant boundaries, or retrieve a permitted-looking subset of another tenant’s metrics if the control never verifies entitlement before execution. The result may look technically correct while still being a policy failure.

When the access check is missing, label filters become a data-slicing mechanism rather than a security boundary. That means they can reduce noise or constrain exposure, but they cannot by themselves establish trust, tenancy, or ownership. In practice, the control is only as strong as the request admission step that sits ahead of query processing.

What actually fails in shared observability environments

The failure is not usually in Prometheus query logic. The system may return an accurate result set for the labels supplied, yet still hand that result to a caller who should never have reached that dataset. That is why the control failure is best understood as unauthorized access with correct execution, not as a broken query engine.

This creates a confidentiality problem because observability data often carries production topology, service names, incident signals, and operational patterns. Even partial visibility can reveal workload relationships, deployment structure, or activity levels that a tenant should not see. The practical issue is that filtering can make leakage smaller, but it does not make the access decision sound.

NHIMG’s Ultimate Guide to NHIs is useful here because the same pattern appears whenever machine or service access is allowed to reach shared telemetry without explicit entitlement checks. Its lifecycle and governance sections help frame the broader control problem: who owns the caller, who can revoke it, and how access is validated over time.

How to think about the control boundary

Request-level authorization should decide whether the caller can perform the query at all, while label filtering should only constrain the data scope after that decision has been made. Those are different control layers, and they solve different problems. If the environment relies on filtering alone, the system is effectively trusting the query shape as a proxy for entitlement, which is too weak for shared services.

For practitioners, the key question is whether the proxy can answer “is this identity allowed to ask this question?” before it answers “which series should this query return?” If the answer is no, then the architecture is relying on downstream data shaping to compensate for missing policy enforcement. That may be acceptable for convenience, but it is not a strong access model.

Label-based restrictions also tend to break down when metadata itself becomes sensitive. If tenant names, environment tags, or service labels are visible, an attacker or curious insider can still infer structure from the response pattern even when the result set is limited. The safer pattern is to combine pre-query authorization with scoped query execution and auditability of who queried what.

Using a broader access-governance reference such as Lifecycle Processes for Managing NHIs is helpful when the query is issued by automation, because the entitlement problem often starts with how the calling identity was provisioned and whether it was ever recertified. Top 10 NHI Issues is also relevant as a reader map for the common failure modes around over-privilege and weak governance.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Request-level authorization is an access-control decision for query callers.
Recommendation — Enforce access control before query execution and verify tenant-scoped entitlements.
NIST CSF 2.0	PR.AC — Identity Management, Authentication and Access Control	The issue is whether the requester is entitled to the data, not whether the query parses.
	GV.OC — Organizational Context	Shared observability demands explicit ownership and boundary definitions for data access.
Recommendation — Apply PR.AC to verify requester entitlement before allowing observability queries. Define tenant and data-access boundaries for telemetry as part of governance.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Exposure	Caller identities in observability often rely on machine credentials that must be governed.
	NHI-06 — Over-Privileged Non-Human Identities	The core failure is allowing a caller to reach data without proving least privilege.
Recommendation — Protect and rotate the credentials that authorize automated query callers. Reduce query-caller privileges to the minimum dataset and action scope required.
NIST SP 800-63	IAL — Identity Assurance Level	Strong request authorization depends on confidence in the identity making the query.
Recommendation — Use higher assurance where telemetry access can expose sensitive operational data.
NIST Zero Trust (SP 800-207)	3 — Continuous Verification	A request should be checked each time, not assumed safe because the result was filtered.
Recommendation — Continuously verify the requester before releasing query results.

Practitioner Guidance

What to verify: Confirm that authorization happens before query execution, not only after the result set is assembled. If the proxy can filter data but cannot deny the request based on caller entitlement, treat the design as incomplete for multi-tenant isolation.

What good looks like: The caller is authenticated, authorized for the request context, and then constrained to a tenant-safe result set. Audit records should show both the requesting identity and the policy decision, so you can distinguish a denied query from a permitted query with narrow scope.

Common mistake: Treating label filtering as if it were an access-control boundary. It may reduce blast radius, but it does not replace entitlement checks, especially where metrics can expose service structure, environment names, or operational state.

Practitioner takeaway: If request-level authorization is missing, the system may still be “correct” at the data layer while remaining insecure at the access layer, and that is the failure mode that matters most.