Witwave Operator MCP Tool Rendering Lacks SecurityContext, Creating PSS Parity Gap with Helm Charts

A critical security parity gap has been identified in the Witwave operator's MCP tool rendering pipeline. The operator's code path for applying MCP tool Deployments fails to include essential pod and container security configurations that are already present in the corresponding Helm chart, according to a high-confidence source review.

The vulnerability resides in `operator/internal/controller/witwaveagent_mcp_tools.go:226-285` (the `applyMCPToolDeployment` function) and `operator/api/v1alpha1/witwaveagent_types.go:1284-1344` (the `MCPToolSpec` definition). When a WitwaveAgent resource enables any of the `spec.mcpTools.{kubernetes,helm,prometheus}` flags, the operator renders a Deployment without critical security attributes. Specifically absent are pod and container `SecurityContext` settings, `ServiceAccountName` assignments, `AutomountServiceAccountToken` configurations, and `readOnlyRootFilesystem`-enabling volume mounts. The same security controls are fully implemented in `charts/witwave/templates/mcp-tools.yaml:118-365` on the chart side, creating a direct parity failure between the two rendering paths.

The gap surfaces most acutely in Pod Security Standards (PSS)-restricted namespaces, where the missing configurations cause admission failures or policy violations. Operators relying on the Go-based rendering path for MCP tool deployment will encounter these failures, while users deploying via Helm directly will not. This inconsistency creates a split deployment model where security posture depends entirely on which rendering mechanism is used. The issue is currently marked in-progress, with remediation requiring the operator code to be updated to carry forward the same security context logic present in the Helm chart templates.