The Beginning
Like any good story, this one started with a run in the park.
After weeks of ideation trying to find the right problem, it suddenly clicked. I got home, called Netanel, and asked:
How come, in 2024, it’s still so easy to hack web applications?
That question became an obsession. We spent months asking “why.” Why is the AppSec market so fragmented? Why does it feel like a wedge between security and dev? And why, despite massive budgets and real effort, does AppSec still produce so much noise and so little control?
We validated this with 100+ CISOs
We took our thesis to the field. Over 100 conversations with CISOs and security leaders. The complaints were predictable: too noisy, too many false positives, low signal, siloed tools.
But what stuck with me wasn’t the frustration. It was something a CISO at a large fintech told us: “I’ve accepted that we’ll never truly know what’s happening inside our apps. We just manage the uncertainty.”
That resignation – the idea that AppSec is fundamentally about educated guessing – is what made us stubborn.
AI didn’t just change the game. It broke the old playbook.
Here’s why this story became urgent.
AI has simultaneously accelerated software development and shattered the assumptions AppSec was built on. Consider what’s happening right now:
Vibe coding is real. Developers are shipping AI-generated code faster than any human review process can absorb. The code works, mostly—but no one fully understands what it does or what attack surface it introduces.
MCPs are connecting AI to everything. Model Context Protocol servers let AI agents read your databases, call your APIs, execute code, and trigger actions across your infrastructure. Every MCP connection is a new trust boundary that traditional security tools can’t see.
Agentic applications are non-deterministic. When an AI agent decides at runtime which tools to call, which data to fetch, and which actions to take, your application’s behavior becomes fundamentally unpredictable. Static analysis of code that might run is meaningless when you need to know what actually ran.
The data confirms what practitioners already feel:
- Verizon’s 2025 DBIR: exploitation of vulnerabilities as initial access reached 20%, with median remediation time of 32 days—a lifetime in modern deployment cycles
- Mandiant M-Trends 2025: application exploits remained the #1 initial infection vector (33%) for the fifth consecutive year
- IBM’s 2025 report: $4.44M average cost per breach
Attackers operate at runtime. The cost of getting reality wrong is enormous. And AI is making “reality” harder to pin down than ever.
A real time view of what an MCP is actually doing from the Rein platform
First principles: what are we actually trying to secure?
Strip everything down and an application is a system that:
- Receives inputs: requests, events, prompts, agent instructions
- Executes code: your code, frameworks, dependencies, AI model calls
- Interacts with resources: databases, files, APIs, third-party services, MCP servers
- Produces outputs: responses, state changes, side effects, agent actions
Applications have always been dynamic. But AI adds a new dimension: non-determinism at the core. An AI agent connected to MCPs might execute completely different code paths for identical inputs. A prompt injection might hijack execution in ways that look “normal” to every external observer.
So from first principles, the AppSec question for the AI era becomes:
Can we know deterministically what executed, why it executed, and what it touched—even when the application itself is non-deterministic? And can we control that without breaking the business?
Why the traditional stack can’t answer that question
When we mapped the market, we realized something: most AppSec tools aren’t “wrong.” They’re just observing through a straw. Each captures a slice of evidence around the application—not the application itself.
- Scanners (SAST/SCA) ask: Could this code be vulnerable? Does this dependency have a CVE? But “could” scales badly when AI generates code faster than humans can review it. You get findings, triage fatigue, and developers learning to ignore the stream.
- WAF and API security operate at the edge, making decisions based on inputs and patterns, not on what the application did with them. They can’t answer: which function ran? What code path executed? What did the AI agent decide to do? They can only guess.
- Observability tools feel like truth, but they’re representations of truth, what developers chose to instrument, often sampled, often missing the exact details you need. And they offer no protection, only forensics.
- eBPF-based runtime security observes the kernel, but AppSec needs application context. At the syscall level, eBPF can’t distinguish between an AI agent legitimately querying your database and one that’s been hijacked through prompt injection to exfiltrate your user table via MCP. Both look identical: a socket connection and a database query. You’re reconstructing application reality from indirect signals, missing the correlation between request, endpoint, code execution, and impact.
The uncomfortable conclusion: AppSec isn’t failing because teams aren’t trying. It’s failing because they lack the one thing that matters – application reality.
And here’s the brutal truth for AI: if you couldn’t see inside traditional applications, you definitely can’t see inside non-deterministic AI agents calling arbitrary MCP servers. The blind spots don’t just persist. They multiply.
The turning point: stop adding layers: go after reality
We asked the first-principles question again, sharper:
If attackers win at execution time, why are defenders reasoning from approximations of execution?
The answer: because getting application-level reality has required tradeoffs production teams won’t accept. Invasive instrumentation. Heavy agents. Brittle hooks. Performance costs. Deployment complexity. So our constraint became: get real-time application context without the pain.
That is the core of Rein.
Our mission: end AppSec guesswork
Rein’s mission is simple: “End AppSec guesswork. Uncover application reality.” We mean “reality” literally: every user interaction, every resource accessed, every API invoked, every line of code executed—in dev, staging, and prod. Not by sampling. Not by proxying traffic. Not by sidecars. Not by eBPF. Rein observes every action as it executes, with 100% coverage and zero sampling.
Why Rein is native to AI security: Traditional tools were designed for a world where code was written by humans, reviewed by humans, and behaved deterministically. That world is disappearing. Rein was built for what’s coming:
- For AI-generated code: Know exactly what that vibe-coded function actually does in production—not what a scanner guesses it might do
- For MCP servers: See every tool call, every data access, every action an AI agent triggers through your MCP connections, with full context of why
- For agentic applications: Track non-deterministic execution paths in real time, understanding what the agent actually did regardless of what it was supposed to do
- For prompt injection attacks: Detect when AI behavior deviates from intent by observing execution reality, not just input patterns
Because production reality is ruthless, we anchored on another principle: visibility can’t come at the cost of trust.
Rein is a read-only, agentless visibility layer. We don’t modify, alter, or hook into your applications. And we publish real performance numbers because this is where “runtime security” usually dies: 0.1% CPU, 20MB memory, 400 microseconds per request.
Why this matters now
The boundary of “the app” keeps expanding: APIs, third-party services, dependencies—and now AI agents that can reason, decide, and act. Every MCP server you connect is a new attack surface. Every AI agent is a new trust boundary. Every piece of vibe-coded code is a new unknown.
The same first principles apply: if something can execute actions and touch resources, security needs runtime context and control. That’s why Rein spans apps, APIs, libraries, MCPs, and AI agents as a unified platform.
Back to that run in the park
We didn’t start Rein because we wanted another security category. We started Rein because we couldn’t unsee the gap: teams doing all the “right” things—buying tools, scanning code, tuning WAF rules, adding processes—and still operating without application reality.
That gap was already unacceptable for traditional apps. For AI applications, it’s untenable. Today we’re launching Rein publicly.
If you’ve felt that gap, between theoretical risk and real risk, between “we scanned it” and “we know it,” between “the AI should have done X” and “here’s what it actually did” I’d love to talk. Because the question from that park run still bothers me:
How is it still so hard to protect applications?
With AI making everything faster, more connected, and less predictable, it shouldn’t be getting harder.
It doesn’t have to be.
