What is Riptides?
Riptides gives every workload in your infrastructure, whether it’s a long-running service, a CI job, or an AI agent, a cryptographic identity, and uses that identity to enforce mTLS, control which destinations a workload is allowed to reach, and deliver credentials, all without storing secrets in code or config and without modifying application or agent code.
It works at the kernel level, so applications and agent frameworks don’t need to be modified, instrumented, or rebuilt. A daemon runs on each node and loads policy into a kernel module that intercepts TCP connections, performs mutual TLS handshakes, and injects credentials into outbound requests, transparently.
The problem it solves
Section titled “The problem it solves”Most infrastructure security relies on network perimeter controls (VPCs, security groups, firewalls) or application-managed secrets (API keys in environment variables, credentials in Vault with sidecar proxies). Both approaches assume the thing behind them calls a fairly predictable set of destinations. Once a workload is running inside the perimeter, it’s implicitly trusted regardless of what it actually is, and every process sharing a service account or API key is indistinguishable from every other one holding the same credential.
That assumption breaks down hardest with AI agents. An agent decides at runtime what to call based on LLM output, so the same agent can take a different path through your infrastructure on every run, and a prompt injection can steer it toward a destination or tool call nobody intended. Static network rules and a service account shared across every agent instance can’t keep up with that, and when something does go wrong, there’s rarely a way to tell which agent, which session, or which user’s request was behind it.
Riptides replaces perimeter trust and shared credentials with identity assigned to the workload itself, whether it’s a classic service or an AI agent process:
- Who is this? The kernel module attests identity from process-level and environmental metadata: command name, Kubernetes labels, namespace, cgroup, cloud instance metadata. Attestation happens below the application, so a compromised process, or an agent acting on injected instructions, cannot spoof its identity. For an AI agent, that identity can be composite: the agent process, and the user or session it’s acting on behalf of, bound into the same identity, so an LLM call, an MCP tool call, and a local tool invocation all carry both.
- Is it allowed to talk to that destination? Policy defined as Kubernetes-style custom resources controls which identities can connect to which destinations: internal services, external APIs, or MCP servers and tool endpoints an agent calls.
- What credentials does it need? Credential bindings deliver short-lived, rotated credentials (cloud IAM, Vault, LLM provider API keys) directly to the kernel, so the workload’s process memory never holds a long-lived secret. There’s nothing in an agent’s context for a prompt injection or memory dump to steal.
How it compares
Section titled “How it compares”| Riptides | Service mesh (Istio/Linkerd) | Vault + sidecar | |
|---|---|---|---|
| Identity enforcement layer | Kernel | Sidecar proxy | Application |
| App changes required | None | None | Often |
| mTLS | Yes | Yes | No |
| Secretless credentials | Yes | No | Partial |
| Works on bare metal / VMs | Yes | Limited | Yes |
Riptides is not a replacement for a service mesh in all cases: if you need advanced traffic management (canary routing, retries, circuit breaking), a service mesh may be a better fit. Riptides is the right choice when you need strong workload identity, secretless credentials, or mTLS on bare metal and VM environments where sidecars are impractical.
For AI agents specifically, the comparable alternatives are an AI gateway or prompt-level guardrails, and both share the same limitation: they only see traffic that goes through them. A gateway covers the LLM calls routed through it; an agent that makes a direct connection, or that reaches an MCP server, a database, or an internal API outside the gateway’s path, bypasses it entirely. Guardrails try to stop an agent from being told to do something unsafe, but a credential sitting in the agent’s memory or a tool call to an unapproved endpoint doesn’t go through a prompt at all. Because Riptides enforces at the kernel, every outbound connection is covered regardless of which framework, library, or tool call initiated it, independent of whatever the agent’s LLM decided to do.
Core components
Section titled “Core components”Control plane: Hosted and operated by Riptides. You manage all resources (WorkloadIdentities, Services, CredentialSources) through it using riptides-cli ctl and the Riptides CRDs. You don’t deploy or manage the control plane yourself.
Daemon: Runs on each node (as a Kubernetes DaemonSet or a systemd service on VMs). It watches the control plane for policy changes and loads them into the kernel module. The daemon handles certificate signing and credential delivery.
Kernel module: Loaded by the daemon on startup. It intercepts TCP connections at the socket level to enforce mTLS and inject credentials. No application changes needed.
What you can do with Riptides
Section titled “What you can do with Riptides”- Transparent mTLS: enforce mutual TLS between any two workloads, or between agents in a multi-agent system, without changing application code or deploying sidecars
- Secretless credentials: workloads and AI agents call external APIs, cloud services, and LLM providers without ever holding a long-lived secret; credentials are injected at the kernel level and rotated automatically, so there’s nothing in process memory for a prompt injection or memory dump to expose
- Per-agent identity and attribution: every AI agent process gets its own SPIFFE identity, so multi-agent systems get agent-to-agent mutual authentication and every connection is attributable to a specific agent, session, and destination, not a shared “agent-service-account”
- Composite identity for delegated actions: bind the delegating user or session to the agent’s identity, so LLM calls, MCP tool calls, and local tool invocations alike carry both “which agent” and “on whose behalf,” not just which process made the call
- Egress and tool-call control: restrict which destinations, APIs, and MCP servers a workload or agent can reach, enforced below the application and independent of what an agent’s LLM decides to call
- Secret manager integration: bind secrets from any secret store to workload identities without static tokens, sidecars, or application-side SDKs
- Cross-cluster identity federation: workloads in different clusters, clouds, or on-premises environments trust each other’s identities via a shared trust domain
- Zero-trust messaging and data planes: extend mTLS and identity-based access control to brokers, queues, databases, and other infrastructure components without modifying producers or consumers
Getting access
Section titled “Getting access”Register for a free account to get started, or contact info@riptides.io for a production plan. Once you have your access details, head to the Getting Started guide.