Splyntra an open-source observability + security tool for AI agents (self-hosted, OTel-native)
Hey IH 👋
I'm Anand, and I just launched Splyntra — an open-source observability and security platform built specifically for AI agents.
The problem: I kept watching teams (including my own past projects) ship agentic systems into production — agents calling tools, spending money, touching real customer data — with basically no visibility into what they were actually doing. Traditional APM tools are built for request/response services with predictable inputs. Agents aren't that. A single run fans out into planning steps, tool calls, retrievals, sub-agent handoffs — and any one of those spans can leak a secret, get hit by a prompt injection, or quietly spike your token bill. When something breaks, you're grepping logs across three different providers trying to reconstruct what happened.
What I built: One OpenTelemetry-native pipeline where trace and risk live on the same data — so instead of a separate observability tool and a separate security tool, you get one view: execution traces, a unified risk score (secrets, PII, prompt injection, tool abuse), cost/latency analytics, evals, and policy guardrails.
It's self-host first — docker compose up -d gets you the full stack locally — and the core is source-available (FSL, free for any use inside your company), with SDKs for Python and TS:
pip install splyntra npm install @splyntra/sdk
Time to first trace is under 5 minutes if you're already instrumenting with OpenAI/LangGraph/CrewAI/etc.
Where I'm stuck / would love input from this community specifically: pricing the managed cloud tier for solo devs vs. teams, and figuring out how much of "governance" (policy engine, audit ledger) actually matters to indie builders vs. just larger orgs. If you're running agents in anything resembling production, I'd genuinely love to hear how you're currently debugging when they go sideways — even "I just don't, and it terrifies me" is useful data for me.
Happy to answer anything about the architecture, the licensing model, or why I went with OTel instead of a proprietary format.
Never automate an unproven process — it just scales your mistakes." That line hits hard, David.
The shift you made from high-volume outbound to building an owned audience engine via ChoppingBlock and pSEO is a masterclass in adapting before a channel dies completely. Most agencies double down on spam when response rates drop; pivoting up the value chain to pure judgment and data positioning is the real play.
Running a sub-30% markup against Toptal's 100% while keeping margins healthy through AI-native operations is brilliant arbitrage. Rooting for that $10M goal!
Hey — I saw Splyntra and wanted to share something directly relevant.
I used Zarek ([zarek.tech](https://zarek.tech)) to plan the entire go-to-market for an AI observability tool. It's a permanent AI teammate for SaaS founders — it keeps memory across sessions, builds your launch roadmap, and drafts channel-specific copy so you don't start from scratch every time.
Here's what it actually produced for a product like Splyntra (observability + security for AI agents):
Step 1 — Positioning copy (for your landing page hero)
> "Splyntra traces every agent run, scores it for risk, and ships nothing sensitive. One OpenTelemetry pipeline — execution tracing, cost analytics, secret/PII redaction, prompt injection detection, all in one."
Step 2 — Hacker News launch comment (Show HN)
> "We built Splyntra because our AI agents were leaking secrets in traces and we had no single place to catch it. It wraps your existing OTel pipeline — no new SDK, just plug in. Risk scores surface in real time. Happy to share the architecture if anyone's curious."
Step 3 — Reddit r/MachineLearning post
> "Anyone else drowning in agent traces with zero security signal? We just open-sourced the core of Splyntra — OTel-native, self-hostable, covers PII redaction + prompt injection detection. Curious what your current stack looks like."
Step 4 — Cold outreach (for dev tool / AI infra buyers)
> "Subject: your agents are probably leaking more than you think — Hi [name], saw you're building on [LangChain/CrewAI/etc.]. Splyntra adds risk scoring to your existing OTel traces — no rip-and-replace. Happy to show you a 5-minute demo."
Zarek built all of this in one session, kept context across edits, and scheduled the sequence automatically.
If you want to run it on Splyntra: [zarek.tech](https://zarek.tech) — or reach out directly at wangc2016217@gmail.com.
Running agents in production solo (research and publishing pipelines that touch email, web posting, and storefront ops), so here's one indie data point for your governance question.
The audit ledger mattered to me before any attacker did. The scariest thing I've caught wasn't an injection - it was my own injection-detection layer silently degrading to a handful of built-in rules after a config load failure. Every report kept saying "none detected" for weeks. Healthy and broken produced identical output. What ended it was making detector health part of the output itself: every report now prints how many rules are actually loaded. If a risk score can fail quietly, the score becomes the risk - so I'd surface detector/policy health as a first-class metric next to the per-run score.
On debugging when things go sideways: my working question isn't "what did it do" but three - can I stop it, can I undo it, can I prove what happened. Traces give you the third. The first two are policy: a kill switch and an explicit reversibility boundary (what runs autonomously vs. what waits for a human click). That's the part of governance indies actually feel. Big orgs buy audit for compliance; solo operators need it for sleep.
Pricing thought: keep the policy engine in the free self-hosted core. It's what builds the daily habit your paid tier depends on.
The OTel-native approach is a smart default: it lowers the switching cost and lets teams reuse existing instrumentation. For the indie tier, I'd lead with 'what did my agent actually do and how much did it cost' before calling it governance.
The “trace + risk in the same view” approach makes a lot of sense, especially once agents start touching real data and tools. I’m also curious whether solo builders will actually pay for the governance side, or if they’ll mostly come for debugging and cost visibility first.
As you think about the indie/early stage segment, it might also be interesting to hear from small teams that are building with a couple of interns or junior engineers. That’s often where keeping agent systems observable becomes messy pretty quickly.
Yeah, that matches what I'm expecting too I think governance ends up being something people grow into rather than something they show up for. Nobody's first Splyntra session is "I need a policy engine." It's "why did this run cost 4x normal" or "what did this thing actually call." If governance earns its keep, it'll be because those same debugging habits scale up once there's more than one person touching the agent.
Which ties directly into your second point the intern/junior-engineer team is actually a really good lens I hadn't weighted enough. That's probably where things get messy faster than at a solo-dev or a 50-person company, not slower: you've got someone less familiar with the codebase iterating on prompts and tool wiring, nobody's necessarily reviewing every change, and "wait, why did the agent do that" becomes a daily question instead of a rare one. That's arguably the sweet spot for "here's exactly what changed and what it touched" mattering way before anyone's thinking about RBAC.
Might reach out if you or anyone you know is running agents with a team like that real "here's where it got confusing" feedback from that stage would be more useful to me right now than most enterprise conversations. Appreciate you pushing on this.
The combination of observability and security makes the product broader than a typical agent tracing tool. I’m curious which side users actually come looking for first.
Honestly, it's been more evenly split than I expected going in. A good chunk of people find us because something already broke a cost spike, a weird tool call, a "wait, did our agent just leak something" moment and security is the front door. Others come in the boring way, just wanting decent tracing because their current setup is print statements and vibes, and the risk scoring is something they notice a week later and go "oh, that's actually useful too."
What's been interesting is that almost nobody stays single-purpose once they're in. The tracing people start caring about risk the first time a score flags something they'd have missed. The security-first people end up living in the trace view because that's where the "why" actually lives. Which honestly reinforces why we didn't want to ship these as two products the entry point varies, but the value converges pretty fast once you're looking at real runs.
That’s a useful signal. The fact that the entry point differs but the value converges makes the positioning more interesting.
This comment was deleted 14 days ago
Really appreciate this you've basically articulated the thesis better than my launch post did 😅
You're spot on about incidents. That was the actual "aha" moment for me I kept seeing postmortems where the trace and the security finding lived in two different tools, so someone had to manually stitch "this tool call looks weird" to "and here's what it cost us" to "oh, and this is the injected instruction that kicked it off." Once you see enough of those, treating them as one pipeline stops feeling like a nice-to-have and starts feeling obvious.
And yes completely agree on governance. I don't think a solo dev wakes up wanting "policy engine," they wake up after something weird happens and want "what did my agent actually touch, why did it do that, and what did it cost me." The audit ledger and delegation stuff is really the same primitive as debugging, just pointed at a different question. If it only feels compelling once you're 50 engineers deep, we've probably over-built it for the wrong stage of company.
On self-hosted vs. managed: my rough rule so far is that anything about your own data traces, detectors, evals, the redaction pipeline stays fully powered in self-hosted, free, forever. What's cloud-only is stuff that's genuinely painful to run yourself: SSO/identity, cross-project policy at org scale, the always-on infra for advanced detectors. Still actively figuring out where that line should sit, honestly if you have a strong opinion on where it shouldn't sit, I'd take that feedback seriously.
Thanks for actually engaging with the "why," not just the feature list.