Image Safety Filters: Why Your Benign Request Was Blocked
6 min read · updated August 3, 2026
A blocked request with a generic policy message is one of the more frustrating things an API can return, because it tells you nothing about which of several independent systems objected. Knowing the architecture makes the refusal diagnosable, and knowing which benign categories are hardest for a classifier makes it predictable.
A block happens at one of four stages
- Prompt classification, before generation. A text classifier reads your prompt. This is the fastest refusal — it arrives in well under a second, before any image was made, and it is the one that responds to rewording because the input it judged was your words.
- Input image screening, for edits. An edit request carries an image, and that image is screened independently of the prompt. A perfectly ordinary instruction can be refused because of what the source photograph contains.
- Output classification, after generation. The image was produced and a vision classifier objected to it. Diagnostic signature: the refusal takes as long as a successful generation, and you are sometimes still billed. Rewording helps only insofar as it changes what gets drawn.
- Account or policy layer. Rate limits, region restrictions, or an org-level policy. Distinguished by being consistent for everything rather than specific to one prompt.
Latency is therefore your best free diagnostic. Log the time to refusal alongside the error code — an instant refusal and a slow one are different systems and need different responses in your UI. Where the API returns a category (content_policy_violation and its equivalents, sometimes with a subcategory), log that too and count the distribution weekly; the shape of your refusals is a fact about your product that nobody else can tell you.
Benign requests that trip classifiers
Classifiers are tuned to be cautious on categories where the cost of a miss is high, and caution shows up as false positives on the legitimate neighbours of those categories. The recurring ones:
| Category | Description |
|---|---|
| medical and anatomical | Clinical illustration, dermatology reference, surgical diagrams. Adjacent in feature space to nudity, which is heavily filtered. |
| art history | Classical sculpture and Renaissance painting are full of nudes. Requests to reproduce or pastiche them are a standing false-positive source. |
| tools that are also weapons | Kitchen knives, axes, hunting and agricultural equipment. Product photography for a hardware retailer runs into this constantly. |
| named real people | Often refused as policy rather than as a mistake — likeness rights and impersonation are the concern, and this is usually a deliberate line rather than a classifier error. |
| children in ordinary contexts | A schoolbook illustration or a family scene. This filter is intentionally the most conservative in any stack and it is right to be. |
| brands and trademarks | Logos and recognisable product designs, blocked for intellectual-property reasons rather than safety ones. |
| conflict and history | Historical education material about wars, uniforms and events sits next to violent content in feature space. |
| innocent homonyms | 'Shoot a portrait', 'kill the lights', 'a shot of whisky'. A text classifier working on surface features can object to the word rather than the meaning. |
Clarity is not evasion
There is an important line to hold here, and it is worth stating plainly. If a request is genuinely against a provider’s policy, the correct response is not to find a phrasing that gets it through. The filter is not the policy; the policy is the policy, and a request that succeeds by obfuscation is still a violation of the terms you agreed to — as well as, in most cases, a thing you should not be generating.
What is legitimate is removing ambiguity so a classifier can tell that a genuinely benign request is benign. Those are different activities and they are easy to tell apart: one adds information, the other removes it.
- State the context. “A labelled anatomical diagram of the shoulder joint for a physiotherapy textbook” carries more of what the classifier needs than a bare anatomical term. You are adding true detail, not hiding intent.
- Prefer the technical register. Clinical and professional vocabulary is less ambiguous than colloquial vocabulary, and ambiguity is what a cautious classifier resolves against you.
- Replace an accidental homonym. “Photograph a portrait” rather than “shoot a portrait” is a clarification of what you meant.
- Describe a type, not a person. Where likeness is the issue, “a woman in her sixties with short grey hair” is a different request from a named individual — not a workaround for the same one.
Designing a product that gets refused
If image generation is user-facing, refusals are not an edge case; they are a routine response your interface has to handle well. Four things separate a product that copes from one that does not.
Never surface the raw provider error. “Your request was flagged by our content policy” leaves a user who asked for a picture of their dog feeling accused. Something plainer — that the request could not be completed, with a suggestion to add detail about the context — is both kinder and more actionable.
Preserve the user’s work. A refusal that clears the prompt box is a second, self-inflicted failure. Keep the text, keep any uploaded image, and let them edit.
Track the rate as a product metric. A refusal rate that jumps overnight usually means a provider changed a threshold, not that your users changed. Without the metric you learn it from support tickets a week later.
And decide in advance what happens on refusal. For some products a fallback to a different model is right, and it is worth knowing that two hosts serving the same open-weight model may apply entirely different moderation stacks — the filter is part of the deployment, not part of the weights. For others, silently retrying elsewhere is exactly the wrong behaviour, because the first refusal was correct. That is a policy decision for your product and it should be made deliberately, once, rather than by whoever writes the retry loop.