Just finished a deep dive into the security audit report that was quietly published last week regarding Claw's LLM observability platform, specifically their new "auto-instrumentation" agent. If you're using it in a production environment, you should be concerned. The default configuration grants the agent's service account a shockingly broad set of permissions, ostensibly for "comprehensive tracing," but the audit details how this creates a trivial lateral movement path in a breach scenario.
The core issue is their default Kubernetes `ClusterRole` binding. It doesn't follow the principle of least privilege—it's the opposite. For the agent to capture span data from your LLM application pods, they grant it `list`, `get`, and `watch` on nearly every resource across all namespaces. More critically, the agent's pod also gets a mounted service account token with these permissions. The report demonstrates that if an attacker compromises the application, they can easily exfiltrate this token from the well-known API endpoint and then use it to query secrets, configmaps, or even pod logs across the entire cluster.
Here is a sanitized excerpt of the default `ClusterRole` they apply:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: claw-agent
rules:
- apiGroups: [""]
resources: ["pods", "services", "configmaps", "secrets", "endpoints"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments", "statefulsets"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["get"]
```
The audit team's proof-of-concept showed that with this level of access, an attacker could:
* Enumerate all running pods to map the cluster.
* Read configuration maps containing database connection strings or API keys.
* Access secrets (though not `create` or `update`, simply reading them is catastrophic).
* Watch pod logs for other services, potentially capturing sensitive output.
This is fundamentally a design flaw for an observability tool. The agent only needs to *read* the specific pods it's instrumenting, not inventory the entire cluster. The fact that this is the default—and their documentation touts it as a "one-click install for full visibility"—is negligent. It prioritizes convenience over basic security hygiene.
I'm curious if anyone else has audited their Claw deployment or similar tools (Langfuse, Phoenix, etc.) for this class of permission sprawl. What are the minimal viable RBAC rules you've implemented? Have you moved to a sidecar model instead of a cluster-wide agent to isolate the blast radius? Benchmarks on overhead are one thing, but a default config that expands the attack surface this dramatically makes the whole cost-per-token argument moot if you're introducing critical vulnerabilities.
Show me the benchmarks
I reviewed that same audit and what's even more concerning is the cross-namespace pod execution capability. The default role includes `pods/exec` permissions, which weren't highlighted in your snippet. If an attacker obtains that service account token, they aren't just querying data. They can get an interactive shell on any pod in the cluster. This transforms a single compromised application container into a full cluster takeover vector in about two API calls.
The performance argument for broad permissions is also flawed. I benchmarked a constrained role allowing `get` only on labeled pods in specific namespaces. The agent's latency for span collection increased by less than 3ms at the 99th percentile. That's a negligible tradeoff for closing the attack path.
Claw's documentation claims the wide permissions are necessary for "dynamic discovery of ephemeral LLM inference pods," but their own agent uses a watch mechanism that only requires permissions for the resources it's already monitoring. They could have shipped with a label-selector based model.