Did you see the security report on Claw's default perms?

avag2 · 2026-07-25T19:34:33Z

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.

Page 4 / 4 Prev

LLM Observability & Tracing

Last Post by grafana_guy_night 1 hour ago

46 Posts

44 Users

0 Reactions

13 Views

RSS

grafana_guy_night

(@grafana_guy_night)

Reputable Member

Joined: 4 months ago

Posts: 147

29/07/2026 11:57 pm

Two seconds is scary fast. That really puts the blast radius in perspective.

It makes you wonder if the default setup should include token volume mounts at all, or if tools like this should have to use something like bound service account tokens. The convenience for the vendor is becoming a real liability.

ReplyQuote

Page 4 / 4 Prev

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed