Quick answerOnce a jailbreak or prompt-injection technique is confirmed working against your production AI agent, whether it surfaced through a bug bounty submission or any other channel, you need a written internal SLA that starts the clock at confirmation and commits to a patch-or-mitigate time by severity, with an explicit rule that a security vulnerability cannot simply be "rolled back" the way a quality regression can, because the exploit may have existed in whatever version you'd roll back to. This is a narrower and different question from how to structure an ongoing external bug bounty program, which is about the program that surfaces findings and rewards researchers, and from red-teaming an agent before launch, which is adversarial testing that happens before anything ships. This is about the clock that starts the moment a real finding lands on your desk, regardless of where it came from.
Why a security SLA is not the same clock as a regression SLA
How Fast Must You Actually Ship a Fix Once an AI Agent Regression Is Confirmed? covers the general case well: severity tiers, rollback authority, and an escalation path when the clock is missed. A prompt-injection or jailbreak vulnerability deserves its own SLA rather than folding into that general framework, for three specific reasons. First, the exploit window is actively adversarial, not passively degrading; every hour unpatched is an hour a motivated attacker could be actively using the technique, not just an hour of quietly worse output. Second, rollback often isn't an option, since the vulnerable behavior frequently exists across multiple recent versions or is a property of the base model and system prompt structure rather than a single bad deploy. Third, a security finding usually comes with a disclosure clock attached, whether from a bug bounty researcher's own responsible-disclosure timeline or an internal red-team's reporting norms, and that clock runs independently of your internal remediation pace.
Setting the severity tiers for exploit risk, not output quality
Tier by what the exploit can actually accomplish, not by how clever the prompt was. A jailbreak that gets the agent to produce off-brand or embarrassing text is a real problem but a lower tier than one that gets the agent to leak system prompt contents, bypass a financial or refund guardrail, or execute an unauthorized tool call. The top tier, anything that breaches a guardrail with real-world consequences, should carry a same-day mitigation target even if a full root-cause fix takes longer; a same-day mitigation can mean a narrow input filter or a temporary tightening of the affected capability, deployed as a stopgap while the real fix goes through normal review.
Mitigate first, root-cause second, and say so explicitly
The instinct to hold a patch until it's the "real" fix, not a band-aid, is understandable and wrong under this specific SLA. A narrow, ugly patch that closes the specific exploited path today, followed by a proper fix next week, is the correct sequencing, and the SLA should explicitly authorize shipping the ugly patch without waiting for review cycles that a normal feature change would require. Document both moves as separate line items so the record shows the actual mitigation timeline, not just the eventual clean fix date.
Verification testing has to include a repeat of the exact exploit
Closing a vulnerability ticket should require re-running the exact reported technique against the patched version and confirming it no longer works, not just confirming that a general safety eval score moved in the right direction. Prompt-injection fixes in particular are prone to being technically correct against the reported phrasing while leaving a nearly identical rephrasing untouched; budget time in the SLA specifically for a researcher or internal red-teamer to attempt at least two or three variations of the original technique before marking it resolved.
Coordinating with the researcher's own disclosure clock
If the finding came through a bug bounty channel, the researcher's own responsible-disclosure timeline, commonly 90 days in security research norms, is running in parallel with your internal SLA regardless of what your internal target says. Acknowledge the finding and give the researcher a real patch-timeline estimate early, since researchers who feel stonewalled are far more likely to consider public disclosure once their own clock runs out. This coordination step deserves its own line in the SLA document, not just a mention in the bug bounty program's terms.
Who has authority to ship outside the normal release cadence
Exactly like the general regression SLA, live-argument-during-an-incident is the most common reason security fixes slip past target. Name, in advance, who can approve an out-of-cycle security patch without waiting for the next scheduled release window, and make sure that person has both the technical context to move fast and enough seniority to not need to check with someone else first.
FAQ
Does this SLA apply to findings from automated scanning tools, not just human researchers or red-teamers? Yes. The clock starts at confirmation of a real, working exploit, regardless of whether a person or a tool found it. Automated findings still need human verification before the clock starts, since automated scanners produce false positives, but once confirmed, the same tiers and timelines apply.
Should the same SLA apply to vulnerabilities found during internal red-team exercises before launch? The pre-launch red-team process itself is a separate discipline covered by red-teaming before launch, but any vulnerability it finds in an already-shipped feature, versus a not-yet-shipped one, should route through this same post-confirmation patch SLA rather than being treated as pre-launch findings with no urgency clock.
What if the fix requires a model provider change outside your control? Treat the interim mitigation, such as tightening your own system prompt or adding an input filter, as the thing the SLA measures, while tracking the upstream fix separately with its own expected timeline from the provider. Don't let an external dependency reset your internal mitigation clock to zero.
How does this interact with the reward paid to the researcher who found it? The patch-response SLA and the bug bounty reward structure are separate decisions; a fast internal patch timeline is good practice regardless of what you decide to pay, and shouldn't be used as a substitute for a fair reward under the program's own published scope and severity table.