Moving a secret into a Kubernetes Secret did not remove its other copy from the generated workload specification. A principal able to get Pod specifications, but unable to get Secret objects, could still recover the seed from sidecar arguments. The later 1.2.1 change moved seed delivery into Secret-backed configuration. The prerequisite is access to pod…
Inspect the ClaimsCase · DiggingBeagle record
Agent Router MCP session seed remained visible in pod command arguments
Secret-backed configuration still copied the session encryption seed into readable Pod specs.
Public disclosure: Nov 6, 2026
Scope
Kubernetes Agent Router chart and extproc configuration in the advisory versions.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
The advisory traces session-seed values into Kubernetes Pod arguments readable below Secret permissions. No victim session takeover is shown. An impact band remains unassigned because the available evidence does not establish a comparable severity score or verified numerical loss for this assessment.
Assessed Nov 8, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-AGENTROUTER-MCP-SEED-PODARGS-01 · CLM-ENR-AR-SEED-POD-RBAC · Agent Router encryption seed exposed in pod arguments · Agent Router version 1.2.1 release
At a glance
Secret placement must be traced to every serialized runtime copy, including container Args and Helm output.
Read the implicationsThe prerequisite is access to pod metadata in the affected cluster. Session impersonation, concrete credential theft and rotation behavior in live customer deployments were not demonstrated.
Limits and uncertaintyFull account
Moving a secret into a Kubernetes Secret did not remove its other copy from the generated workload specification. A principal able to get Pod specifications, but unable to get Secret objects, could still recover the seed from sidecar arguments. The later 1.2.1 change moved seed delivery into Secret-backed configuration.
The prerequisite is access to pod metadata in the affected cluster. Session impersonation, concrete credential theft and rotation behavior in live customer deployments were not demonstrated.
This was a persistence of secret material across configuration representations. Moving the primary seed into a Kubernetes Secret did not prevent its value from being serialized into extproc container arguments, a surface readable through Pod metadata by principals lacking Secret permissions. The advisory also identifies optional previous-seed fallback handling during rotation. A complete repair must remove sensitive values from generated Pod specs and process arguments, not merely change where the chart initially reads them.
Mechanism and trust boundary
- 01
Read generated pod command-line arguments under an otherwise limited RBAC role.
- 02
Recover a seed that should have been confined to Secret access.
Claims & evidence
CLM-ENR-AR-SEED-POD-RBACThe Agent Router seed advisory reports that gateway Pod read permissions, including the built-in view ClusterRole, could reveal the MCP session seed from generated container arguments, without access to Secret objects.supported
Basis: reported finding
- supportsAgent Router encryption seed exposed in pod argumentsprimary disclosure
Where the seed can be read today; Impact
CLM-AGENTROUTER-MCP-SEED-PODARGS-01The Agent Router 1.2.0 secret-handling repair still passed the MCP session encryption seed through generated extproc container arguments accessible to actors with Pod read permissions.supported
Basis: reported finding
- supportsAgent Router encryption seed exposed in pod argumentsprimary disclosure
Summary; extproc sidecar receives seed as container argument
Implications
Secret placement must be traced to every serialized runtime copy, including container Args and Helm output.
Controls and mitigations
- Upgrade to Agent Router 1.2.1 and inspect generated Pod specs and process arguments for both active and fallback encryption seeds.
- Limit Pod metadata access, inspect historical audit and monitoring copies, and plan explicit seed rotation if exposed.
Unknowns and contradictions
- The prerequisite is access to pod metadata in the affected cluster. Session impersonation, concrete credential theft and rotation behavior in live customer deployments were not demonstrated.
Sources and citation
Material revision history
- Nov 8, 2026 · Canonical change recorded · new in release · revision 229