How we protect confidential information
SaferAI evaluates frontier AI systems, which sometimes involves nonpublic model access and proprietary information from AI developers, governments, and research partners. This post describes how we protect that access and information at a high level.
Confidentiality
Our confidentiality practices are designed primarily to reduce the risk of leaks in infrastructure and in conversation. They also reduce insider-threat risks by limiting who has access to sensitive information and, by proxy, what any single compromised or careless user can expose.
Policy
We sort evaluation information into a small number of confidentiality levels, from public to internally restricted, based on the sensitivity of each project. The most sensitive category covers details about a nonpublic model, including model capabilities, evaluation timeline, and source developer. This information stays with the researchers directly involved in the project and is written and spoken about only under an assigned codename.
Information about our own methodology, tasks, and infrastructure circulates more freely inside SaferAI.
Tooling
Channel membership and document sharing are centrally managed, and nothing sensitive can be shared outside the org without an explicit override. We also enforce siloing on specific projects: transcripts and outputs from a given evaluation are visible only to the researchers assigned to it, and sensitive evaluations are managed at the group level using enterprise Identity and Access Management (IAM) tooling (discussed below).
Norms
Before a project starts, every staff member working on it knows which security level applies and what that means in practice. We use a model’s codename even in rooms where everyone already knows who the developer is.
Security
We assess how frontier AI companies manage risk, so we hold ourselves to the same discipline. The controls below follow the approach we recommend in our own work: least-privilege access, layered defenses, and monitoring that assumes mistakes will happen. They protect against external breaches and limit the damage any single compromised account or device can cause.
| Area | Control |
|---|---|
| Authentication & Access | A single identity system is the source of truth for every account. We utilize shared logins and IAM access controls for evaluation infrastructure access. Multi-factor authentication is required everywhere, with hardware security keys as the standard for accounts that can reach sensitive systems. Reaching internal evaluation systems takes two independent steps: network-level access via VPN and a separate application sign-in. Cloud sessions are role-scoped following the principle of least privilege. Inside our evaluation platform, we use role-based access controls so researchers can only see transcripts and outputs from evaluations they’re assigned to. |
| Devices | Mobile device management (MDM) enforces endpoint policies at a CIS level 2 baseline. This includes: Full-disk encryption Automatically installed security updates Enforced Chrome profiles Credentials managed in a centralized password manager, with a separate vault for shared and administrative secrets. Staff working on sensitive projects use hardware security keys. |
| Logging & Detection | Cloud infrastructure activity is logged and monitored. Automated rules flag high-signal events. |
This page reflects our practices as of August 2026 and will be updated as they evolve.
