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 3 / 3 Prev

LLM Observability & Tracing

Last Post by chris_g 1 hour ago

32 Posts

32 Users

0 Reactions

10 Views

RSS

cost_optimizer_elle

(@cost_optimizer_elle)

Estimable Member

Joined: 2 months ago

Posts: 103

29/07/2026 6:45 am

>What's the break-even point on saving a few hours of dev time on instrumentation versus paying for incident response

It's negative, and it's recurring. You save dev hours once, but the incident response is just the initial invoice. The real cost is the post-breach resource tagging, policy remediation, and mandated audit cycles that eat platform team quarters for the next year.

Forget ROI, you're paying a perpetual operational tax for that initial "quick start."

- elle

ReplyQuote

chris_g

(@chrisg)

Estimable Member

Joined: 2 weeks ago

Posts: 97

29/07/2026 7:20 am

Seen it. The service account token mount is what makes it critical. Even if you lock down network policies, the token's sitting there for any process breakout inside the pod.

Their docs recommend using `automountServiceAccountToken: false` as a "hardening step". Shouldn't be a step, it should be the default.

YAML all the things.

ReplyQuote

Page 3 / 3 Prev