Start in monitor mode, where the agent records what it would block without interfering. Review those events with the application owners, tune out false positives, then switch to block mode one attack category at a time. Going straight to block risks turning a security tool into an outage.
Why false positives are the main risk
OWASP's virtual patching guidance names avoiding false positives as the top priority for protective rules, and says rules should also avoid false negatives. A blocked legitimate request is a failed checkout or a broken login. Users do not care that the cause was well intentioned.
The same logic applies to any control that sits in the request path and can say no. Monitor mode is how you learn what your real traffic looks like before the control has any power over it.
A four stage rollout
- Observe. Deploy to a non-critical service in monitor mode. Collect events for at least one full business cycle, including month end or batch jobs if your app has them.
- Review. Sit with the owning team and sort events into real attacks, scanner noise, and legitimate behavior that looked odd. Write down the reason for each decision.
- Tune. Add narrow exceptions for the legitimate cases. Prefer specific exceptions over broad ones, because broad ones become holes.
- Enforce. Turn on blocking for the category with the cleanest data first. Keep the others in monitor mode. Watch error rates and support tickets for several days.
Then repeat for the next category and the next service.
What to decide before you start
| Decision | Why it matters |
|---|---|
| Who gets the alert | An alert nobody reads is monitor mode forever |
| Who can switch a rule off | During an incident you need a fast, accountable override |
| What counts as success | Define the false positive tolerance in writing |
| What happens when the agent fails | Fail open or fail closed changes your outage profile |
The last row deserves a direct question to any vendor. The Java instrument documentation notes that a startup agent which cannot load aborts the JVM, while an agent attached later fails quietly. Ask what the product does in your runtime.
Keep a rollback ready
Every enforcement change should have a one step rollback, tested before you need it. A feature flag, an environment variable, or a console toggle all work, as long as the on call engineer knows where it is.
Measure the rollout
Track blocked requests, confirmed true attacks, false positives reported by users, and time to override. A rising false positive count after enforcement is a signal to step back, not push through.
A worked example: a login endpoint
Consider a hypothetical login service that has run for years. In monitor mode, the agent flags several requests containing unusual characters in a username field. Reviewing them with the owning team, you find three groups: a handful of real probing attempts, a batch from an old mobile client that sends a particular character sequence legitimately, and traffic from the company's own scanner.
If you had enabled blocking on day one, the old mobile client would have failed to log in, and support tickets would have arrived before anyone understood why. Because you used monitor mode, you write a narrow exception for the mobile client, label the scanner traffic, and enable blocking for the real attack pattern. The control now does its job and the old client keeps working.
What a review meeting looks like
Keep the review short and structured. Bring a list of event groups with counts, the rule that fired, and a sample request for each. The owning engineer answers one question per group: is this legitimate behavior? Record the answer and the action. Aim to leave each meeting with a smaller unknown pile than you started with. When the unknown pile is empty for a category, that category is ready for blocking.
Exit criteria for each stage
| Stage | Exit criterion |
|---|---|
| Observe | A full business cycle of data collected |
| Review | Every event group labeled by the owning team |
| Tune | No unexplained legitimate traffic in the category |
| Enforce | Error rates and tickets stable for the agreed period |
Write these criteria down before starting. Otherwise the temptation is to advance on schedule rather than on evidence.
Communicating the change
Tell support and on call engineers when enforcement begins, which categories are on, and how to reach the override. A short note in the team channel is enough. Surprises are what turn a reasonable control into a hated one.
Handling seasonal and rare traffic
Some traffic appears only a few times a year, such as tax season exports, holiday sales, or quarterly reports. A monitor period that skips those events will miss behavior that blocking could break. Ask the owning team for a calendar of unusual events, and either extend monitoring through one of them or keep the relevant categories in monitor mode until it passes. Mark the calendar in the rollout document so the next team does not rediscover the same lesson.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a policy can start permissive and become stricter. Your RASP rollout follows the same shape: observe first, then enforce once the data supports it.
Quick check
How long should monitor mode run?
Long enough to see your normal traffic patterns, including rare jobs. Many teams use a full business cycle, but pick a period based on your own calendar.
Can I block some attack types and only monitor others?
Usually yes, and it is the sensible path. Check that your product supports per category modes.
What if monitor mode shows almost no events?
Check that the agent is working and that the traffic reaches it. Quiet can mean a healthy app, or it can mean the agent is not seeing requests. Trigger a harmless test event to find out.
For a decision on whether you need RASP at all, see IAST versus RASP. Safeguard's free scan at gold.safeguard.sh/scan can show the dependency risk behind many of the attacks a runtime control would watch for.
Sources
Last reviewed: 19 October 2026.
