An adversarial suffix is a string, frequently unreadable, that is found by optimising against a model until appending it to a request reliably triggers compliance. It is produced with gradient-based search such as GCG on open-weight models, and the resulting suffixes often transfer to other models the attacker cannot see inside. Because the trigger is a computed artifact rather than natural language, it defeats filters that look for human-readable intent. Defences include perplexity checks, input normalisation, and adversarial training, none of which fully close it.
How does an adversarial suffix work?
On an open-weight model the attacker can read gradients, so they run an optimisation (the best known is Greedy Coordinate Gradient, or GCG) that searches for a token string which maximises the chance the model starts its answer with compliance. Appended to a blocked request, that suffix pushes the model past its refusal. The strings are often nonsense to a human, and many transfer to closed models because different models share training patterns.
Why adversarial suffixes matter
This is an automated, repeatable attack rather than a clever one-off prompt, and transferability means a suffix tuned on an open model can work against a product built on a closed one. Because the trigger is not natural language, guardrails that classify readable intent do not see it coming. It shows that alignment training alone does not make a model robust to optimised inputs.
How to defend against adversarial suffixes
Layer several checks. Perplexity or gibberish filters flag the unnatural strings; input normalisation and paraphrasing can break the exact token sequence; adversarial training hardens the model against known suffixes. None is complete on its own, so combine them with output filtering and constrained tool use, and re-test as new optimisation methods appear.
References
Optimised inputs beat alignment-only defences. Talk to a security expert about testing your model against adversarial and transferable suffixes.