Every agent request carries two things: which agent process is running, and whose authority it's acting on. Riptides binds both into a single SPIFFE identity — so you always know who did what, and on whose behalf.
"An agent deleted a production database record. It took two days to figure out which agent, which user's session triggered it, and whether it happened to anyone else."
— Security Lead, Enterprise SaaS company
All your agents use the same credentials. Logs show "agent-service-account" made 10,000 requests. Which agent? Which user? Which workflow? Unknown.
The service account gradually accumulates every capability needed by different agents and different users. Removing a permission risks breaking something — so permissions grow. Human lifecycle events never reach the agent's credentials.
Multi-agent systems have agents calling each other. Without mutual authentication, any process can impersonate any agent. A compromised agent in a LangGraph pipeline or CrewAI crew can call any other agent in the system.
Something went wrong. You need to answer: which agent, which user, which action, which time. With shared identities, you're correlating timestamps across logs from different systems and hoping they line up.
Every agent process gets a cryptographic SPIFFE identity — automatically, at the kernel level. When an agent acts on behalf of a user, the human's authorization context is bound to the agent's identity. Downstream services see both: which agent is running, and whose authority it carries.
Each agent process is identified and distinguished automatically — even two agents in the same pod. No registration, no SDK, no code changes.
When an agent acts on behalf of a user, Riptides binds the human's authorization to the agent's request. Downstream services see both: which agent is running, and whose authority it carries.
The same identity is used for agent-to-agent authentication, egress policies, credential bindings, and audit logs. One identity, consistent across every system.
Every request carries both the agent's workload identity and the delegating human's authorization. Resource servers know exactly who is acting and on whose behalf. When a human's access changes, the agent's delegated authority changes with it.
Every connection logged with the specific agent's SPIFFE identity, the destination, the policy decision, and the delegating user. Not "service-bot" — the exact agent, the exact user, the exact time.
Every connection between agents in a multi-agent system uses mTLS. Both sides prove their identity cryptographically. A compromised agent cannot impersonate another — the certificate is bound to the process, not a shared secret.
SPIFFE SVIDs are X.509 certificates proven via TLS handshake. They can't be stolen via prompt injection, copied from environment variables, or replayed from logs. This is infrastructure-level identity, not application-level tokens.
Works with LangChain, CrewAI, AutoGen, LangGraph, and custom frameworks. The kernel module assigns identity automatically based on process attributes. Learn how →
OAuth tokens and service accounts are application-layer credentials that the agent possesses. If the agent is compromised, those credentials are compromised. They're bearer tokens — anything that has them can use them. SPIFFE SVIDs are X.509 certificates bound to the agent process at the kernel level. The agent proves its identity through a TLS handshake, not by presenting a stealable credential. And composite identity — binding human delegation to workload identity — isn't possible with shared service accounts.
Deploy Riptides on the cluster where your agents run. Each agent process gets a unique identity automatically. Before enforcing any policies, you immediately see per-agent audit trails: which agent made which request, when, and to where.
This is the deployment that answers "which agent did it?" — and gives your NHI governance program coverage for AI agents.
| Shared Service Accounts | Riptides Agent Identity | |
|---|---|---|
| Identity granularity | One credential for all agents | Unique SPIFFE identity per agent process |
| Human attribution | Lost — agents act as "service-bot" | Composite identity: agent + delegating human |
| Agent-to-agent auth | None or shared secret | Mutual TLS per agent |
| Credential type | Bearer tokens (stealable) | Cryptographic proof (cannot be stolen or replayed) |
| Permission scoping | Union of all agents' needs | Per-agent based on individual identity |
| Incident investigation | Correlate timestamps across logs | Cryptographic identity on every connection |
| Lifecycle management | Manual; human offboarding doesn't propagate | Automatic issuance, rotation, and revocation |
| Control plane dependency | N/A — static credential, always present | None on the critical path — identity attested locally at the kernel |
| Audit posture | "We use service accounts" | "Every agent has a unique SPIFFE identity tied to the authorizing human" |
A technical look at the challenge of binding cryptographic identity to agent processes at runtime, and how SPIFFE solves it: How to Deliver SPIFFE Identity to AI Agents →
Composite agent identity binds multiple identity dimensions into a single SPIFFE SVID for each agent instance: the agent process itself, the user or system it is acting on behalf of, the task or session it is executing, and the node it runs on. This gives you complete attribution for every action an agent takes, not just which process made a call.
When multiple agents share a service account or API key, you cannot attribute a call to a specific agent instance. If an agent calls an unexpected endpoint, you know something happened but not which agent, which session, or which user prompted it. Per-agent SPIFFE identity makes every connection attributable to the exact agent instance that made it.
Yes. Riptides issues identity at the kernel level, below the framework. It works with LangChain, CrewAI, AutoGen, OpenAI Agents SDK, MCP-based agents, and any custom framework. No import, no annotation, no code change is required.
SPIFFE SVIDs are short-lived and auto-rotating. Revoking an agent's identity means stopping the issuance of new SVIDs for that process. Because credentials are never held in process memory, there is nothing to hunt down and rotate across systems. The identity simply expires at the end of its short TTL.
Traditional IAM assumes services follow predictable execution paths: they call known endpoints with known credentials in a known sequence. AI agents decide at runtime what to call based on LLM output, so the same agent can take completely different paths on consecutive runs. That breaks static policy rules built around known behavior. Riptides ties identity to the process at the kernel and enforces policy there, independent of whatever the agent decides to do next.
No. Unlike SPIRE, cloud IAM, or identity brokers, Riptides attests the workload and issues its SPIFFE SVID locally at the kernel when the process starts, using kernel-resident data. There is no remote round-trip on the critical path. Policy and credentials are synchronized in the background and applied locally, so an agent's identity and egress control keep working even if the management plane is temporarily unreachable.
Requires SPIRE Server, a SPIRE Agent DaemonSet, and a registration entry per agent. SVIDs are delivered via a Unix socket. Works, but adds operational overhead and requires a running control plane for every issuance.
mTLS identity via sidecar proxy. Not SPIFFE-native. Identity is tied to network location, not the process. Sidecars can be bypassed, and identity does not follow the workload if it moves outside the mesh.
Cloud-provider identity, not portable across environments. Requires OIDC federation configured per cloud. Provides no egress policy enforcement and no credential injection into the agent process.
SPIFFE SVIDs issued directly at the Linux kernel. No control plane required during agent execution. Identity is tied to the process, not the network. Delivers identity, credential injection, and egress enforcement in a single layer, with no code changes required.
Identity, access control, and a full audit trail for every agent and service — enforced on the host, with no code changes. Up and running in an afternoon.