Prompt injection recurrence rate is a measurement of how often the same underlying injection vector, or a semantically modified variant of it, succeeds against an AI agent after it was previously detected, blocked, or otherwise mitigated. It is expressed as a rate over a defined observation window, such as a rolling 30 or 90 day period, rather than as a raw count of incidents.
OWASP's Top 10 for LLM Applications classifies prompt injection (LLM01) as manipulation of LLM inputs to alter intended model behavior, distinguishing direct injection, where an attacker supplies malicious input directly, from indirect injection, where malicious content is delivered through external sources such as retrieved documents, web content, or tool outputs. NIST's adversarial machine learning taxonomy (AI 100-2e2023) situates prompt injection within a broader class of integrity-violating attacks that adapt over time in response to defensive measures, which is the underlying reason recurrence, not just initial detection, matters as a security signal.
Recurrence Rate vs. Detection Rate vs. Block Rate
Detection rate answers whether an injection attempt was identified at the moment it occurred. Block rate answers whether a detected attempt was prevented from executing or influencing agent behavior. Neither metric, on its own, indicates whether the underlying attack vector has been durably neutralized or whether it will reappear in a paraphrased, encoded, or otherwise obfuscated form in a later session.
Recurrence rate closes this gap by tracking repeated or modified occurrences of the same attack vector across sessions, users, or tool calls over time. This distinction matters operationally: a security program can report a high block rate while still experiencing a high recurrence rate if attackers are successfully varying payloads to bypass exact-match detection logic. NIST AI RMF 1.0 supports this framing through its Measure function, which calls for ongoing quantitative tracking of identified risks rather than reliance on point-in-time assessments alone.
Role of Runtime Policy Enforcement in Reducing Recurrence
Runtime policy enforcement and tool-call governance contribute to recurrence reduction when they change the conditions that allowed an attack vector to succeed in the first place, rather than only flagging individual instances. Mechanisms such as tool approval workflows, least privilege agent permissions, and output filtering at the point of tool invocation can reduce the surface area available to an indirect injection delivered through a retrieved document or tool response, even if the injection attempt itself is not perfectly detected on every occurrence.
Trussed AI applies runtime policy enforcement, agent identity and permissions controls, and audit logging within AI agent runtimes as part of a broader runtime governance approach, with the aim of constraining what an agent can execute even when an injection attempt is not caught at detection time. Any claim that a specific control reduces recurrence should be substantiated by comparing recurrence rate before and after the control was applied, using the same measurement window and matching methodology.
Implementation Considerations Before Building the Metric
Teams building recurrence measurement into an agent runtime should validate the following before treating results as reportable.
- Define an explicit taxonomy for what counts as the same or similar injection vector before building any calculation logic.
- Establish a consistent measurement window and reporting cadence to support trend comparison over time.
- Integrate detection, blocking, and enforcement logs into one event schema rather than maintaining separate logs per control.
- Validate that added logging and correlation does not introduce unacceptable latency in the runtime enforcement path.
- Test the pipeline against known payload variation techniques, including paraphrasing, encoding, and indirect injection via tool output.