How to Lock Out a User After Repeated Prompt Injection Attempts

Define an attempt before you count it

A lockout is only as sound as its counter. Define an attempt as a policy event, not a raw model failure. Useful signals include classifier-based screening of user prompts and retrieved or tool content, pattern matching for system prompt leakage, monitoring of outputs for signs that an injection worked, and action screening that checks each proposed tool call against the user's original intent. Record the signal type with each event so thresholds can treat them differently. A blocked tool call is stronger evidence of intent than a single low-confidence classifier hit.

Injection does not only arrive through the chat box. It can come in through tool return values, tool descriptions and retrieved documents. You need an explicit rule for whether indirect injections count against the user. A defensible default is to block and alert on the content, attribute it to its source, and count only content the user authored or supplied. The trade-off is that a user who controls a document can route attacks through it, so review that exclusion periodically against what your alerts show.

Set thresholds, windows and durations

Prompt injection has no established lockout standard, but authentication lockout offers a usable model. OWASP's authentication guidance says a lockout policy should weigh three factors: the number of failed attempts before lockout, the observation window those attempts must fall within, and the lockout duration. It also advises tying the counter to the account rather than the source IP address, so rotating addresses does not reset it.

For login attempts, accounts are typically locked after 3 to 5 unsuccessful attempts. Treat that as a starting reference, not a prompt injection benchmark. Prompt injection signals are noisier than failed passwords, so weight them by signal strength and run the policy in a non-enforcing mode first to see how many legitimate users would have been caught.

For duration, consider exponential lockout instead of a single fixed period. The duration starts very short and doubles with each further violation, which limits the cost of a false positive on the first offense while making persistence progressively more expensive.

Decide where enforcement sits in the execution path

Screening points exist at user input, model output and each proposed tool call, and injection can also enter through MCP server responses. The lockout state should be consulted at every one of these points, not only at the chat front end. Otherwise a locked-out user can still reach the same tools through an agent, an API client or another application.

Enforce the decision in the execution component, outside the model's context. OWASP's agent guidance says authorization belongs there, and NIST describes separating the logic of what an agent attempts from the systems that decide what it is allowed to do. Deterministic decisions made outside the model cannot be rewritten by injected text.

Application-layer checks have a practical limit. Each application implements its own counter and its own rules, so state diverges and coverage depends on every team getting it right. Enforcement in a shared runtime path gives one policy and one counter for all interactions that pass through it. The counter still needs an identity to key on. NIST describes agent identities as distinguishable from human users and service accounts, so decide whether an agent's attempts roll up to the user who invoked it or are tracked separately.

Control false positives, abuse and recovery

Account lockout always trades protection against denying access to authorized users. Two risks follow. The first is false positives: a legitimate user pasting an unusual document trips a classifier repeatedly. Mitigate this with weighted signals, longer observation windows for low-confidence events, and soft-blocking of specific actions before full lockout. The second is abuse: an attacker who can provoke attempts against another user's account, for example by planting injected content in a shared document, can turn the lockout into a denial-of-service path. Excluding indirect content from the counter, as described above, reduces that exposure, and so does requiring human review before a long lockout takes effect.

Recovery needs the same care as the lock. Accounts are typically unlocked after a set time, by self-service or by an administrator. If you send unlock links, make them unique and one-time so they cannot be guessed or replayed. Recovery mechanisms must also not hand attackers a bypass. For human approvals, a bare confirmation flag is insufficient. The approval must belong to the current actor and the exact tool call, be valid and unconsumed, and be checked and consumed atomically just before execution.