Tool-use safety

Why it's a separate category

A model can be genuinely well-behaved in ordinary conversation and still be unsafe with tool access. The two properties don't automatically move together. A model can, in the worst case, be perfectly safe in what it says out loud. It can do that while actively narrating an unsafe action it's about to take. It describes its own next step in calm, reasonable-sounding language, right before doing something a careful reviewer would have stopped. That specific failure mode, safe language wrapped around an unsafe action, is exactly what this category is built to catch. It's the reason tool-use safety is evaluated and tuned as its own area, rather than assumed to follow automatically from a model that talks safely.

As of tAI 4.2, tool-use safety is tuned as its own dedicated pass during training. That's the first time in the model's development history it's been run separately from general conversational safety tuning. Earlier versions folded the two together into a single combined safety-tuning stage. The assumption was that a model tuned to be safe in conversation would carry that carefulness into tool use as a side effect. That assumption sounded reasonable. Internal evaluation showed it was measurably wrong often enough to matter. The combined approach caught fewer of the safe-language-unsafe-action cases described above than a dedicated pass did. That's the direct reason the training process changed, rather than staying combined for the sake of simplicity.

What gets tested

The evaluation for this category is built around three distinct properties. They're tested independently of one another, not as a single pass-or-fail check. Scoping asks whether the model stays within what it was actually granted access to. A specific working directory, a connected inbox, a single repository selected for that conversation, are all examples of that granted scope. It asks whether the model reaches beyond that boundary because a task seemed to call for it. Consent asks whether an action with a real external effect waits for explicit approval before it happens. Reversibility awareness asks something more subtle: whether the model treats a destructive or hard-to-undo action differently from a read-only one that carries no real risk if it turns out to be slightly wrong.

• Scoping. Does the model stay within what it was actually granted access to, a working directory, a connected inbox, a single repository, rather than reaching beyond it.
• Consent. Does an action with a real external effect wait for the explicit approval the product surface requires, rather than proceeding on the model's own judgment alone.
• Reversibility awareness. Does the model treat a destructive or hard-to-undo action, deleting something, force-pushing, sending a message, differently from a read-only one.

The model is one layer, not the only one

Tool-use safety, as evaluated and reported on this page, is a property of the model's own judgment. It asks whether the model, left to decide on its own, chooses to stay scoped, wait for consent, and treat irreversible actions with appropriate caution. It is deliberately not treated as the only thing standing between a request and a real-world consequence. Building the product that way would have been a mistake. It would make every user's safety depend entirely on the model never having an off day. Product-level safeguards, covered in full on the Sandboxing and Connector safeguards pages, enforce the same boundaries independently and outside the model entirely. That's specifically so a single model-level judgment error doesn't automatically become a product-level failure.

That layered design shows up directly in how the numbers below should be read. A scope violation caught in this category's evaluation is a real data point. Say tCode's file access reaches slightly outside its intended boundary in a near-miss case. That's a genuine signal about the model's judgment, and it gets tuned against. It is not, on its own, evidence that a user was actually exposed to a real consequence. The sandboxing described on the Sandboxing page is a separate, independent backstop. That backstop would have to also fail for a real consequence to follow. We report the model-level numbers and the product-level safeguards honestly and separately, rather than blending them into one reassuring combined figure, because the two things measure genuinely different failure surfaces.

Results

No case in tAI 4.2's evaluation round involved the model taking an irreversible action without the required approval gate. A send, a publish, a direct push, a deletion, all fall into that irreversible category. That's the specific outcome the consent property above is designed to protect against, and it held across the entire evaluation round. The scope-violation rate is tracked separately per tool category. File access, command execution, version-control operations, and connector actions are each measured on their own. Full figures, with a plain-language description of what a typical near-miss actually looked like, are in the tAI 4.2 system card. That document is the right place to go for the numbers behind the summary given on this page.

Avoiding approval fatigue

An approval gate is only worth something if a person actually reads what they're approving. A product that asked for explicit confirmation on every single tool action, including harmless, read-only ones, would train users to click through without reading within a matter of days. That outcome would make the approval gate on a genuinely consequential action worth less, not more, since it would arrive indistinguishable from a dozen routine ones the user had already learned to dismiss on reflex. That's a real, well-documented failure mode in security UX generally, not a hypothetical concern specific to tAI. It's part of why the consent property described above is scoped specifically to actions with a real external effect, rather than applied uniformly to every tool call regardless of consequence. Getting that scope right is itself treated as part of the tool-use safety evaluation, not a separate UX concern handled independently of it.

Reading a file, searching a codebase, or fetching a page during research all proceed without a gate. None of those actions are hard to undo, and none of them have an effect outside the current session. Sending a message, publishing something, pushing to a shared branch, or running a destructive command are treated completely differently, for exactly the opposite reason. Keeping that line sharp and consistent is a deliberate design choice, tracked as its own concern separate from the raw scoping and consent properties described above. A gate that shows up rarely, and only for something that actually matters, is a gate people are far more likely to still be reading carefully the hundredth time they see it. That's a deliberate trade-off in how the product itself is built, not just a property of how the model happens to behave.