The API Key Leaks Keep Coming - Now It’s x.AI

The latest high-profile API key leak has struck x.AI. A static API key granting access to internal AI models hosted on Groq’s infrastructure was accidentally committed to GitHub. As first reported by Krebs on Security, the key was live for several days, exposing valuable backend resources to anyone who stumbled upon it.

This isn’t an isolated case. Just in the past few months, Hugging Face, Docker Hub, and even GitHub itself have suffered similar exposures. The trend is accelerating. The reason? Static keys are dangerously convenient. Developers, often under pressure and without deep security training, treat API keys as throwaway credentials, just another config value to copy-paste and commit. Once pushed to Git or dumped into a shell script, these secrets become ticking time bombs.

Still the Norm: Static Keys and Shared Secrets

Despite the growing list of breaches, most companies, even those with large engineering teams still rely on static API keys and shared secrets to authenticate workloads and services. These credentials are often embedded directly in source code, committed accidentally to Git, passed through environment variables, mounted via Kubernetes secrets, or stored in plaintext on local filesystems. In many cases, these secrets are shared across multiple services or teams, increasing the blast radius if even a single system is compromised.

Even when secrets managers like AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager are used, the secret itself is still treated as a fixed asset, fetched at runtime and cached in memory or on disk. The assumption is that the environment is trusted enough to handle the secret securely. But in cloud-native systems where workloads are short-lived, containers are reused, and debugging access is widespread, this assumption often breaks down.

Sidecar proxies and agents are sometimes used to pull credentials on behalf of the application, but these don’t eliminate the secret, they just move the trust boundary. Any process with access to the sidecar or the local network interface can potentially extract the token. The result is an illusion of security layered over a fundamentally fragile model: credentials that live too long, travel too far, and are visible to too many components.

This model wasn’t built for today’s threat landscape. It assumes that secrets can be distributed and managed like configuration. But unlike config values, secrets have real security implications and handling them casually creates serious exposure.

A Kernel-Native Alternative: Ephemeral Identity by Design

At Riptides, we take a fundamentally different approach to workload identity, one that eliminates the need for static secrets altogether. Our system dynamically generates ephemeral identities (X.509 certificates, JWT tokens, etc) at the point of need, scoped to a single process, and tied directly to kernel-level runtime context.

Secrets are never written to disk, never passed via environment variables, and never exposed to userspace. Everything happens at the kernel level, tightly bound to real-time metadata (like process ID, cgroup, network communication, location, binary hash, etc). The identity is injected only when the workload genuinely needs to call an external service, and only if the live behavior matches an authorized policy.

This also allows us to enforce contextual access: a workload can’t just ask for a secret, it must be actively communicating with the intended destination, as verified by kernel-level telemetry. If a process tries to access a service it has no business talking to, the identity issuance is denied by design. No secret ever exists in a persistent or reusable form.

We call this kernel-native identity, and it’s built for the realities of modern infrastructure: distributed, dynamic, and under constant attack. No static credentials. No proxies. No sidecars. Just identity, embedded where it belongs - in the kernel.

Visibility: Monitoring Credentials in Motion

Beyond identity issuance, Riptides actively monitors all inbound and outbound connections at the kernel level. This gives us real-time visibility into which workloads are communicating, where credentials are being transmitted (if at all), and whether any secrets are being exposed over the wire. By inspecting traffic metadata and correlating it with process-level identity, we build a live communication graph and enforce policies based on observed behavior.

This approach allows us to detect when credentials are leaving expected boundaries, flag insecure usage patterns, and continuously assess the security posture of running systems — not just at deployment time, but throughout the workload’s lifecycle.

It’s Time to Kill the API Key

The repeated leaks we’re seeing — from startups to hyperscalers — aren’t just accidents. They’re symptoms of a broken model: static secrets scattered across infrastructure, owned by no one, and visible to everything. The industry has outgrown this approach.

At Riptides, we're building a future where identity is ephemeral, policy-aware, and deeply integrated into the kernel and where secrets don’t move because they don’t need to. Combined with live traffic monitoring and contextual enforcement, this gives teams a radically clearer view of what’s happening across their infrastructure and the power to stop misuse before it spreads.

The sooner we stop treating credentials like config, the safer our systems will be. Let's kill the API key, and replace it with something that actually fits the world we run today.

We've written extensively about our kernel-level architecture — from tracing and telemetry pipelines to eBPF-based observability and real-time identity enforcement. You can explore more in our #KERNEL blog series:

• Riptides: Kernel-Level Identity and Security Reinvented
• From Breakpoints to Tracepoints: An Introduction to Linux Kernel Tracing
• From Tracepoints to Metrics: A journey from kernel to user-space
• Seamless Kernel-Based Non-Human Identity with kTLS and SPIFFE
• Linux kernel module telemetry: beyond the usual suspects

‍