feat(openmeter): add OPENMETER_TRUST_REQUEST_USER to prevent forged attribution

[saswatds]

Summary

The OpenMeter callback resolves the CloudEvent subject from kwargs["user"] first, then falls back to the key-bound user_api_key_user_id. For multi-tenant proxy deployments, a client can set "user": "..." anywhere in the request body and cause their usage to be attributed to that arbitrary string — a billing-attribution forgery risk.

This PR adds a new env var OPENMETER_TRUST_REQUEST_USER (default "true", backward compatible). When set to "false", the request-supplied user field is ignored and the OpenMeter subject is resolved solely from user_api_key_user_id.

Motivation

Today, the only mitigation is for the proxy operator to ship a custom pre_call_hook that pops user from the request data before any callback runs (e.g. data.pop("user", None)). That works but is invasive — it removes the field for all callbacks, including ones that legitimately want the end-user value (e.g. Langfuse trace_user_id). An env var scoped to the OpenMeter callback keeps the mitigation localized.

Behavior

OPENMETER_TRUST_REQUEST_USER	kwargs["user"] set	user_api_key_user_id set	OpenMeter subject
unset / true (default)	yes	yes	kwargs["user"] (unchanged)
unset / true (default)	no	yes	user_api_key_user_id (unchanged)
false	yes	yes	user_api_key_user_id ✅ new
false	yes	no	raises OpenMeter: user is required ✅ new
false	no	yes	user_api_key_user_id

Tests

Added three new tests in tests/test_litellm/integrations/test_openmeter.py:

• test_common_logic_trust_request_user_false_ignores_request_user — verifies the key-bound user_id wins when the flag is false.
• test_common_logic_trust_request_user_false_still_raises_without_key_user — verifies the request user is not a fallback in this mode.
• test_common_logic_trust_request_user_default_preserves_behavior — explicit backward-compat check.

All 21 tests in the file pass locally.

Notes

• Matches the existing env-var-driven config pattern in openmeter.py (OPENMETER_API_KEY, OPENMETER_API_ENDPOINT, OPENMETER_EVENT_TYPE). No new config schema, no type definitions to update.
• Default behavior is unchanged, so existing deployments are unaffected.

[CLAassistant]

All committers have signed the CLA.

[greptile-apps]

Greptile Summary

This PR adds an OPENMETER_TRUST_REQUEST_USER env var to the OpenMeter callback that, when set to "false", prevents clients from forging billing attribution by injecting an arbitrary user field in the request body; the default remains "true" for full backward compatibility.

• The guard is read per-call inside _common_logic, consistent with how OPENMETER_EVENT_TYPE is read, and falls through to the existing user_api_key_user_id lookup or raises "OpenMeter: user is required" unchanged.
• Three new unit tests cover the flag-disabled path, the no-fallback error path, and the default backward-compat path; teardown properly clears the new env var.

Confidence Score: 4/5

Safe to merge; the default behavior is unchanged and the new flag is well-tested, with one minor usability gap in how falsy env var strings are parsed.

The implementation is small, clearly scoped, and all three new tests exercise the distinct behavioral branches. The only gap is that env var values like "0", "no", or "off" are silently treated as trust=true rather than being treated as the operator likely intended.

litellm/integrations/openmeter.py — the boolean parsing logic for the new env var.

Important Files Changed

Filename	Overview
litellm/integrations/openmeter.py	Adds OPENMETER_TRUST_REQUEST_USER env var guard in _common_logic; correctly defaults to trust (backward-compatible) and reads at call time consistent with OPENMETER_EVENT_TYPE; minor: only "false" (case-insensitive) disables, other common falsy strings like "0"/"no"/"off" are silently ignored.
tests/test_litellm/integrations/test_openmeter.py	Adds three targeted unit tests for the new flag; teardown_method correctly cleans up OPENMETER_TRUST_REQUEST_USER; no real network calls; tests cover all the behavioral rows from the PR table.

_{Reviews (1): Last reviewed commit: "feat(openmeter): add OPENMETER_TRUST_REQ..." | Re-trigger Greptile}

[greptile-apps]

The flag only disables when the env var is exactly "false" (case-insensitive). Common truthy-negative strings like "0", "no", or "off" are silently treated as trust = True — the opposite of what an operator setting one of those values would expect. A simple multi-value check avoids the silent mis-configuration.

Suggested change

	trust_request_user = (
	os.getenv("OPENMETER_TRUST_REQUEST_USER", "true").lower() != "false"
	)
	trust_request_user = os.getenv(
	"OPENMETER_TRUST_REQUEST_USER", "true"
	).lower() not in ("false", "0", "no", "off")

[saswatds]

Happy to accommodate this if it's a pattern this project wants to adopt. However, I feel just using false is strict and predictable.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Sameerlite]

@saswatds code qa is faling. Can you create a PR in litellm-docs to solve this?

[saswatds]

Opened the docs companion at BerriAI/litellm-docs#298. How do we want to order these? Docs first then rerun CI here, or merge this one and the docs PR back to back?