[Bug] Driver policy passes readback but cross-session calls get driver_policy_denied; Worker console ports publish on 0.0.0.0 (patch offered)

[Shuuyou]

Hi AgentTeams team — we are CyberGuard (github.com/elsechord/CyberGuard), a finalist project in the GOAI 2026 Agent Infra track building an autonomous security-operations team on top of AgentTeams v1.2.2. Two local-hardening findings from our deployment; for the second one we already carry a one-line patch and would be glad to upstream it as a PR.

Environment

• AgentTeams v1.2.2 (pinned release, commit 849182af), Docker Desktop, Windows
• QwenPaw Workers; investigation MCP servers registered through Higress

1. Driver policy passes readback + native evaluator checks, but cross-session calls still get driver_policy_denied

Steps to reproduce (condensed)

1. Configure the Driver policy for two investigation MCP drivers through the native management API: default deny, allow exactly three named investigation tools for Matrix sources.
2. Read the policy back after the write and evaluate the intended allow/deny cases with the installed native policy evaluator — all cases pass deterministically at configuration time.
3. Start a new Worker session and have the model call one of the allowed tools from its task room.

Actual

Cross-session tool calls still fail with driver_policy_denied, even though the same policy evaluates as allow in the deterministic check. For us, policy propagation/evaluation context across sessions remains an unresolved issue.

A related observation: a policy rule scoped to Matrix sources never matched in practice; we suspect the request-context channel/source fields are missing at evaluation time on some paths. We only got predictable behavior with exact-tool rules that do not depend on request-context channel fields.

Expected

A policy that reads back correctly and passes the native evaluator's allow/deny checks should be enforced identically in live sessions — or the docs/API should reveal which session/context attributes participate in evaluation so mismatches become debuggable.

Questions / suggestions

• Is Driver policy evaluation scoped per session, per driver instance, or global? Which context (channel, source, room) is available at evaluation time?
• Would you consider a "policy test" API that evaluates a policy against a live session context, so configuration-time checks match runtime behavior?
• Possibly related: bug: Driver card policy lost update: background reload_driver re-saves a stale card, clobbering a concurrent policy write #1283 (lost update in DriverManager.reload_driver reverting concurrent policy writes) — a different failure mode in the same subsystem; linking it here in case it interacts with the cross-session propagation we observed.

2. Worker console ports publish on 0.0.0.0; localhost binding requires a controller patch

Symptom

On v1.2.2, Worker environment creation unconditionally sets AGENTTEAMS_CONSOLE_PORT=8088, and the Docker backend publishes the random host port without HostIp (the PortBindings in internal/backend/docker.go, around line 717). CoPaw and QwenPaw worker consoles both ended up published on 0.0.0.0/IPv6 on our Docker Desktop engine. Setting the task bridge network's default bind address to localhost did not change this, because this port is requested explicitly by the API without a host IP.

Workaround we carry today

A one-line patch (plus a regression test) that rebuilds only the controller binary into the official embedded image — it changes only this automatic console binding and does not touch other explicit port mappings:

--- a/internal/backend/docker.go
+++ b/internal/backend/docker.go
@@ -717,6 +717,6 @@
 		portKey := consolePort + "/tcp"
 		p.ExposedPorts = map[string]struct{}{portKey: {}}
 		hc.PortBindings = map[string][]dockerPortBinding{
-			portKey: {{HostPort: strconv.Itoa(hostPort)}},
+			portKey: {{HostIP: "127.0.0.1", HostPort: strconv.Itoa(hostPort)}},
 		}
 	}

For transparency: our deployment is therefore a pinned-source build with this patch, not an unmodified release.

Suggestion + offer

Make the console bind host configurable at the controller level — we would suggest defaulting to 127.0.0.1 and opting into 0.0.0.0, since a per-worker admin console on all interfaces is a surprising default (or honor an existing knob if there is one we missed). We are happy to open the PR ourselves — the change is small and we already have the regression test; just tell us your preferred configuration surface (env var / controller flag / Worker spec field) and we will follow your contributor flow.

Thanks for building AgentTeams — we are glad to share more logs or test pre-release builds.

---

Hi AgentTeams team — we are CyberGuard (github.com/elsechord/CyberGuard), a finalist project in the GOAI 2026 Agent Infra track building an autonomous security-operations team on top of AgentTeams v1.2.2. Two local-hardening findings from our deployment; for the second one we already carry a one-line patch and would be glad to upstream it as a PR.

Environment

• AgentTeams v1.2.2 (pinned release, commit 849182af), Docker Desktop, Windows
• QwenPaw Workers; investigation MCP servers registered through Higress

1. Driver policy passes readback + native evaluator checks, but cross-session calls still get driver_policy_denied

Steps to reproduce (condensed)

1. Configure the Driver policy for two investigation MCP drivers through the native management API: default deny, allow exactly three named investigation tools for Matrix sources.
2. Read the policy back after the write and evaluate the intended allow/deny cases with the installed native policy evaluator — all cases pass deterministically at configuration time.
3. Start a new Worker session and have the model call one of the allowed tools from its task room.

Actual

Cross-session tool calls still fail with driver_policy_denied, even though the same policy evaluates as allow in the deterministic check. For us, policy propagation/evaluation context across sessions remains an unresolved issue.

A related observation: a policy rule scoped to Matrix sources never matched in practice; we suspect the request-context channel/source fields are missing at evaluation time on some paths. We only got predictable behavior with exact-tool rules that do not depend on request-context channel fields.

Expected

A policy that reads back correctly and passes the native evaluator's allow/deny checks should be enforced identically in live sessions — or the docs/API should reveal which session/context attributes participate in evaluation so mismatches become debuggable.

Questions / suggestions

• Is Driver policy evaluation scoped per session, per driver instance, or global? Which context (channel, source, room) is available at evaluation time?
• Would you consider a "policy test" API that evaluates a policy against a live session context, so configuration-time checks match runtime behavior?
• Possibly related: bug: Driver card policy lost update: background reload_driver re-saves a stale card, clobbering a concurrent policy write #1283 (lost update in DriverManager.reload_driver reverting concurrent policy writes) — a different failure mode in the same subsystem; linking it here in case it interacts with the cross-session propagation we observed.

2. Worker console ports publish on 0.0.0.0; localhost binding requires a controller patch

Symptom

On v1.2.2, Worker environment creation unconditionally sets AGENTTEAMS_CONSOLE_PORT=8088, and the Docker backend publishes the random host port without HostIp (the PortBindings in internal/backend/docker.go, around line 717). CoPaw and QwenPaw worker consoles both ended up published on 0.0.0.0/IPv6 on our Docker Desktop engine. Setting the task bridge network's default bind address to localhost did not change this, because this port is requested explicitly by the API without a host IP.

Workaround we carry today

A one-line patch (plus a regression test) that rebuilds only the controller binary into the official embedded image — it changes only this automatic console binding and does not touch other explicit port mappings:

--- a/internal/backend/docker.go
+++ b/internal/backend/docker.go
@@ -717,6 +717,6 @@
portKey := consolePort + "/tcp"
p.ExposedPorts = map[string]struct{}{portKey: {}}
hc.PortBindings = map[string][]dockerPortBinding{
-			portKey: {{HostPort: strconv.Itoa(hostPort)}},
+			portKey: {{HostIP: "127.0.0.1", HostPort: strconv.Itoa(hostPort)}},
}
}

For transparency: our deployment is therefore a pinned-source build with this patch, not an unmodified release.

Suggestion + offer

Make the console bind host configurable at the controller level — we would suggest defaulting to 127.0.0.1 and opting into 0.0.0.0, since a per-worker admin console on all interfaces is a surprising default (or honor an existing knob if there is one we missed). We are happy to open the PR ourselves — the change is small and we already have the regression test; just tell us your preferred configuration surface (env var / controller flag / Worker spec field) and we will follow your contributor flow.

Thanks for building AgentTeams — we are glad to share more logs or test pre-release builds.

[shiyiyue1102]

The current Docker backend still omits HostIP for the automatic console binding, consistent with the all-interface exposure you observed; a focused PR with your regression test is welcome, scoped to that binding and preserving explicit port mappings, with the default/bind-address configuration and remote-access compatibility called out for review.

For policy evaluation, QwenPaw 2.2.1 matches channel-scoped rules against request_context["channel"], so passing a standalone evaluator does not establish which context the live invocation received. Please share the installed QwenPaw version, a sanitized policy plus evaluator input, and one denied call's tool name and available channel/session context, with policy readback immediately after the failure. That should help distinguish a missing/mismatched invocation context from the reload race in #1283; we should not treat them as the same bug yet.

[Shuuyou]

Thanks @shiyiyue1102 — data below, with the layer distinction called out explicitly since we have denials from two different mechanisms.

Installed QwenPaw version — what we can and cannot attest. We did not record a runtime package version string in our exports; being precise rather than guessing:

• Worker image: higress-registry.cn-hangzhou.cr.aliyuncs.com/agentteams/agentteams-qwenpaw-worker:v1.2.2; the actual base-image RepoDigest read from the running cg-inv005-planner container on 2026-09-17 is sha256:5a8c60926009551f7ce555f657d63c8791450196a79ab41ba8bafd2e1bd51834.
• The only version-like strings in the Worker logs are component tags (session-sync[QwenPaw_QA_Agent_0.2], ReMe v0.4.1.3 for the memory component), which are not the product version.
• The readiness endpoint your runtime calls (/api/version) is exactly what we patched around locally (our proposed Worker._wait_for_qwenpaw_api change requires /api/version and the read-only /api/mcp list in the same bounded attempt); we can capture and attach its response on the next wake if that pins the version definitively.

Sanitized policy + evaluator input (2026-09-17, applied before run 003, per Worker per MCP client):

{
  "default_effect": "deny",
  "client_overrides": [],
  "tool_defaults": [],
  "tool_overrides": [
    {"source_type": "channel", "source_value": "matrix",
     "subject_type": "all", "subject_value": "",
     "effect": "allow", "tool_name": "read_investigation_evidence"},
    {"source_type": "channel", "source_value": "matrix",
     "subject_type": "all", "subject_value": "",
     "effect": "allow", "tool_name": "read_investigation_reports"}
  ],
  "unmanaged_rules_count": 0
}

Evaluator input was a constructed request_context with channel=matrix — which is precisely your point: it cannot establish what the live invocation carried. The native evaluator results we recorded: matrix:read_investigation_evidence=allow, matrix:read_investigation_reports=allow, console:read_investigation_evidence=deny, matrix:execute_shell_command=deny. (The readback-and-evaluate step persists the previous policy before mutation and reads back after apply; the after state matched the intended rules on all three Workers.)

One denied call (QwenPaw Driver layer, 2026-09-17):

• Tool: mcp-cyberguard-investigation-readonly__read_investigation_evidence
• Native call id: call_00_YubILewvqIXwouiZt1V35681; conversation-history seq 14
• Worker: response-planner (team leader)
• Session: matrix:!Lw5fzTc4bvXrOY0bUj:matrix-local.agentteams.io:18080 (the leader's DM room); timestamp 2026-09-17T03:35:16.420165 UTC
• Result: {"ok": false, "type": "driver_policy_denied", ...}
• Notably, a call to the same tool for the same run in a parallel model turn 227 ms later succeeded with a gateway receipt, and two further calls from the newly created task room (!8oG3gtAujMgdcFyoeC:..., seq 39/41) were denied again.

Context caveat, stated honestly: the exported history row carries the session_id (the Matrix room) but no explicit per-invocation channel field, so from our data we cannot prove which request_context["channel"] the driver actually matched against — consistent with your missing/mismatched-invocation-context hypothesis. For contrast, a 2026-09-18 worker error dump from a different layer (our model admission guard, below) does carry explicit channel: agentteams_matrix with full channel_meta (room id, worker name, event id), so the runtime clearly has that context available at the model-call boundary.

Do not conflate with the 2026-09-18 denial — different layer. The 9-18 event was our own admission guard rejecting the first model request (HTTP 400, cyberguard_admission / tool_definition_not_allowed, worker cg-inv005-investigator, channel agentteams_matrix) because the request carried tool definitions outside our per-role whitelist. It was not a driver_policy_denied, and no QwenPaw driver-policy evaluation of a live tool call occurred in that run because the request never reached the model. We are keeping the two failure classes in separate records.

Policy readback immediately after the failure — a gap we acknowledge. For the 03:35 UTC denials above we do not have a driver-policy readback captured immediately after the failure. The nearest artifacts are (a) the verified readback + evaluator run at ~03:33–03:34 UTC, about one to two minutes before, showing the channel rules present and effective, and (b) a post-hoc offline audit of the exported history later that day. For the 9-18 event we do have an immediate post-failure readback, but of the admission-guard ledger (run closed two seconds after the denial, denial counts recorded), not of the driver policy. We will capture a driver-policy readback immediately after the next denial in the next run so the reload race in #1283 and the context-propagation question can be separated on real data, as you suggest.

On the Docker side: we are opening a focused PR for the HostIP binding shortly, will link it here — scoped to the automatic console binding only, preserving explicit port mappings, with the default/bind-address and remote-access compatibility points called out for review.

[Shuuyou]

The focused PR for the HostIP binding is up: #1287

• Single commit on top of current main: buildCreatePayload's automatic console port binding now sets HostIP: "127.0.0.1"; explicit req.Ports mappings are untouched (covered by a dedicated regression test).
• Two regression tests added in internal/backend/docker_test.go (TestDockerCreateBindsConsolePortToLoopback, TestBuildCreatePayloadPreservesExplicitPortMappingHostIP); full backend package passes (go test ./internal/backend/ -count=1, run in a clean golang:1.25 container).
• The PR description flags the two design questions you raised for review: whether the loopback default should be configurable (env/flag/spec field), and the intended compatibility path for remote-access scenarios.

We'll follow up on the policy-evaluation part separately with the post-denial readback and /api/version capture as discussed above.

[shiyiyue1102]

AgentTeams v1.2.4 includes your console loopback-binding fix (#1287) and the QwenPaw Driver reload fix that preserves concurrent policy updates (#1299). Please upgrade both the embedded/controller and QwenPaw Worker images to v1.2.4, ensure the Workers are recreated with the new image, and retest the console binding and cross-session tool calls.

The channel/context mismatch has not yet been confirmed resolved by these fixes; if driver_policy_denied persists, please share the runtime /api/version, one denied call's tool name and available channel/session context, and a sanitized policy readback taken immediately after the denial. If both symptoms are resolved on v1.2.4, please let us know so we can close this issue.