Claude Opus 5.5 and Prompt Injection: What the Security Test Shows—and What We Still Don’t Know

The claim and the available evidence

Anthropic presents Claude Opus 5.5 as having tied with Fable 5.1 for the lowest prompt-injection success rate among the models tested in a Gray Swan benchmark. This is a relevant claim for people connecting models to documents, tools, or other inputs that could contain malicious instructions. But it should be read as the manufacturer’s statement about a specific evaluation—not as proof that the model is safe in every environment.

The verified source information provided identifies this claim on Anthropic’s Opus 5.5 announcement page, but it does not include Gray Swan’s methodology report or detailed results. It gives no numerical rate, total number of models, model versions, attack set, evaluation instructions, or rules for deciding whether an attack succeeded. Nor does it establish whether every model was compared under identical conditions.

We can therefore report what Anthropic says, but we cannot reproduce the test or independently assess its strength from these materials. The absence of details in the available material does not prove that Gray Swan has not published them elsewhere; it means they cannot be confirmed using the sources verified here.

This distinction matters. A strong showing on a benchmark can be a useful signal when planning an evaluation, but it does not replace testing in the application itself. Risk depends on the model and on how the system obtains information, interprets instructions, and takes action.

What a prompt-injection success rate means

Prompt injection is a class of attack in which malicious text attempts to change a model’s intended behavior. It may appear in a user’s written instruction or in content the system retrieves, such as a webpage, file, or message. In an indirect injection, the user may not write the attack at all: the model encounters it in material it has been asked to process.

A success rate usually summarizes how many attack attempts achieve an outcome defined by the evaluation, relative to the set of attempts considered. Without the operational definition, that general description is not enough to interpret a specific result. A protocol might count success when a model repeats a prohibited instruction, reveals test data, uses a tool in an unauthorized way, or simply fails to complete the original task. These behaviors are not equivalent, and none should be assumed to form part of Gray Swan’s benchmark without documentation.

The denominator also matters: which attacks were included, how many times each was run, what configuration was used, and how results were aggregated. A low rate on a restricted test set might describe that set well while failing to represent different attacks, applications with tools, or languages not included. The sources supplied do not confirm these parameters for the cited comparison.

Another issue is how ordinary failures are counted. A model might resist a malicious instruction while also rejecting a legitimate request or failing to complete the task. Product evaluation should look separately at attack resistance, false-alarm rates, and task quality. The available information does not establish whether Gray Swan reports these metrics separately.

Which models and conditions does the comparison cover?

The statement attributed to Anthropic identifies Opus 5.5 and Fable 5.1 as tied for the best result among the models tested. The available material does not say how many models were in the group or list the other versions. It also does not reveal whether the evaluation covered unmodified models, configurations with system instructions, or complete systems with filters and tools.

Those differences affect what a comparison means. Testing a model on its own is not the same as testing an application that includes document retrieval, routing, moderation, and tool calls. If participants ran with different defenses or settings, the result might reflect the combined configurations rather than the models alone. The supplied sources do not establish which design Gray Swan used.

Anthropic’s source lets us attribute the claim accurately. Opus 5.5’s official system card is identified as documentation about the model and its safety evaluations, but the available excerpt does not show specific Gray Swan results or describe the prompt-injection protocol. Anthropic’s general system-card page says these documents cover capabilities, safety evaluations, and deployment decisions; that institutional overview is not a substitute for data specific to this test.

What can—and cannot—be concluded

The narrow, defensible conclusion is that Anthropic attributes to Opus 5.5 a tie with Fable 5.1 for the lowest prompt-injection success rate in the Gray Swan evaluation it mentions. If confirmed by the primary report under relevant conditions, the result would be evidence about behavior on that benchmark. On its own, it does not show that Opus 5.5 is immune to prompt injection, safer than every other model, or suitable for every application.

Nor can the result be directly generalized to attacks in other languages, file formats, tool chains, or data sources. A test may be useful for one class of attempts without covering others. Without the methodology, it is impossible to know whether the evaluation included indirect instructions embedded in documents, whether the model had to use tools, or whether an external action counted as success. These are open questions, not omissions that can be confidently attributed to the benchmark.

A relative ranking also does not automatically tell us the absolute level of risk. Two models sharing the best rate among the participants does not tell us what that rate was, how far ahead they were of the others, or whether any differences were statistically significant. No figure is supplied here to support those calculations.

The benchmark does not replace an evaluation of the complete system. An application might restrict permissions, validate outputs, and require confirmation before taking action. Or it might grant the model broad access to data and tools. That architecture can substantially change the consequences of a malicious instruction, even when the underlying model is the same.

Documented capabilities and limitations of the exact model

The official source provided identifies a system card for Claude Opus 5.5 and describes it as documentation about the model, its safety evaluations, and responsible deployment. Without further detail in the supplied material, it would not be rigorous to attribute specific safety results, technical capabilities, or quantified limitations to the card when they do not appear in the excerpt.

Anthropic also presents Opus 5.5 as strong at agentic coding and knowledge work, and says it costs 40% less to run than Opus 5 on typical workloads. That comparison is the manufacturer’s claim and applies to typical workloads; it is not a universal rate or a guaranteed saving for every use. The available information does not define which workloads count as typical, how operating cost is measured, or whether the figure refers to per-token pricing, total task cost, or another metric.

A description of the Claude family should not be turned into a verified property of Opus 5.5. A technical decision requires the exact model card, relevant parameters, and testing against the tasks and limits that matter. In particular, the Gray Swan claim alone does not demonstrate how the model responds to instructions in a document, ambiguous requests, tool errors, or attempts to extract sensitive information.

Access and pricing: what can be confirmed

The sources supplied include Google Cloud documentation about Claude Opus 5.5 and an AWS Bedrock page dedicated to the model. This confirms that both platforms have documentation pages identifying it. The available excerpts are not enough to establish availability in every region, immediate access for every account, contractual terms, or a valid model identifier for each deployment.

The general Claude models documentation is identified as a guide for checking models and comparing options, but the supplied excerpt contains no specific Opus 5.5 price. Consequently, we cannot publish an input or output rate here, or make claims about effective dates, minimums, usage modes, or associated charges. Those details need to be checked on the pricing page for the chosen channel and at the time of contracting.

The 40% reduction compared with Opus 5 is limited to Anthropic’s claim about operating cost on typical workloads. It is not an official rate and cannot be translated into a per-request cost without knowing volume, input and output sizes, tool use, and what Anthropic means by a typical workload. For budgeting, teams should measure a representative sample through the specific channel they plan to use.

Safeguards for a real workflow

No benchmark figure should replace application-level controls. If the model reads external material, treat that material as potentially untrusted content and clearly separate the data being analyzed from the instructions that govern the system. This separation can reduce ambiguity, but it does not by itself guarantee that the model will always interpret the hierarchy correctly.

For consequential actions, it is prudent to limit tool access, apply least-privilege permissions, and require independent validation before executing sensitive operations. A model response can be a proposal, not an authorization. It is also useful to log relevant inputs, decisions, and tool calls in a way that complies with the product’s privacy and retention obligations.

Tests should reproduce the real architecture: the same kinds of documents, retrieval, instructions, tools, and controls that the team plans to use. Teams can separately measure whether the model follows valid instructions, rejects attempts to divert it, avoids disclosing data, and completes the legitimate task. This local evaluation complements an external benchmark; it does not justify attributing properties to Opus 5.5 that have not been observed in testing.

In an agent workflow, a malicious instruction need not persuade the model to reveal text in order to cause harm. It might try to trigger an unauthorized query, change an action, or influence a later decision. Defenses should therefore not rely only on the model detecting the attack: permission boundaries and checks outside the model can contain failures.

Evidence at a glance

It is useful to keep three levels separate. First, the claim attributable to Anthropic: Opus 5.5 tied with Fable 5.1 for the lowest prompt-injection success rate among the models included in the Gray Swan evaluation the company mentions. Second, institutional information that can be verified in the supplied sources: an Opus 5.5 system card exists, and platform documentation identifies the model. Third, questions that remain unresolved in the available excerpts: figures, protocol, set of models, equivalent conditions, specific price, and actual availability.

There is not enough evidence to turn the reported result into a general safety certification or to describe Gray Swan’s protocol as if we had reviewed it. These sources also do not establish the rate Opus 5.5 achieved, whether its difference from other models is significant, or which specific safeguards would prevent injection in each application.

For security leads and developers, the practical takeaway is limited: the comparison may justify including Opus 5.5 in an evaluation, but not skipping controls or local tests. Before deployment, confirm the version and channel, check current terms and pricing, review the complete system card, and test attacks representative of the application. The benchmark provides context; the evidence needed for a decision depends on the risk, permissions, and data involved in each workflow.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.