We are pinned to an agt-core generation upstream has already removed (CedarBackend, v4 policy language)

[imran-siddique]

The problem

PolicyEvaluator wraps AGT's v4 Cedar backend:

# src/cmcp_runtime/policy/evaluator.py
from agent_os.policies.backends import CedarBackend

That module no longer exists upstream. microsoft/agent-governance-toolkit#3444 replaced the v4 policy language with ACS v5 across the Python runtime and deleted agent_os/policies/backends.py. On AGT main there is no CedarBackend outside a migration CLI helper.

We do not notice because agent-governance-toolkit-core>=4.0 resolves to 4.1.0, tagged 2026-06-09, which still ships the module. Every release after it on that line has moved on.

Why this matters now

It is already blocking security work. #471 needs cryptography>=49.0 to close two reachable advisories, and the agt-core releases that permit it are the same ones that removed the API we import. The short-term answer there is a 4.1.1 backport, which is the right call for a CVE fix but does not change the underlying position: we are one dependency resolution away from a broken gateway, and pip will make that choice for us the moment our floor moves or 4.1.0 is yanked.

The exposure is not marginal either. Cedar evaluation is the enforcement path. If it breaks, cMCP allows or denies nothing correctly, and the demos, the web console, and every conformance claim go with it.

What needs deciding

1. Migrate to ACS v5. Understand what replaces CedarBackend, whether policy bundle hashing and the mode="auto" cedarpy/cli/builtin selection have equivalents, and what happens to the annotation extraction in _advice_for_deny that reaches into _build_cedar_request. That last one already depends on a private attribute, so it will not survive untouched.
2. Or vendor the evaluation we need. We use a small surface: evaluate(context), _build_cedar_request, and the backend-mode selection. cedarpy is already a direct dependency of ours. Owning ~200 lines against cedarpy directly would end the coupling, at the cost of maintaining it.
3. Or pin exactly and accept it. agent-governance-toolkit-core==4.1.0 makes the current state explicit instead of accidental, and buys time. It also means never taking an upstream fix again, including security fixes to agt-core itself.

Option 3 is worth doing immediately regardless of which of 1 or 2 wins, because >=4.0 currently lets pip pick a release that would break us silently.

First step

Pin agent-governance-toolkit-core==4.1.0 in pyproject.toml with a comment pointing here, so the constraint is deliberate. Then decide between migrating and vendoring.

[imran-siddique]

Audit result: staying on the 4.x line, this stays open pending upstream

I checked all seven agent_os imports against the 5.x line rather than porting on the assumption that only the evaluator breaks. Five are fine:

Import	5.x
agent_os.policies.backends.CedarBackend	module gone
agent_os.mcp_gateway.GovernancePolicy	symbol gone
agent_os.mcp_gateway.MCPGateway	present, signature changed
agent_os.mcp_response_scanner.MCPResponseScanner	ok
agent_os.credential_redactor.CredentialRedactor	ok
agent_os.prompt_injection.{DetectionConfig,PromptInjectionDetector}	ok
agent_os.mcp_security.MCPSecurityScanner	ok
agent_os.stateless.StatelessKernel	ok

So the migration is evaluator.py and proxy.py, not the evaluator alone. Two findings make it more than a rename:

1. No ACS v5 policy backend at the old import site. agent_os/policies/ now contains context_*, obligations, rate_limiting, data_classification. The policy engine lives in policy-engine/ and agentmesh/engine_api. There is nothing to port the evaluator to without picking up a new embedding surface.
2. MCPGateway is denylist-shaped on 5.x. It takes a required positional runtime and swaps policy=GovernancePolicy(allowed_tools=...) for denied_tools / sensitive_tools. cmcp allowlists from the catalog and fails closed on anything unlisted. There is no faithful allowlist expression in that API, and approximating one would weaken tool gating.

Point 2 is a governance question, not a porting detail: adopting 5.x's model would change what cMCP guarantees about unlisted tools.

Decision for now: hold the <5.0 ceiling and pursue the 4.1.1 backport in microsoft/agent-governance-toolkit#3614, which closes the two reachable advisories in #471 without touching tool-gating semantics. Commented there with this context.

This issue stays open as the record of the coupling. Revisit if 4.x is declared closed to backports, or if a supported embedding API appears for the relocated policy engine.