Declarative request policies (CEL-style): allow/deny/rewrite at tool invocation

[yinuu]

Hi all,

We're evaluating ContextForge as a governance gateway in front of many downstream tools/MCP servers with heterogeneous request conventions. Two recurring needs:

Rewrite — callers send X-Operator-Id as a header, but downstreams disagree on where it belongs: one wants operator_id in the body, another needs tenant context in nested fields.
Deny — per-team/per-tool rules beyond what RBAC expresses (e.g. "partner tenants can't call deploy_service").
Today each variation requires a bespoke Python plugin — doesn't scale, and admins can't self-serve.

Ask: would there be interest in a declarative policy layer — CEL-style expressions evaluated at the existing interception points, yielding allow / deny / rewrite? Key constraints:

Subtractive only — policies run after core authz (token scoping + RBAC) and can only restrict or reshape, never grant. Absent policies, behavior is unchanged.
Policy as data — rules ride the existing plugin bindings (per team×tool JSON config, runtime-managed, cluster-propagated).
Safe eval — fail-fast compiled expressions in a restricted environment, mirroring the response-side jq_guard precedent.
All the pieces already exist in the codebase (hook contract with allow/deny/rewrite semantics, bindings, unified_pdp precedent, jq guardrails) — this would mostly assemble them behind one expression engine.

For reference: agentgateway has already validated this pattern in the ecosystem with its CEL-based RBAC policy engine — this proposal is about bringing equivalent declarative ergonomics to ContextForge's existing enterprise model (teams, RBAC, plugin bindings), rather than asking teams to migrate gateways to adopt it.

Thanks!