otel.logging Helm settings never reach agent runtimes, so the documented audit-logging path emits nothing

[Rachael-Graham]

Disclosure: this issue was written by an AI agent (Claude) while verifying kagent's
audit-logging documentation, and reviewed by a human before filing.

Summary

otel.logging.enabled=true in the Helm chart configures the controller only. The
controller forwards a fixed five-name allowlist of tracing variables to agent runtimes
and no logging variable is on it, so the Helm setting is inert for an AgentInstance even
though the GenAI prompt and reply events are emitted by the runtime.

Verified both ways on a live cluster: the Helm path emits nothing, and the same
configuration applied through Harness.spec.env works.

The allowlist

// go/core/internal/translator/otel.go:13-19
var otelEnvNames = []string{
	"OTEL_TRACING_ENABLED",
	"OTEL_EXPORTER_OTLP_ENDPOINT",
	"OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
	"OTEL_EXPORTER_OTLP_PROTOCOL",
	"OTEL_EXPORTER_OTLP_TRACES_PROTOCOL",
}

OtelEnvFromProcess() copies only those names out of the controller's environment, and it
is called from one place, go/core/internal/translator/kagent/compiler.go:77.

Meanwhile the chart does set the logging variables on the controller —
helm/kagent/templates/controller-configmap.yaml renders OTEL_LOGGING_ENABLED and the
OTEL_EXPORTER_OTLP_LOGS_* family. Confirmed on a running cluster:

$ kubectl get configmap kagent-controller -n kagent -o jsonpath='{.data}' | ...
OTEL_LOGGING_ENABLED = false
OTEL_TRACING_ENABLED = true
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT = http://jaeger.jaeger.svc.cluster.local:4317

So the value exists on the controller and is never forwarded to the runtime that would act
on it.

Workaround that works, and why

Setting the variables on Harness.spec.env does reach the runtime. It is authoritative
precisely because logging variables are off the allowlist: HarnessEnvironment(harness)
is appended before OtelEnvFromProcess() and DedupeEnv keeps the last write, so the
controller overrides spec.env for the five tracing variables but not for any logging
variable.

That also means the workaround inverts if logging variables are ever added to the
allowlist, so it is not a stable contract to document.

Expected

Either the logging variables join the forwarded allowlist so otel.logging.* reaches agent
runtimes, or the chart documents that the setting is controller-only and names the supported
per-Harness path.

Note on a second, separate gate

The Go ADK elides log message content unless
OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true. The same variable has the
opposite default for traces, where the span payload is emitted unless the value is
explicitly "false". That asymmetry appears deliberate and is not part of this report.

Related

#1273 fixed an OTel logging problem in the 0.7.x Python runtime. This is a different path:
the v1alpha3 controller translator forwarding environment to Substrate Actors.