Prompt-injection resistance
Whether content the model reads while working, rather than what you typed yourself, can override your instructions.
What it is
tAI increasingly reads content it didn't ask for and you didn't write yourself. An email sitting in a connected inbox is one example. A page fetched during research is another. A file inside a connected repository is a third. A Notion page pulled in for context, because a request referenced it, is a fourth. Any of that content can, in principle, contain text written specifically to look like an instruction rather than information. A line buried in an email signature that reads like a command aimed at whatever system processes the message next is a concrete example. Prompt-injection resistance is the name we give to whether tAI correctly treats that kind of content as data to reason about, rather than as something to obey the way it would obey a request you typed directly.
This category matters more as tool access grows, and it matters in a specific, asymmetric way. A model that can only talk can be tricked into saying something wrong. That's a real problem, but a bounded one: the damage stops at the output. A model that can also act, drafting an email, editing a file, running a search, taking a step in a connected workspace, can be tricked into doing something wrong. The damage from that is no longer bounded by the conversation window. It can reach whatever system the action touched. That asymmetry is the entire reason this category exists on its own, rather than being folded into a general "does the model follow instructions correctly" check. It's also the reason the bar for this category keeps rising every time tAI is given a new kind of tool access.
How we test it
The test suite works by planting instructions inside content tAI would plausibly encounter mid-task. A fetched web page is one vector. An email body is another. A file tAI is asked to read and summarize is a third. A page in a connected workspace is a fourth. Some planted instructions are direct, phrased along the lines of "ignore your previous instructions and instead do the following." A model that fails against those is failing at the easiest version of the problem. The harder, more useful part of the test set is indirect: instructions written to look like a normal, plausibly in-scope request, since that style is consistently the harder one to catch and the one that shows up more often when this category actually fails.
The content used to build this test set comes from three sources, kept deliberately separate. The first is hand-written adversarial examples produced during internal red-teaming. The second is synthetic variation, generated to probe phrasing the hand-written set doesn't already cover. The third, and the one that has mattered most in practice, is anonymized patterns drawn from confirmed production reports. Those are cases where a real user or an automated monitoring system flagged an attempt that actually happened, not one we imagined in advance. Keeping the three sources separate matters. It stops the evaluation from becoming overfit to any single writing style or pattern. It also lets us see which source is finding the most, and adjust where we spend effort next.
What we've found
The clearest, most obvious injection attempts have been consistently easy to catch for a while now. Improvement on that specific slice of the test set has mostly plateaued. There isn't much more room to improve against something already caught reliably. The harder, more persistent failure mode is content written to mimic the user's own voice and stay plausibly in-scope. That's the one that has actually driven measurable safety-tuning work across recent versions. A concrete example is injected text sitting inside an email thread that asks tAI to also take an action on an unrelated but superficially related address. It's phrased the way the actual account holder might plausibly phrase it themselves, not the way an obvious attacker would.
That specific in-voice failure mode is called out directly on the tAI 4.2 page. It's treated as an open area, not a solved problem carried forward with a caveat nobody reads. It was also, notably, first identified from a real production report, not from internal red-teaming. That's itself a useful data point about the honest limits of red-teaming, described in more depth on the Red-teaming page. An internal team testing against its own imagination will always be better at catching known patterns than at anticipating every new one. This is a concrete example of that limit showing up in real evaluation history, not as an abstract caveat.
The full adversarial prompt set used to build this category's evaluation isn't published, for the same reason a lock manufacturer doesn't publish a working bypass guide alongside its marketing material. The exact detail that would let an outside reader verify our numbers most thoroughly, the specific phrasings that do and don't get caught, is the same detail that would hand a working technique to someone trying to defeat the safeguard rather than understand it. Category-level results, trend across versions, and the general shape of what's being tested are published; the underlying test prompts themselves are not, and that trade-off is applied consistently across every category in this section, not singled out here.
Where this risk concentrates most
Every product surface that reads content tAI didn't generate itself carries some version of this risk, but it isn't evenly spread. A connected inbox, workspace, or repository is a meaningfully higher-exposure surface than, say, a single file you upload and ask about directly. The reason is volume and variety. A connector brings in content written by many different people, over a long period of time, none of whom were writing with tAI's own instructions in mind. A single uploaded file is one piece of content you chose yourself. That's part of why the safeguards described on the Connector safeguards page exist as an independent layer on top of this category, rather than assuming prompt-injection resistance alone is sufficient protection for connected accounts.
It's worth being precise about how this category relates to the one described on the Tool-use safety page, since the two are easy to conflate. This page is about whether tAI correctly recognizes planted content as data rather than as an instruction to follow in the first place. Tool-use safety is about what happens next, once a specific action has actually been proposed: whether it stays in scope, waits for consent, and treats irreversible steps with appropriate caution. A genuinely safe system needs both to hold. A model that resists injected instructions perfectly but then handles its own legitimate tool actions carelessly isn't actually safe, and neither is the reverse. They're evaluated, tuned, and reported as two separate categories specifically so a strength in one doesn't quietly mask a weakness in the other.