Security

What this covers

This section is the detailed version of the short overview at ai.artfical.com/security. That page is kept short on purpose. The work behind it is not short. Everything summarized there in a sentence or two has a full page here. There are seven evaluation categories we test every model against before release. There is a page on how red-teaming and the release checklist actually work in practice. There is a page on how the product itself is built, so a safeguard failure inside the model isn't the only thing standing between a bad request and a bad outcome. And there is a per-model breakdown of what changed and why between tAI 4.1 and tAI 4.2. If you read only one page from this section, this overview page is designed to be enough to know where to go next for anything more specific.

None of what follows is written to be reassuring on its own. That's a deliberate editorial choice, not an oversight. Where something is unresolved, we say so on the relevant page. Where an evaluation category has a known gap, we describe the gap rather than smoothing it over. Where a piece of methodology is genuinely harder to verify from the outside than others, we say that too. A security section that only ever reports good news is easy to write and hard to trust. We would rather this section be trusted than flattering. Several pages in this section describe a checkpoint that was built, evaluated, found wanting, and rejected before it ever reached a real user, and we think that kind of detail is more informative than a polished summary that only shows the version that eventually shipped.

The seven-category structure that runs through this entire section did not appear all at once. Earlier versions of tAI were evaluated against a smaller, less formal set of concerns. The current structure is the product of finding real gaps in that earlier, simpler approach. Tool-use safety used to be folded into general conversational safety, and it isn't anymore. Turkish-language misuse used to be a spot check, and now it's a full parallel track. Both of those changes came from evidence, not from a redesign exercise done for its own sake. We expect this structure to keep evolving as we find more gaps. When it does, the change and the reason for it will be documented here, not silently folded into an existing category.

How it's organized

The pages in this section are grouped into five parts. The grouping is meant to match how someone would actually want to read it, not how the work happens to be organized internally. The first group is evaluation categories, and it's the closest thing to a fixed reference in this section. There are seven pages, one per category, each covering what the category means, how it's tested, and what the current results look like. The second group is how we evaluate, and it steps back from any single category. It covers red-teaming methodology, the release checklist a version has to clear before it ships, what happens when something is found after the fact, and the ongoing production monitoring that doesn't stop just because a version already passed pre-release testing.

The third group moves from the model itself to the product built around it. A model's own good judgment is one layer of safety. It is deliberately not the only one. The four pages in this group, sandboxing, connector safeguards, data handling, and infrastructure, describe safeguards that hold independently of whether the model gets a judgment call right in a given moment. The fourth group is per-model detail. It covers what's specific to tAI 4.2 and what's specific to tAI 4.1, since a security posture described only in the abstract is less useful than one tied to a specific, currently running version. The fifth group is reference material, meant to be used rather than read start to finish: how to report an issue, answers to the questions this section gets asked most, and a glossary of the terms used throughout it.

Who this is for

This section is written for several different readers at once. It's worth being explicit about who they are. A security team evaluating whether to give tAI access to internal systems wants a certain level of detail. A researcher checking a specific claim wants a different level. A curious user who just wants to know what actually happens when tAI takes an action on their behalf wants something else again. Someone doing a formal vendor security review will likely want the release process page, the infrastructure page, and the per-model system cards, roughly in that order. Someone who just wants a plain answer to "can tAI send an email without me approving it" is better served by the FAQ page than by reading release-process methodology first.

We've tried to write every page so it stands on its own. A reader arriving from a search result or a direct link shouldn't need to have read the rest of the section first. That means some ideas get restated more than once across different pages. The split between conversational and tool-use safety is one example. The idea that a model-level safeguard and a product-level safeguard are independent layers is another. Both get explained again on more than one page rather than referenced obliquely and left unexplained. If that repetition feels heavier than it needs to be when you're reading the section start to finish, that's a deliberate trade against the more common case: a reader landing on a single page from a link elsewhere, needing it to make sense on its own.

What this section doesn't cover

This section is about technical security posture: what's evaluated, how it's tested, and what safeguards hold it up. It is deliberately not the place for legal and policy documents, even where the two topics overlap in a reader's mind. The privacy policy, terms of service, usage policy, and cookie policy live under ai.artfical.com/legal, and they're the authoritative source for anything about legal basis, data subject rights, or contractual commitments. Where this section references something like data retention or deletion, it's giving the plain-language, practical version. The legal pages are where the binding wording actually lives, and where the two would ever appear to disagree, the legal page wins. We link to the relevant legal page directly wherever this section touches on something with a legal dimension, rather than leaving a reader to go find it separately.

This section also isn't the complete, tool-by-tool reference for any single connector. Gmail, Notion, GitHub, and Linear each have their own dedicated documentation covering every available tool and its exact permission scope. The Connector safeguards page in this section covers the safety pattern shared across all four, not the tool-by-tool detail specific to any one of them. Similarly, this section isn't a general product manual. Questions about how to actually use a feature, rather than how it's kept safe, are better answered by the main tAI docs than by anything here. Keeping that boundary clear is what lets each of these three kinds of documentation, security, legal, and product, stay focused and accurate rather than trying to be everything to everyone at once.