Several claims about IAST and RASP are partly true and mostly overstated. Agents rarely need code changes, but they do need tests, tuning, and ownership. Neither technique gives zero false positives or complete coverage. This post checks six claims against primary documentation.
Myth 1: "No code changes means no effort"
Partly true. On Java, an agent instruments bytecode as classes load, so source stays as is. Oracle's documentation describes this mechanism. You still change launch configuration, build images, and manage a privileged component.
Myth 2: "IAST finds everything"
False. OWASP defines IAST as testing while the app is exercised by tests, a person, or other activity. Code that never runs is never observed. A clean result from thin tests proves little.
Myth 3: "It gives zero false positives"
Overstated. OWASP notes that static tools lack runtime visibility, and runtime sensors can have stronger evidence. Evidence is not infallibility, and sensor quality varies. Measure on your code.
Myth 4: "RASP means you do not need to patch"
False. OWASP describes protection layers that block exploitation of known flaws as work-arounds that buy time until source code fixes are implemented. They should be tracked and retired. See RASP is not a substitute for fixing.
Myth 5: "Install it once and forget it"
False. Agents need updates. Rules need review. Findings need triage. Exceptions need expiry dates. Oracle's documentation also notes that whoever deploys an agent is responsible for verifying it is trustworthy.
Myth 6: "A runtime agent cannot be bypassed"
Unproven. Any in-process control shares a process with the code it watches. Python's documentation, for its own audit hooks, states they are not a sandbox and malicious code can trivially bypass them. That is about Python's built in mechanism, not a product, but the principle is worth asking vendors about.
Summary table
| Claim | Verdict | What to ask |
|---|---|---|
| No code changes | Mostly true | What changes in launch and deploy? |
| Finds everything | False | How is coverage measured? |
| Zero false positives | Overstated | Show precision on our code |
| Replaces patching | False | How are shields tracked and expired? |
| Set and forget | False | Who owns updates and rules? |
| Cannot be bypassed | Unproven | How does it resist tampering? |
How to use this list
Bring the right column into vendor calls and trials. A good vendor will answer plainly, including about limits. A vendor that insists the myths are facts has told you something useful.
Why these myths persist
Most of these claims start from something true. Agents really do avoid source changes. Runtime evidence really is richer than static guesses. Protection layers really do reduce exposure. The overstatement happens when a narrow truth is stretched into a promise about outcomes. Reading the primary documentation, running your own trial, and asking for limits in writing are the simplest ways to separate the narrow truth from the stretched version.
Using the list in a vendor meeting
Turn each myth into a neutral question. Instead of asking whether the product has false positives, ask how many findings your own developers called real in your trial and how that was measured. Instead of asking whether it replaces patching, ask how shields are tracked and retired. Questions framed this way are harder to answer with slogans and easier to compare across vendors.
A worked example: reading a claim
Suppose a data sheet says the product finds vulnerabilities with no code changes and no false alarms. Break it into parts. No code changes is plausible for agent based tools, and you can verify it in a trial. No false alarms is a strong absolute and should prompt a request for evidence from environments like yours. The sentence mixes a checkable claim with an unchecked one, which is common. Verify the first, discount the second, and move on.
Evidence you can collect yourself
| Claim | Your test |
|---|---|
| Easy to deploy | Time the install and count configuration changes |
| Accurate | Have developers label findings from your code |
| Low overhead | Run the same load test with and without |
| Replaces patching | Check how the tool tracks shield expiry |
| Safe to run | Break the agent on purpose and observe |
When a vendor answers well
A good answer states a limit. It says things like our coverage depends on your tests, or our protections should be paired with fixes. Vendors who volunteer limits are easier to trust, because you can plan around what they tell you.
A short reading list approach
If you want to go deeper, start with primary documentation. Read the OWASP pages on interactive testing and virtual patching, and the documentation of your own runtime's instrumentation or audit features. They are short, written for practitioners, and free of sales language. After that, read vendor material with a clearer sense of what is a standard idea and what is a product specific claim.
Keeping the list current
Products change, and so do claims. Review this list when you renew or evaluate a tool, and update it with what you learn from trials. Add your own entries as you meet new claims. A living internal list is a cheap way to keep institutional memory when staff change.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and see how a claim about a finding is checked against evidence. Treat vendor claims the same way: ask what would show it is true.
Quick check
Is IAST worth it despite the limits?
For many teams, yes, particularly for critical services with strong tests. The limits just shape where and how you use it.
Where can I see the primary documentation?
The sources below link to OWASP, Oracle, and Python pages used for this post.
Are all claims in vendor material myths?
No. Many are accurate within their stated scope. The skill is separating the scope from the stretch.
Compare the methods in SAST, DAST, IAST and SCA compared. Safeguard's free scan is at gold.safeguard.sh/scan.
Sources
- OWASP DevSecOps Guideline: Interactive Application Security Testing
- Oracle: java.lang.instrument package
- OWASP: Virtual Patching Best Practices
- Python docs: sys.addaudithook
Last reviewed: 19 October 2026.
