Why IAST Fails API Security: Observability Without Offense Leaves Apps Exposed

Buchi Reddy B

CEO and Founder at Levo

Back when I led Observability at AppDynamics as an Engineering Director, I saw firsthand how powerful runtime instrumentation could be. 

Without rewriting a single line of code, we could trace distributed transactions, surface memory leaks, and correlate performance slowdowns to business impact. 

Enterprises could finally troubleshoot production issues in real time, across sprawling microservices, with precision that had never been possible before.

That’s what made AppDynamics a category-defining product and why Cisco acquired it for $3.7 billion in 2017.

But I also saw where runtime instrumentation started to break.

It was never designed to simulate what hadn’t yet happened but only to observe what already had.

That’s the exact trap IAST falls into. 

Its security insights are tied entirely to existing application traffic.

In API-first applications where behavior is fragmented across chained services, ephemeral containers, and dynamically generated endpoints, that limitation becomes dangerous.

What IAST doesn’t see, it doesn’t test.

And what it doesn’t test, your team can’t secure—leaving critical parts of your application exposed by default, as I’ll unpack throughout the rest of this blog.

Traffic-Dependent Coverage Leaves Critical Endpoints Untested

When QA runs a login sequence or automated tests hit an API route, IAST can capture the execution trace, inspect inputs, and surface issues like injection flaws, unsafe deserialization, or misconfigurations. 

On the surface, it feels elegant: no synthetic fuzzing, no noisy crawling—just clean, in-context detection.

But all of that hinges on one condition: the route has to run.

Modern APIs rarely conform to fixed, deterministic flows. 

1. Execution paths change based on user roles, environment variables, deployment conditions, and third-party triggers. An endpoint might only be invoked by an asynchronous job.
2. A dynamic route might be constructed at runtime based on session state. A high-risk admin API might never be hit during automated testing because it's buried behind a conditional feature flag.

Consider an internal financial service that exposes a /credit-score/override endpoint used only by support agents during fraud escalations. 

Because it’s protected by role-based access and triggered only in production scenarios, it’s never executed in staging. 

IAST, relying solely on exercised traffic, sees nothing. But an attacker who gains access to staging credentials or finds the endpoint exposed in a misconfigured environment can test it directly via Postman, bypass AuthZ checks, and overwrite user data. 

As shown above, security testing just a fraction of your APIs is as good as testing none. 

In modern architectures, even a single unvalidated endpoint can become the entry point for lateral movement, data exfiltration, or privilege escalation. 

IAST focuses disproportionately on endpoints that already receive traffic—those exercised by QA, monitored by observability tools, or hit by synthetic tests.

But in security, risk isn’t proportional to traffic volume.

The APIs most likely to be overlooked: internal, deprecated, unauthenticated, or environment-specific are often the ones most vulnerable to abuse.

By ignoring these low-traffic, high-risk endpoints, IAST fails to surface zombie and shadow APIs, ignored by your teams and thus actively targeted by attackers. 

No Payload Generation = No OWASP API Top 10 Testing

Testing coverage is only half the problem.

Even for the endpoints that IAST does see, such as those exercised during QA or automation, it still doesn’t perform real security testing.

There is no active payload injection, no role substitution, and no attempt to chain calls or manipulate business logic across sessions.

IAST simply observes expected behavior and assumes the absence of failure means the absence of risk.

But real API security testing requires deliberate misuse. It involves sending invalid tokens, modifying object IDs, escalating privileges, and chaining calls across workflows to expose logic flaws.

Most of the OWASP API Top 10 vulnerabilities, especially broken access controls like BOLA and BFLA do not emerge from happy-path flows. They only surface when you actively try to break the system.

In this case:

• QA only tests the full flow with the right roles.
  
  
• IAST sees nothing wrong—because the correct user followed the correct sequence.

But an attacker intercepts the traffic, elevates their ticket manually to “High Priority” using the PATCH call, and bypasses the role check. The backend never validates user permissions at that lay

Modern APIs rely on chained workflows, token-bound identity, and session-specific context, but IAST doesn’t simulate identity changes, doesn’t reauthenticate across steps, and doesn’t track state between calls.

Despite accounting for nearly 30% of API breaches , AuthN vulnerabilities are not detected and remediated in pre-production.

Instrumentation Fragility and False Greens

IAST promises deep insight by embedding agents inside your live applications—but those agents are brittle.

Every framework upgrade, container refresh, or runtime migration risks silently breaking that instrumentation. 

The result?

Slower sprints. More time triaging agent issues than improving posture.  Higher latency from runtime hooks that don’t surface real risk.

Tests still run. Reports stay green. 

But critical execution paths are no longer being observed.

And that fragility doesn’t scale.

Engineering teams can’t afford to patch agent configurations across dozens of CI pipelines, each shipping independently. 

Security teams can’t rely on coverage that silently disappears with every refactor. 

Worse, this creates the most dangerous illusion in enterprise security: the assumption that testing is complete.

Teams only discover gaps once exploited vulnerabilities are caught in production—by then, it’s a fire drill.

Instrumentation becomes a productivity tax on developer velocity slowing it down without delivering what matters: Strong Security Posture. 

Levo: Runtime Aware, Contextual & Dynamic Offensive Testing

When we started building Levo, the goal wasn’t to passively observe behavior but to proactively validate whether your APIs could be exploited under real-world conditions.

That required simulating malicious behavior safely, before attackers ever could.

We knew coverage couldn’t depend on QA traffic, UI-driven flows, or staging environments behaving like prod.

So we built Levo to automatically generate and send precise, context-aware payloads without asking developers to simulate anything.

The result?

No tradeoffs between coverage, depth, and accuracy.

Every API is discovered. Every parameter is tested. Every call is validated.

And all of it happens before code ever reaches production.

1. Discovery That Doesn’t Depend on QA Traffic

IAST only sees what QA exercises. Levo doesn’t wait for traffic.
We continuously discover internal, external, and third-party APIs across environments without agents, runtime hooks, or code changes.

2. Documentation That Mirrors Actual Behavior

IAST relies on outdated Swagger files or incomplete traces.
Levo automatically builds and updates API documentation based on how each endpoint behaves across environments, including request structure, auth schemes, and response formats.

3. Security Testing That Actively Probes for Exploits

IAST passively watches traffic. Levo actively simulates attacker behavior.
We generate and inject thousands of exploit-aware payloads across every discovered endpoint so devs can fix before it breaks in prod.

4. Context-Aware Testing Across Roles and Calls

IAST doesn’t simulate identity shifts or test chained workflows.
Levo dynamically substitutes tokens, modifies object IDs, and chains multi-step flows to expose BOLA, BFLA, and other access control flaws without manual setup.

5. Data-Aware Risk Mapping for Every Call

IAST flags issues. Levo shows impact.
Every vulnerability is tied to the user, service, and sensitive data it touches so teams can prioritize real-world risk, not just route count.

Book a demo through this link!

‍