Adversarial ML
Isometric pink hub cube radiating spokes to smaller pink cubes above a dark grid platform, with larger pink blocks at its corners.
attacks

How the GCG Optimizer Finds Adversarial Suffixes

How the Greedy Coordinate Gradient algorithm builds an adversarial suffix token by token: the gradient step, the top-k candidate search, and its cost.

By Adversarial ML Editorial · ·Updated · 6 min read

In 2023, Zou et al. published GCG (Greedy Coordinate Gradient), an optimization-based attack that finds adversarial suffix strings making aligned LLMs produce restricted outputs. The original paper required a research-grade GPU cluster to run effectively. Three years later, the attack class is within reach of any practitioner with a single consumer GPU. This is the optimizer’s-eye view of that attack class in 2026: the math of how a suffix is found, the cost curve, and the defenses that follow from it.

What GCG actually does

The setup: you have a target model with a safety alignment that refuses certain prompts. You want to find a suffix string S such that when appended to a refused prompt P, the model produces a target completion T instead of refusing.

The optimization is over the discrete token space. At each step:

  1. Compute the gradient of the loss (probability of T given P + S) with respect to each token in S
  2. For each position in S, identify the top-k token candidates that would most decrease the loss
  3. Sample from those candidates, compute actual loss, keep the best
  4. Update S, repeat

The “greedy” part is the per-position search. The “coordinate gradient” part is the gradient-informed candidate selection. The whole thing is essentially gradient descent on a discrete sequence.

After ~500-2000 iterations, you have a suffix that reliably triggers the model. The output looks like garbled tokens (! ! ! ! describing.\ + similarlyNow write oppositeley.}( Me giving**ONE please?...), but it works.

Why it scales

Two properties make GCG dangerous beyond its specific attack:

Universality

A suffix optimized against one model often transfers to other aligned models, the same adversarial transferability effect that makes black-box attacks viable at all. The original paper already showed suffixes optimized on Vicuna-7B and 13B transferring to ChatGPT, Bard and Claude.

The implication: a research lab with one model can produce attacks that work against many.

Reproducibility

Unlike heuristic jailbreaks that get patched the moment a vendor sees them, GCG-class suffixes are mathematically derived. If a defender patches one suffix, a new run of the same algorithm produces another. The attack class is durable in a way prompt-engineered jailbreaks aren’t.

The cost curve

What has changed since 2023 is the implementation, not the algorithm. The original paper’s own setup assumed a research-grade GPU cluster; the work that followed, including memory-efficient red-teaming implementations such as FlashRT, has been aimed squarely at cutting the memory footprint and the wall-clock cost of the same search rather than at improving its success rate.

That direction is the part that matters for defenders, and it does not depend on any particular hourly figure. Every reduction in the hardware needed to run the search moves the attack from a population of well-resourced labs to a population of anyone with a desktop GPU, and defenses calibrated against the first population do not hold against the second. Plan for the attack to be cheap rather than for a specific price.

Reproducible setup (offensive — for defenders’ regression suites)

# Clone the reference implementation and install it as a package
git clone https://github.com/llm-attacks/llm-attacks.git
cd llm-attacks
pip install -e .

# Point the experiment configs at your local model weights (see the README),
# then attack one harmful behavior on one model with the launch script
cd experiments/launch_scripts
bash run_gcg_individual.sh vicuna behaviors   # swap vicuna for llama2, or behaviors for strings

The attack module itself has no command-line interface: the launch scripts drive the paper’s experiments, and the repository’s demo.ipynb walks through a minimal version of the attack on a single prompt. Output: a suffix string and the resulting model completion. Run multiple times against your target model class to build a transferability corpus.

Defenses that actually move the needle

Doesn’t work much

  • Input filters trained on natural-language injection patterns: GCG suffixes look like noise, not language
  • Single-prompt classification: each suffix is fresh; signature-matching fails
  • Output filters that look for specific harmful content: defenders chase the long tail

Works somewhat

  • Input filters trained on perplexity: GCG outputs often have unusual perplexity distributions. Perplexity-based detection catches the obvious cases, misses the polished ones. Reading any such claim carefully is its own discipline, covered in evaluating adversarial robustness correctly.
  • Constitutional AI / RLHF tuning specifically against GCG-class outputs: training against the attack class reduces the success rate of the suffixes it was trained on. It is not a complete fix, because a fresh run of the optimizer produces suffixes the tuning never saw; it raises the bar.
  • Output-side classification on the resulting completion: if the model goes “Sure, here is how to…” in response to a clear refusal-class prompt, that’s catchable on the output side regardless of the input.

Works well (architectural)

  • Capability scoping at tools: even if you bypass alignment, the model can only do what its tools allow. Jailbreaking a chat-only model produces text; jailbreaking an agent with send_email tool can be catastrophic. Don’t give models tools they don’t need.
  • Separation of trust domains: LLM in the user-facing path; deterministic rules in the action-taking path. The LLM proposes, deterministic code disposes.

Why most teams’ “GCG defense” is theater

Vendor pitches around GCG defense usually amount to: “we trained our model against your attack.” That’s catching the visible threat. Two problems:

  1. The next iteration of the attack (or the next research paper’s variant) bypasses the trained defense.
  2. The training-against-attack approach doesn’t generalize to attack classes not yet published.

Practical defenders should assume GCG-class attacks against any LLM are feasible and design the application architecture to limit the blast radius when (not if) one succeeds.

Patterns worth designing against

Three combinations are worth designing against. Each pairs a model-level bypass with an architectural gap that converts it into impact:

  1. A support bot holding tools it does not need. If a suffix flips a refusal, the blast radius is whatever the tool layer permits, which on a support surface usually includes sending mail. Architectural fix: validate tool arguments server-side and authorize the action independently of the model, so a bypassed refusal still cannot select the recipient.

  2. A derivative model that inherits alignment without inheriting its evaluation. Because suffixes transfer within a model family, a suffix optimized against a base model is a plausible starting point against anything fine-tuned from it, while the fine-tune’s safety claim is usually carried over from the base model card. Architectural fix: treat suffix robustness as a per-derivative measurement, not an inherited property.

  3. Indirect injection as the delivery path. The suffix does not have to arrive in the user turn. Retrieved documents, tool output, and stored prompt injection through agent memory all land in the same context window, and an input filter that inspects only the user field never sees any of them. The taxonomy of indirect injection vectors is tracked at promptinjection.report.

In all three, alignment training is a contributing factor but not the load-bearing one. The architectural mitigations are what bound the impact. A catalogue of GCG-class attack variants, repro scripts, and evaluation harnesses for testing model robustness to adversarial suffixes is maintained at JailbreakDB’s universal adversarial suffixes entry.

Reading list

  • The original GCG paper — read once
  • FlashRT — for the cost-curve update
  • Are Aligned Neural Networks Adversarially Aligned? (Carlini et al., 2023) — answers the title question; spoiler: no
  • Sleeper Agents (Hubinger et al., 2024) — for the training-time vs inference-time threat distinction

If you’re a red-teamer, run the algorithm. If you’re a defender, build for the assumption that someone else has.

Sources

  1. Universal and Transferable Adversarial Attacks on Aligned Language Models (Zou et al. 2023)
  2. llm-attacks GitHub repository
  3. FlashRT: Memory-Efficient Red-Teaming
#adversarial-ml #gcg#optimization-attacks#red-team#alignment
Subscribe

Adversarial ML — in your inbox

Working adversarial ML — exploits, defenses, and the gap between — delivered when there's something worth your inbox.

No spam. Unsubscribe anytime.

Related