Riptides is now open to everyone

For the last several months, we’ve been building Riptides alongside a small group of partners — security teams, platform engineers, and the people on the hook for the agents their companies are racing to ship. We learned a lot in private. Today, we’re opening it up. Anyone can spin up a workspace at riptides.io/get-started and try it.

This post is what we’d tell you if we sat down for coffee: what we kept hearing, what we built, and how to take it for a spin in a few minutes.

What we kept hearing

The story rhymes across everyone: moving agents into production is hard. Not because the models don’t work. Because nobody can answer the boring operational questions security and platform teams ask before agents go anywhere near anything real. The pilot demos beautifully; the prod conversation starts with “okay, but what is it actually allowed to touch, and how would we know?” — and that conversation tends to go on for months.

The same three questions came up almost everywhere.

The first one is access control. What is this agent allowed to reach, and how is that enforced? Existing IAM was built for predictable, long-running services that do roughly the same thing on Tuesday as they did on Monday. Agents don’t oblige: the same prompt produces different tool calls, different credential requests, different lateral moves on different days. The protocols agents talk over — MCP, A2A, tool-call APIs — are invisible to the IAM stack everyone already has. Faced with that, teams either over-grant and hope, or they say no and stall. Neither is a long-term position.

The second one is attribution. When something happens — a sensitive query, a strange API call, a data pull at 2 AM — who actually did it? Which agent, on whose behalf, with what context? The honest answer in most environments today is we’d have to put a few people on it for a couple of days. Logs show that a service account ran a query. Reconstructing the agent, the user who triggered it, and the path through three tools and four APIs is archaeology across logs, traces, and SIEM. By the time the answer arrives, the question has moved on.

The third is access to credentials, and it’s the one that wakes security teams up at night. Agents get handed long-lived API tokens and keys because nothing better exists in the runtime. Those credentials end up sitting in environment variables, config files, and process memory — exactly the places a prompt injection or a compromised dependency can reach. The blast radius of a leaked key is its lifetime, and its lifetime tends to be forever.

Underneath all three of those questions is the same thing: the service-account model. It was designed for services that look the same every day, and it’s been showing cracks for years. Agents bend it, then snap it. The fix everyone in those conversations was implicitly reaching for is the same one: identity that lives and dies with the agent — making JIT access and zero-standing privileges actually achievable, instead of a slide in someone’s roadmap deck.

What Riptides is

Riptides is runtime machine IAM, built for the agentic era: know what every agent did and why, and control what it’s allowed to access — all without changing a line of application code.

The foundation: composite identity

The thing the service-account model gets wrong is treating identity as a label you hand to an agent and hope it doesn’t lose. Riptides treats identity as something that’s attested — the kernel watches the agent start, observes what it actually is (the binary, the container, the Kubernetes service account, the user who launched it), and issues a cryptographic SPIFFE identity bound to that running process. The agent can’t claim to be something it isn’t, because nothing inside the agent is doing the claiming.

That alone solves the “which service account is this” problem. But agents add a second dimension: they act on behalf of people. When a developer triggers a coding agent, when an operator runs a query through an analytics agent, when an end user kicks off a workflow — there’s a human whose authority the agent is borrowing for that session. Riptides binds the human’s authorization context to the agent’s runtime identity for the lifetime of that session. Downstream systems no longer see “some agent running as some service account.” They see which agent, on whose behalf, with what session context. No more shared service accounts. No more confused deputies. No more guessing.

Everything else we do sits on top of that.

Attribution

Once identity is real and composite, attribution becomes a side effect rather than a project. Every outbound action the agent takes produces one record: which agent made the call, what credentials it used, what system it talked to, on whose behalf, what context was in scope at the time, and which policy decision was applied. That record is generated at the kernel, where the call actually happens, not reconstructed after the fact from application logs that may or may not have been written.

The practical effect is that the investigations security teams dread — “this happened at 02:47, figure out which of our 40 agents did it and why” — collapse from days of cross-referencing logs and SIEM queries into a single query against a stream of structured events. It also gives the platform team something they’ve never really had: a defensible answer to who is in control of what these agents can do.

Agent access

The flip side of attribution is enforcement. Riptides applies per-agent egress policy on the call path: the kernel sees the connection attempt, checks it against the agent’s identity-bound policy, and allows or denies it before the first byte leaves the host. The agent doesn’t get to negotiate with the policy, route around it, or be talked into bypassing it by a clever prompt.

The same machinery does credentials. Instead of handing agents long-lived tokens and praying they don’t leak, Riptides brokers credentials just-in-time on the call path. The credential is fetched from your secret store, injected into the specific outbound request that needs it, and never returned to user space. It exists in process memory for exactly zero seconds. A prompt injection or compromised dependency can’t exfiltrate a credential the process has never seen.

This is what “JIT access and zero-standing privileges” looks like once it stops being a slide. The agent has only the identity it was attested with, only the access its policy allows, and only the credential it needs for the call it’s making right now.

The same model for classic workloads

The static-service-account problem isn’t new. The same long-lived keys, the same flat internal trust, the same “who actually used this credential” gap have been quietly grinding away at traditional workloads for years — it’s where we started thinking about this in the first place. Agents made the problem loud enough that solving it for them is the priority right now, but the foundation underneath is the same.

So Riptides applies the same foundation to classic workloads: the same kernel attestation, the same identity, the same JIT credentials, the same enforcement. Agents and non-agent workloads end up governed from one control plane. That matters operationally — one mental model, one set of policies, one set of dashboards — and it matters strategically, because the line between “agent” and “regular service” is going to keep getting blurrier.

How it runs

A note on the how, because it tends to be the question people ask once they’re sold on the what. Riptides runs at the syscall path, beneath the application. There is no SDK to integrate, no proxy to deploy, no gateway to operate, no application code to change. Agents make ordinary network calls; the kernel does identity, policy, credentials, and telemetry transparently underneath. The result is that Riptides works with whatever you’re already running — LangChain, CrewAI, AutoGen, LangGraph, a custom Python script, a Go service that’s been in production for five years, or a third-party application you can’t even touch — without any of those things knowing or caring that Riptides exists.

Try it today

The whole self-serve flow takes a few minutes.

Request a workspace at riptides.io/get-started, then install the daemon on a node or VM and point it at your workspace:

curl -fsSL https://docs.riptides.io/install.sh | sudo bash -s -- \
  --control-plane https://<acmecorp>.console.riptides.io

Give your agent an identity:

riptides apply -f agent-identity.yaml

Attribution starts flowing immediately — every connection, every tool call, every credential use. When you’re ready to enforce, add access rules:

riptides apply -f credential-binding.yaml

That’s the whole flow. No other steps, no agent reconfiguration, no application restart. The shape of agent-identity.yaml and credential-binding.yaml, and what you can put in them, is covered in the docs.

What’s next

The thread we’re pulling on hardest right now is coding agents on developer workstations. Cursor, Claude Code or Codex are accessing cloud infrastructure, Kubernetes clusters, GitHub, and production databases — usually with whatever long-lived credentials happened to be sitting in the developer’s shell environment, on macOS or Windows laptops that the rest of the security stack barely sees. The same identity model that covers servers and Kubernetes nodes should cover those machines too: a coding agent running on someone’s laptop is, from a runtime perspective, just another agent that needs an identity, a policy, and credentials it doesn’t get to hold onto. Once that works the same way everywhere, the gap between “what my agent can do in prod” and “what my agent can do on my Mac” closes — without slowing developers down, and without handing the next prompt-injection or compromised MCP server a long-lived key to walk away with.

That work is much easier with real teams in the loop. So here’s the actual ask: spin up a workspace, point Riptides at something you care about, and tell us what breaks. The last few months produced something we’re proud to open up. The next few months are how it gets to “this is how every team runs agents in production.”

We’ll also be sharing more about how we run Riptides — the agents we let loose on our own infrastructure, the policies we wrote, the times we got it wrong, and what we changed. If that’s the kind of thing you want in your feed, stay tuned.

riptides.io/get-started

Follow us on LinkedIn and X for more updates.