Anthropic's Frontier Safety Roadmap

Candidate projects include:

• An operational Mock Secure Research Environment, aiming to simulate at a very small scale what our key workflows and infrastructure would look like (and what the productivity impact would be) if they were subject to extreme security practices. This would include simulating isolated networks,“green lines” for limited remote connections, as well as commensurate physical security controls.
• An analysis of the feasibility of full adoption of confidential compute during the entire lifecycle of model R&D.
• An initial assessment of what AI-assisted security tooling (vulnerability discovery, automated patching, anomaly detection) is feasible today.
• A pilot of a continuous personnel security vetting program for high-risk roles with defined screening criteria, monitoring, and reporting requirements.
• A pilot of a system in which all interaction with our models (including internal research and training) uses APIs rather than interaction with raw model weights.
• An attempt to create adaptive behavioral models for flagging anomalous activity by users and services on our systems (flagged anomalies should adapt as our workflows and usage patterns change).
• An attempt to identify our most valuable algorithmic IP and a path to giving it additional protections.

By April 1, 2026, we will have selected and begun 1-3 project(s), including but not limited to those above, and established concrete further goals and timelines for each. Each should lead to a working answer to the key open questions within 6 months.

We are highly confident that we can complete this initial step, and will use it as a jumping-off point to set further goals.

To assess whether we have reached this goal, we will prepare a report for the Responsible Scaling Officer to mark each invariant as "Not in place," "Mostly in place" or "Fully or near-fully in place." The report's conclusions (though not all details of our security posture) will be circulated to the full company and there will be at least a 7-day comment period for people to remark on observations they've made that may not be consistent with the conclusions. We will consider this goal reached if both of the following are true: we have achieved "Fully or near-fully in place" for at least 60% of invariants, and we have achieved "Mostly in place" for at least 80% of invariants.

We're in a unique position to contribute meaningfully to AI security practices across the industry. We aim to systematically share what we’ve learned from all of our security commitments—through blog posts, conference talks, and open source contributions—to help raise the security bar across the AI industry

We have moderate confidence that we can achieve this goal. The list of invariants is long and has many dependencies, and we will need substantially more security capacity staffing than we currently have, but we’ve made a substantial effort to determine what is realistic.

We will establish an internal jailbreak-finding method for classifier guards (focused on chemical and biological weapons) that matches or exceeds the current collective abilities of all of our bug bounty participants to find jailbreaks. We will assess this via a report that evaluates whether our internal findings are more substantial in aggregate than our bug bounty findings.

We have moderate confidence that we can achieve this goal. We have a technical path in mind that we believe should succeed if we can execute on it well, but this is a research problem and progress may be hard to predict.

We will develop an automated system intended to detect a large majority of sophisticated cyber attacks that use Claude, with minimal or no human involvement, along with a plan to assess precision and recall (likely based on red teaming).

This system will not necessarily be usable for all of our product surfaces and environments at the outset. It will be a proof-of-concept that we assess in the environments most conducive to it, which will include major production environments.

We have moderate confidence that we can achieve this goal. We already have some preliminary systems that provide a starting point.

We will write a comprehensive internal report to identify how our Safeguards could be improved by updating our data retention policies. Within 6 weeks of report completion, we will publish a new goal related to this or announce that we aren’t doing so.

We are highly confident that we will complete this report, and will use it as a jumping-off point to set further goals.

Keeping the Constitution up to date and running a systematic oversight process. We will ensure that the public Claude’s Constitution stays in sync with what we use internally (updating it within 90 days of relevant internal updates). We may also use additional guidelines and other training data (such as human preference labels) that are in line with Claude’s Constitution without publishing those.

We will run an oversight process over a representative sample of our production-relevant post-training data and rewards to evaluate alignment with the Constitution, aiming to ensure that we review for any egregious inconsistencies with the Constitution in ways that Claude itself can detect and will describe this oversight process in our Risk Reports.

In the future, we will work to extend the above to all models used in high-stakes usage, including, e.g., internal-only models used for evaluation purposes. But our immediate goal is to establish the above for our mainline models.

Our long-term goal, which may require further progress after we achieve the goal listed here, is that cases where production releases of Claude egregiously violate the Constitution on real-world traffic in ways that Claude itself could detect are rare or require explicit jailbreaks.

We have moderate confidence that we can achieve this goal. We already take measures along the lines of the above, but will work to make them more consistent and systematic.

Alignment assessments. We will continue developing and maintaining our alignment assessment pipeline (see past alignment assessments in our system cards) and will ensure that it makes use of both interpretability and non-interpretability techniques. We will aim to use interpretability in particular in such a way that it produces meaningful signal beyond behavioral methods alone. We will thoroughly red-team our alignment arguments, which will likely include testing our assessment pipeline by assessing adversarially-designed misaligned model-organisms, though we may take other approaches if the analysis in our Risk Reports depends primarily on something other than auditing. We will continue to apply this auditing pipeline (a) prior to publicly deploying any model that is significantly more capable than any of the models described in our previous Risk Report; (b) within a reasonable period of time following the deployment of an internal or other non-public model that we determine could pose notable risks (in line with the threat models emphasized in our most recent Risk Report) distinct from those of public models. The latter will—at a minimum—include any internal models that we are deploying for large-scale, fully autonomous research and that are significantly more capable than our most capable such models as of the publication of our previous Risk Report.

We will be open about what we find, as feasible while protecting our IP around the development of model capabilities. For new internal deployments, the Responsible Scaling Officer can (and usually will) allow a temporary internal deployment before the audit is complete. This will be allowed as long as we complete our audit and seek another approval within a reasonable period of time. Our Risk Reports will examine these decisions.

We have high confidence we can achieve the non-interpretability parts of this goal and moderate confidence that we can achieve the interpretability parts of this goal. Our current practices are already fairly similar to the above, but it will require ongoing effort to maintain and improve their adequacy in the face of improving capabilities and to fully expand their coverage to internal deployments. We have done several limited red-teaming exercises to date, but think more would be needed in order to qualify as thoroughly red-teaming our alignment arguments, and using interpretability techniques on new frontier models are at risk of taking longer than initial release dates.

Security team subgoal

We will improve our observability across the board to the point of relative maturity - involving centralized, searchable logs with the most important relevant information for all of our critical security systems, and robust processes for keeping these logs available. We believe that if we can establish comprehensive logging of crucial internal activity, we’ll put ourselves in a much better position to leverage current and future advanced AI capabilities for security (since AI systems can be used to analyze our logs). We also believe that some key threat models - including the possibility of both human and AI attackers corrupting our training runs - could be significantly ameliorated if we simply have high odds of detecting when they happen (even if response to those detections lags considerably).

To assess whether we have reached this goal, we will prepare a report for the Responsible Scaling Officer to mark each invariant as "Not in place," "Mostly in place" or "Fully or near-fully in place." The report's conclusions (though not all details of our security posture) will be circulated to the full company and there will be at least a 7-day comment period for people to remark on observations they've made that may not be consistent with the conclusions. We will consider this goal reached if both of the following are true: we have achieved "Fully or near-fully in place" for at least 60% of invariants, and we have achieved "Mostly in place" for at least 80% of invariants.

We have moderate confidence that we can achieve this goal (somewhat more so than for our security maturity goal). The list of sub-goals is fairly long and has many dependencies, and we will need to prioritize and resource this work more than in the past, but we’ve made a substantial effort to determine what is realistic.

Alignment team subgoal

We will ensure that we are cataloging all high-stakes internal usage of Claude, such as situations where we use Claude internally for fully autonomous research or other situations where it might have an opportunity to engage in catastrophic sabotage, in line with our current threat models.

We will implement monitoring that we believe is sufficient to produce evidence of egregious sabotage-oriented activities in high-stakes use cases with high probability, under the assumption that Claude has general capabilities broadly comparable to those of a full-time entry level Research Engineer. In cases where we have high confidence that models are sufficiently aligned such that risks are low, we will not consider this monitoring to be necessary.

We will evaluate the effectiveness of our monitoring tools, likely using a combination of human and automated red teaming and adversarially-designed model organisms, and will discuss our findings in our Risk Reports.

We have moderate confidence that we can make Claude aligned enough that monitoring will not be strictly necessary, at least in the medium term. We have moderate-to-high confidence we can put our monitoring goal in position to achieve the goal, as needed. We already do a fair amount of internal monitoring, but need to make it more comprehensive and accurate.