Everyone Was Wrong About Agentic AI and Application Security

How It All Started

A year ago, my co-founder Matan called me with a question that should have been easy to answer.

“How is it still so easy to hack modern web applications in 2024?”

I didn’t have a good answer.

I’d spent most of my career on the offensive side of application security – pentester, vulnerability researcher, eventually CTO. My job was simple and endlessly fascinating: breaking into systems no one had broken into before. I was good at it. And if you’d asked me why attackers always seemed to have the upper hand, I would have given you the standard explanation: asymmetric warfare. Attackers only need to find one way in. Defenders need to protect everything.

But sitting with Matan’s question, that answer felt hollow. It was lazy thinking disguised as wisdom. So I started asking a different question: why is it still so easy to break modern applications?

The Uncomfortable Truth

We began examining how AppSec tools actually work. Not the marketing promises – the actual mechanics of what they do.

SAST tools analyze your code and flag potential vulnerabilities. But they’re analyzing static code without knowing what actually runs in production. They don’t know your architecture, your deployment patterns, or which code paths are even reachable. SCA tools scan your dependencies and alert you to known CVEs. Sounds great until you’re getting paged at 2 AM about a CVSS 10 vulnerability in a library you imported three years ago, and you spend the next five days trying to figure out if the vulnerable code path is even used in your application.

API security tools monitor traffic patterns. But they don’t understand what your application is supposed to do, so they’re essentially pattern-matching against theoretical threats. Every single tool was making educated guesses. Every single tool was treating the application as a black box. And then it hit us: we’ve been solving the wrong problem for 25 years.

The Missing Piece

The entire AppSec industry has been built on guesswork. We’ve gotten very sophisticated at guessing – better algorithms, more data, fancier machine learning models. But we’re still fundamentally guessing because we’re missing the one thing that would make guessing unnecessary: context.

Security tools don’t know what your application actually does. They don’t see the relationships between libraries and APIs. They don’t understand which user interactions trigger which code paths. They don’t know which resources are accessed or how data flows through your system. They can’t tell you with certainty whether a vulnerability matters because they don’t know if the vulnerable code ever executes.

The result? Vague metrics. Overwhelming noise. Midnight panic calls from Dan in SecOps about vulnerabilities that might not even be relevant. Security teams drowning in alerts, spending more time investigating false positives than addressing real threats. This is why AppSec has been unsolved for 25 years. This is why the asymmetry between attackers and defenders persists. Not because the problem is fundamentally unsolvable, but because we’ve been missing the foundation everything else should be built on.

What If We Could See Everything?

Here’s the thing: the industry knew this. Everyone knew we needed context.

For 25 years, companies have been chasing complete runtime visibility. RASP solutions tried with instrumentation. IAST tools attempted it through agents. Network solutions relied on proxies. More recent approaches experimented with eBPF. They all understood what was needed. They just couldn’t figure out how to actually get there.

Instrumentation adds overhead and changes application behavior. Proxies only see what crosses network boundaries. eBPF gives you kernel visibility but can’t understand application semantics. Agents are fragile and break with every framework update. Every approach was constrained by its fundamental architecture. They were all variations of the same thinking, hitting the same walls.

We weren’t the first ones to want complete runtime context. We’re the first ones successfully achieving it. To get there, we had to stop thinking about traditional approaches entirely. No proxies. No eBPF. No hooking. No instrumentation. Something completely new. What if we could see everything the application does, 100% of the time, without any of the compromises that held back previous attempts? What if we knew every user interaction, every resource accessed, every AI agent, every library call, every API integration – with zero performance impact and zero application modification? This became our north star. And we built something the industry said couldn’t be done.

Building the Solution

Everyone who tried to solve this problem made the same mistake: they tried to sit inside the application or between the application and its resources. Agents inject themselves into the application runtime. Instrumentation modifies your code. Proxies intercept network traffic. eBPF observes at the kernel level but loses application context. They all thought the answer was to get closer to the application – to hook into it, instrument it, intercept its calls, or wrap its functions.

They were all wrong.

The breakthrough came from asking a different question: what if we observed from the outside, at the boundary where the application interacts with the operating system, and correlated that with runtime context without ever touching the application itself? We built Rein to operate at the OS boundary, observing system calls as they happen. When your application opens a file, makes a network request, or accesses a resource, we see it. But unlike eBPF solutions that only see the syscall, we capture the full execution context – which HTTP request triggered it, which API endpoint was called, which library invoked it, the complete stack trace.

We don’t inject code into your runtime. We don’t modify your application. We don’t hook your functions. We don’t intercept your requests. We don’t even sit on your execution path. We observe behavior at the OS boundary and correlate it with runtime-exposed signals – information already emitted by the environment without requiring any cooperation from the application itself. The result is complete visibility with zero interference. We see every operation your application performs in real time, with full context about what triggered it, which code path executed it, and which resources it accessed. And we do it with sub-millisecond latency and negligible CPU overhead.

When a new CVE drops, we don’t guess whether it affects you. We know exactly which parts of your application use the vulnerable code path and whether it ever executes in production. When a library is compromised, we can tell you instantly which APIs call it, which users trigger it, and which resources it accesses. When an AI agent makes a request, we see the entire chain: which user initiated it, which model processed it, which APIs it called, which data it accessed.

We’ve unified AI Security, API security, SCA, and SAST around this single source of truth. Everything is grounded in what actually happens at runtime, not what might theoretically happen in some scenario someone tries to model. And because we operate outside the application’s execution path, our customers can enable and disable Rein with a single click in our portal. No restart required. No redeployment. No cooperation from the application needed.

The Revolution

Our customers don’t have to imagine what it’s like to not worry about AppSec. They’re living it. They have actual visibility. Real control. Deterministic answers instead of probabilistic guesses. This is the disruption the industry has needed for 25 years. Not incremental improvements to guessing. Not better models of theoretical behavior. Complete visibility into actual behavior. It’s time to stop guessing. It’s time to start knowing.

It’s time to finally solve AppSec.