AWS taught Amazon Nova to forget a refusal. Prove yours deserves it first.

A red-team lead is scoping a ransomware tabletop for a hospital network's board. She needs the model to draft the attacker's side of it: a plausible initial-access script, the lateral-movement steps, the ransom note. Not to run against anyone. To hand the board something that finally makes the risk feel real instead of theoretical.

The model refuses.

That refusal is not a bug in the ordinary sense. Somewhere in its training, this exact request pattern got flagged as a hallmark of someone building a live attack, and for an actual attacker, refusing is exactly right. The model just has no way to know it's talking to the person a client hired to simulate that attack on purpose. It sees the shape of the ask, not the engagement letter behind it.

The tempting fix is to get cleverer. Rephrase it as a screenplay. Tell it you're a novelist. Add "for authorized training purposes only" and hope the sentence does some work. That approach treats the refusal like a lock that needs a better key, and it usually fails for a specific, useful reason: the refusal often isn't sitting in the prompt at all. It's baked into the model's weights.

AWS said as much on July 6, in a machine learning blog post by Qian Hu, Dan Sinnreich, and Veda Raman that names this failure mode plainly: organizations deploying foundation models keep hitting safeguards that were built for content moderation, and those safeguards block work that was never the threat they were designed to catch. AWS's own examples read like a cross-section of ordinary business: a media company summarizing scripts that contain mature language, a cybersecurity firm simulating real attacks, a legal team processing evidence in a sensitive case, a security team building phishing-awareness training. Four different jobs, one shared symptom.

AWS gives that symptom a useful name: over-deflection. It's not that the AI is too safe (safety is the point). It's that the AI is safe in a way that can't tell your job from an attacker's job, and no amount of prompt-wrangling fixes that, because the tendency to deflect isn't a sentence you're arguing with. It's a pattern learned during the model's alignment training, sitting in the parameters themselves.

What AWS actually shipped

AWS's answer is a technique for making a model unlearn a specific reflex, without retraining it from nothing and without leaving it undefended everywhere else.

The mechanism is called Reverse Direct Preference Optimization, or rDPO, a deliberate inversion of Direct Preference Optimization, the technique Amazon already uses to steer Nova toward preferred behavior using paired examples of better and worse responses. Where ordinary DPO teaches a model new caution, rDPO selectively removes caution that's misfiring. AWS trains lightweight Low-Rank Adaptation (LoRA) adapters that, at inference time, steer the core model away from deflecting in specific, approved policy areas, without disturbing the base model's behavior everywhere else.

That's the mechanism behind Amazon Nova Customizable Content Moderation Settings (CCMS), now available for approved customers on Nova Lite and Pro. CCMS splits Nova's safety behavior into four pillars, Safety, Sensitive Content, Fairness, and Security, and lets an approved customer dial back deflection in the specific pillar their business actually needs. AWS says Nova continues enforcing a set of controls that aren't up for negotiation, including protections against harm to children and privacy violations. Those don't move, regardless of which pillar a customer has approval to adjust.

The deployment path stays inside the Bedrock workflow teams already use. AWS shares the trained adapter through AWS Resource Access Manager. Once a customer accepts and copies it, the adapter shows up as a custom model in Amazon Bedrock with its own ARN. From there, a team stands up an on-demand inference deployment and calls it through the standard Converse API, the same interface they'd use to call any other Nova model. CCMS on Lite and Pro currently runs through on-demand custom model deployment in the us-east-1 (N. Virginia) region. There's no separate SDK to learn and no new request format. The custom model, addressed by its own ARN, is simply less trigger-happy in the pillar it was tuned for.

Access isn't self-serve. AWS is routing this through account teams and support cases, which tracks with treating this as a scoped grant tied to a stated business use, not a global setting anyone can flip.

The trade AWS is showing its work on

AWS published its own evaluation numbers, and they're worth sitting with. They show the technique working, and they show it costing something, on both sides of the ledger.

Deflection rates, baseline versus customized: Safety fell from 86.51% to 32.77%, a swing of nearly 54 percentage points. Red Team Prompts dropped from 98.10% to 47%. Security went from 91.61% to 45.73%. Sensitive Content moved from 79.02% to 33.58%. Fairness fell from 51.84% to 23.83%.

Read that plainly: a model tuned for the Safety pillar was refusing legitimate work covered by that pillar's approved use case roughly seven times in eight before customization, and still refuses roughly one time in three afterward. Customized Nova is not a model that stopped saying no. It's a model that says no less often, in the specific area a customer has justified needing that.

The cost lands on general capability, and it's small: Instruction Following dipped from 94.12% to 92.57%, Math Mini from 86.40% to 85.20%, MBXP Python from 74.80% to 73%. A point or two of drift on unrelated benchmarks, in exchange for cutting deflection in the targeted pillar by more than half.

Those two columns are the actual decision a customer is making. The question is not "should we make the model more permissive," but "does this specific reduction in refusals, for this specific approved use, justify this specific dip in general capability." AWS is at least giving customers real numbers to run that trade against, instead of asking them to take it on faith.

The refusal specimen

Here's what AWS's post doesn't cover, because it's not AWS's problem to solve: how a customer decides, case by case, which refusals in their own workflows are the bug and which ones are the model doing exactly its job.

That's the harder half of this, and it happens before anyone files a support case with their AWS account team. Before you request a pillar adjustment, you need something more durable than "the bot said no and that annoyed someone." You need a refusal specimen: a small, bounded case file built around one blocked request, kept in whatever form your team already tracks decisions.

The rollback trigger matters as much as the exact request. A pillar adjustment made for one approved security exercise doesn't need to stay permissive when someone outside that team's use case asks the same custom model ARN a similar question. A specimen with the rollback trigger written down before the change ships is the difference between a scoped exception and a permanent hole nobody remembers granting.

This is a smaller, more specific cousin of the discipline behind scoping a customer-facing chatbot's job before the model gets loose with strangers. The same instinct, that a prompt is not an access-control layer, applies here too. CCMS moves the boundary from the prompt into the model weights via a dedicated ARN, which is a real improvement. It still doesn't remove the need for a human to have written down, in advance, what "approved" means for this one workflow, and what happens if that scope gets tested.

Back to the tabletop scene: a specimen built for it would name the approved purpose (a contracted security exercise, not a live attack), describe the acceptable response shape (an attack narrative and labeled sample artifacts, not working exploit code), keep every non-negotiable safety control untouched, and set the rollback trigger at the first sign the custom model's access is being used outside that named engagement. That's a request an account team can actually evaluate: a scoped job with a boundary, not a request to make the model generally more agreeable.

AWS's post also notes that customers can pair CCMS with Amazon Bedrock Guardrails for application-level safeguards that sit alongside it. That pairing is worth taking literally. CCMS changes what the model itself will attempt. Guardrails checks what comes out the other side. A specimen file is the paperwork that justifies touching the first one, and Guardrails is part of what keeps standing after you do. Teams already building structured review before an AI action executes will recognize the shape: the model proposes, something outside the model still checks.

None of this is a large, loud AI story. It's a narrow fix to a real operational failure, shipped quietly, with a name attached to a problem plenty of teams have hit without a name for it. That's usually the more useful kind of release to notice, not because it changes the market, but because it changes what your team should write down the next time a legitimate request gets refused for a good reason that happens to be the wrong one.

If your team has a workflow where the model keeps refusing work you're confident is legitimate, bring us that one workflow. We'll help you build the specimen: approved purpose, refusal behavior, acceptable response shape, the protections that don't move, and the rollback trigger, before anyone touches a safety setting.