Share it. Security should own the policy and the alerts, platform engineering should own deployment and the agent lifecycle, and application teams should own the false positives and fixes. One team doing all three tends to either break production or ignore the tool.
Why ownership is harder than for a scanner
A scanner runs on the side. A runtime control sits in the request path of live applications. It can block users, slow requests, and fail at bad moments. That puts uptime in the same sentence as security, so the usual "security owns the tool" model does not fit.
A workable split
| Duty | Owner | Why |
|---|---|---|
| Policy: what to block and when | Security | Defines risk tolerance |
| Alert triage and incident response | Security with on call | Knows attack patterns |
| Agent deployment, upgrades, base images | Platform engineering | Owns the runtime |
| Performance and failure behavior | Platform engineering | Owns uptime |
| False positive review | Application team | Knows legitimate behavior |
| Fixing the underlying flaw | Application team | Owns the code |
| Exceptions and expiry | Security approves, app team requests | Keeps shields temporary |
Write down the escalation path
When the agent blocks a legitimate request at 2 a.m., who can turn the rule off, and how fast? Decide in advance. An accountable override that is easy to use beats a heroic search for the one person with console access.
Link it to the vulnerability process
OWASP describes protective rules like virtual patches as temporary measures that should be tracked in patch management and reviewed for removal when the code is fixed. Make that real: every shield gets a ticket, an owner, and an expiry date. Security reviews the list on a schedule.
What to put in the runbook
- How to confirm the agent is running.
- How to switch each protection between monitor and block.
- Who to page for false positives.
- What fail open or fail closed means for each tier. See failure behavior.
- How to retire a rule.
Signs ownership is broken
- The agent runs a version nobody has updated in a year.
- Alerts go to a mailbox nobody reads.
- Rules were added during an incident and never reviewed.
- Application teams do not know the tool exists until it blocks them.
Starting small
If you are rolling this out for the first time, do not try to define the perfect operating model. Choose one service, name one person from each of the three groups, and meet weekly for a month. Capture what broke, what was confusing, and what you would change. Then turn those notes into the runbook and the ownership table. A model tested on one service is more believable to other teams than a policy handed down from above.
A worked example: a blocked partner request
A partner integration begins failing at night. The agent blocked a request containing a pattern that looked like an injection but was actually a legitimate field format. The on call engineer sees errors, finds the agent's event, and uses the documented override to move that rule to monitor mode. Security reviews the event the next morning with the owning application team, confirms it was legitimate, and writes a narrow exception with an expiry date.
Notice who did what. Platform engineering made the override possible. The application team supplied the knowledge. Security owned the policy and the follow up. No one person needed to know everything.
RACI style summary
| Activity | Responsible | Accountable | Consulted |
|---|---|---|---|
| Define blocking policy | Security | Head of security | App teams |
| Deploy and upgrade agents | Platform | Head of platform | Security |
| Review false positives | App team | Engineering manager | Security |
| Approve exceptions | Security | Head of security | App team |
| Retire shields after fixes | App team | Engineering manager | Security |
Metrics each group can own
Security can track confirmed attacks and the age of open shields. Platform can track agent version spread and failure incidents. Application teams can track false positives per release and time to fix flaws that shields cover. Shared dashboards make the trade offs visible to everyone.
Staffing and skills
Running a runtime control takes a particular mix of skills: reading attack patterns, understanding application behavior, and operating production systems. Few individuals have all three. Pair a security engineer with a platform engineer for the rollout, and bring in an application developer for each service. Cross training pays off over time, since each group learns what the others worry about. Plan for turnover by documenting decisions, not only configurations.
Onboarding a new service
When a new service joins the program, give its team a one page checklist: confirm the agent is in the base image, run in monitor mode first, name a false positive reviewer, record the fail open or closed choice, and add the service to the shield register. A short repeatable checklist means the tenth service takes a fraction of the effort of the first, and keeps the three groups aligned without extra meetings.
Try it yourself
Click through it at your own pace, or open it full screen.
See how findings move through statuses and owners. A shield should be tracked in the same way, with an owner and a date for removal.
Quick check
Should developers be able to disable RASP rules?
They should be able to request a change quickly. A narrow, logged override path is safer than unrestricted access.
Is RASP a security tool or an operations tool?
Both. That overlap is the reason to share ownership explicitly.
Who is on call when the agent causes an incident?
Platform engineering usually carries the first page because it owns the runtime, with security on the escalation path. Write that down before you enable blocking.
For rollout steps, see monitor mode versus block mode. Safeguard's policies, gates, and guardrails follow a similar owner and exception model for dependency risk, and a free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
