See what every agent is doing, who it's talking to, and what was allowed or denied — captured automatically, streamed to your existing stack.
"Not a vague answer — nothing. Your APM shows service-level traffic. Your logs show what the agent framework decided to log. But when the CISO asks 'which agents accessed customer data last Tuesday, and on whose authority?' — you're guessing."
— VP Engineering, AI-native startup
APM tools show pod-to-pod traffic. They can't tell you which agent process made which request, or distinguish one agent from another on the same host.
When an agent calls an external API, there's no immutable record of which agent, which identity, which policy allowed it. Agent-side logs can be suppressed, modified, or simply not implemented.
Agents exhibit dynamic behavior — they decide at runtime which tools to call. Without a kernel-level baseline, you can't detect when an agent starts doing something it's never done before.
A prompt injection happened. Which agent? What did it try to reach? Was it blocked? How long was it active? Without agent-aware telemetry, your SOC team is blind.
LLM API bills arrive as a single line item. When costs spike, you can't tell which agent, which user, or which workflow is responsible.
Every agent connection captured automatically at the kernel level. Every event tied to the agent's SPIFFE identity. Streamed to your existing observability stack. No agent code changes.
Every agent connection is captured automatically — no SDK, no instrumentation, no code changes. You see every destination every agent talks to, with source identity, port, protocol, and timestamp.
Each connection is tagged with the agent's identity, the policy that was evaluated, the decision (allow/deny), and which credential was used. Your SIEM receives structured events, not raw logs.
Connection events stream to your observability pipeline: OpenTelemetry, Datadog, Splunk, Elastic, or any SIEM. Native integrations, standard formats. No new dashboard to adopt.
Alerts fire when agents exhibit unexpected behavior — new destinations, traffic volume spikes, off-hours activity, sudden deny patterns.
Which agents accessed what, when, and under which policy. Cryptographic identity on every event — not pod IPs, not container names.
Every connection is captured at the kernel, below the application layer. Agents can't suppress, modify, or omit their own records. What the kernel sees is what your SIEM receives.
You don't just see that a connection happened. You see the policy rule that allowed or denied it, and the full evaluation context. This is the audit trail compliance requires.
No logging SDK to integrate, no OpenTelemetry instrumentation in agent code. Works with LangChain, CrewAI, AutoGen, LangGraph, and any framework. The kernel module captures everything automatically.
Application-layer logging depends on the agent framework logging correctly — and on the agent not being compromised in a way that suppresses its own logs. AI gateways see traffic that flows through them, but agents can make direct connections that bypass the gateway. Kernel-level capture is comprehensive and tamper-proof: every TCP connection from the agent process is captured regardless of framework, configuration, or compromise state.
Deploy Riptides on the cluster where your agents run. Before enforcing any policies, you immediately get full attribution: every connection every agent makes, tied to its identity, streamed to your SIEM.
This is the deployment that answers the CISO's question — and unblocks the production approval conversation.
| Application-Layer Logging | AI Gateway | Riptides | |
|---|---|---|---|
| Identity granularity | Service or pod level | Request-level (if routed through gateway) | Per-agent SPIFFE identity |
| What's captured | What the framework logs | Traffic through the gateway | Every connection at the kernel |
| Agent can suppress logs | Yes | Can bypass gateway | No — kernel captures independently |
| Covers direct connections | Only if instrumented | No — only proxied traffic | Yes — all TCP connections |
| Policy context | None | Gateway rules | Full policy evaluation: rule, decision, reason |
| Credential exposure | API keys in HTTP logs | API keys visible to gateway | Credential name only (never the secret) |
| Code changes | Logging SDK, instrumentation | Route traffic through proxy | None |
| Audit posture | "We log what the framework provides" | "We log what flows through the gateway" | "Every agent connection is captured with SPIFFE identity" |
How Riptides turns raw kernel tracepoints into workload identity events and Prometheus metrics: Securing Workloads with Kernel Telemetry and Metrics →
Attribution is one record per action, starting from a cryptographically verified identity for every agent and service — not a pod IP or container name. It is distinct from AI agent observability tools that track LLM performance, token counts, or trace execution graphs. Those tools answer "how is my agent behaving?" Attribution answers a different question: "which identity made this connection, on whose behalf, what was it allowed to do, and was that policy enforced at the kernel?" Every event carries a SPIFFE identity verified below the application layer, so your security team gets an audit trail that agents cannot suppress, forge, or omit.
Every connection is logged with the SPIFFE identity of the sending workload, the destination endpoint, the timestamp, and the policy decision: allowed or denied. For AI agents, this includes every tool call, API request, and MCP connection. Logs are structured and stream to OpenTelemetry, Datadog, Splunk, Elastic, or any compatible sink via standard protocols.
Network flow logs record IP addresses and ports. Identity-aware attribution records which specific workload or agent made each connection, verified cryptographically at the kernel. During incident response, you can answer not just what IP made a call but which exact process, on which node, running as which SPIFFE identity. This closes the attribution gap that makes credential breaches take an average of 292 days to contain.
No. Riptides streams identity-enriched attribution to your existing stack. It does not replace Datadog, Splunk, Grafana, or your SIEM. It adds workload identity context to the connection events that already flow through those tools.
Yes. Riptides has a permissive mode that logs all connection events and policy decisions without blocking anything. Teams typically start in permissive mode to map their workload communication graph before enabling enforcement. You can observe for as long as you need before enforcing.
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.