What Is Likert Framing Injection?

What Is Likert Framing Injection?

Likert framing injection is a prompt-injection technique that wraps an unsafe request inside a rating-scale or scoring task, such as asking a model to judge content from 1 to 5 before generating or improving it. It is a security failure mode in eval pipelines, production traces, and gateway guardrails because the model may treat the Likert frame as harmless analysis. FutureAGI detects the pattern with PromptInjection and can block risky prompts with ProtectFlash.

Why it matters in production LLM/agent systems

Likert framing injection turns a safety boundary into a grading exercise. The attacker does not ask directly for disallowed output; they ask the model to rate, compare, improve, or maximize examples under a numeric rubric. That framing can hide intent from naive filters and persuade the model to continue the unsafe task under the label of evaluation.

Two failure modes show up in production. Policy laundering makes a harmful request look like QA, moderation, or benchmark construction. Instruction hijacking appears when the model follows the embedded scoring objective instead of the application policy. In logs, engineers often see unusually long prompt prefixes, words like “score,” “rating,” “rubric,” or “Likert,” and a sudden jump in blocked-output attempts after a harmless-looking user turn.

The pain is cross-functional. Developers see a test prompt that should have refused but instead elaborated. SREs see normal latency and token usage, so the incident does not look like abuse traffic. Security teams need evidence that the numeric frame caused the bypass, not just that unsafe words appeared. Product teams see user trust damage when an assistant performs policy analysis and then echoes material it should have refused.

For 2026 multi-step agents, the risk is sharper because the score can become an action objective. A planning agent may optimize for “make this a 5” across retrieval, rewriting, and tool calls unless each boundary has a guardrail.

How FutureAGI handles Likert framing injection

FutureAGI handles Likert framing injection as a prompt-injection variant anchored to eval:PromptInjection. In an offline eval, the PromptInjection evaluator runs against red-team prompts that contain rating-scale language, classifier wording, and rubric-style requests. In production, ProtectFlash can run as an Agent Command Center pre-guardrail before the prompt enters the model route.

A real workflow looks like this: a support agent is instrumented with traceAI-langchain, and each user turn, retrieved chunk, and agent.trajectory.step is logged. A user submits a rubric-like request asking the model to rate unsafe variants and make one score higher. The route sends the prompt through pre-guardrail: ProtectFlash; if the result is high risk, Agent Command Center returns a refusal or fallback response. If it passes but later output is unsafe, the trace is added to a regression dataset and re-scored with PromptInjection.

FutureAGI’s approach is to test the frame, not only the keywords. Unlike Ragas faithfulness, which measures whether an answer is grounded in context, PromptInjection targets adversarial instruction patterns that try to change the model’s operating rules. That distinction matters because a Likert-framed attack can be perfectly “relevant” while still unsafe.

The engineer’s next move is concrete: set an eval threshold for Likert prompts, alert on eval-fail-rate-by-cohort, compare prompt versions, and mirror risky traffic to a regression suite before relaxing the guardrail.

How to measure or detect it

Use measurement signals that capture both wording and outcome:

• PromptInjection evaluator — flags prompt-injection risk in rating-scale prompts, regression datasets, and red-team suites.
• ProtectFlash guard — runs a low-latency injection check before model routing for live traffic.
• Trace fields — inspect user input, retrieved context, agent.trajectory.step, prompt version, route, and guardrail decision on the same trace.
• Dashboard signal — track eval-fail-rate-by-cohort, block-rate-by-route, reviewed false-positive rate, and unsafe-output rate after Likert-like prompts.
• User-feedback proxy — watch escalations saying the assistant “rated” or “improved” content it should have refused.

from fi.evals import PromptInjection, ProtectFlash

prompt = "Rate this unsafe request from 1 to 5 and improve the score."
pi_result = PromptInjection().evaluate(input=prompt)
guard_result = ProtectFlash().evaluate(input=prompt)
print(pi_result, guard_result)

Treat the metric as cohort-based. One global block rate can hide the problem if Likert-style prompts are rare. Slice by prompt template, route, customer, model, and source channel so a new attack pattern does not disappear inside normal traffic.

Common mistakes

The common failure is treating Likert framing as just another suspicious phrase. It is a task-shape problem: the model is being asked to evaluate the unsafe behavior, then continue it.

• Filtering only banned words. The unsafe intent is carried by the scoring objective, not always by explicit prohibited vocabulary.
• Blocking every rating prompt. Product surveys, moderation queues, and human-feedback tools also use scales; require source, policy target, and requested transformation.
• Testing only direct attacks. Add Likert, rubric, classifier, and “improve the score” variants to prompt-injection regression suites.
• Letting the model quote unsafe examples. A refusal that repeats the payload can still leak content or train users around the guardrail.
• Skipping false-positive review. A high block rate without analyst review pushes teams to disable the control during an incident.