Anthropic Responsible Scaling Policy Explained

What the Responsible Scaling Policy is designed to do

The Anthropic Responsible Scaling Policy is a living, provider-side safety framework. Its purpose is to prevent frontier model capability from outrunning the safeguards needed to manage severe misuse and autonomy-related catastrophic risk. Rather than treating safety as a fixed checklist at release time, the RSP ties continued training and deployment to measured capability thresholds and to the operational and technical controls those thresholds demand.

In structure, AI Safety Levels resemble biosafety levels: as capability and potential for severe harm increase, required safeguards intensify. Official policy materials describe the RSP as the mechanism Anthropic uses to decide when models may be deployed and which protections must accompany higher ASL designations. Anthropic has publicly iterated the policy, including a 2024 update, to refine capability thresholds, evaluation procedures, and safeguard expectations as frontier systems evolve.

For enterprise AI governance leaders, the practical takeaway is narrow but important. The RSP governs Anthropic’s own scaling decisions. It is evidence about how the vendor approaches dangerous-capability evaluation, access control, and release discipline. It is not an enterprise AI management system, and it does not certify that a customer’s composed agent stack is safe for a given use case.

RSP at a glance

AI Safety Levels, thresholds, and deployment commitments

Under the RSP, Anthropic commits to define capability thresholds, run evaluations for dangerous capabilities, and implement corresponding safeguards. If required safeguards cannot be implemented, scaling or deployment is restricted until mitigations are in place. Capability assessment draws on dangerous-capability evaluations covering areas such as CBRN-relevant assistance, cyber offense potential, and autonomy-relevant behaviors. Those results inform ASL determination before broader deployment.

Public materials describe ASL-2 as applying to models that show early signs of dangerous capabilities, where basic safety and security practices are required. ASL-3 addresses higher misuse and autonomy-related catastrophic risk and calls for substantially stronger access controls, security measures, and deployment constraints. Higher ASLs imply tighter model-weight security, stricter access restrictions, monitoring expectations, and deployment limits on the provider side.

Enterprises should treat ASL labels as version-sensitive context, not static brand attributes. Policy text and threshold definitions have changed over time. Procurement and risk teams need the ASL-related claims and evaluation scope that apply to the specific model versions in use, plus notice processes for when capability profiles or safeguard obligations change. Public RSP materials explain framework intent and ASL structure; full internal protocols, exact threshold metrics, and some safeguard details may be only partially disclosed. Primary Anthropic policy pages should take precedence over secondary summaries.

Why ASL designation does not secure enterprise agent systems

Enterprise agent stacks compose a base model with retrieval, tools, orchestration, and identity systems. Safety properties of that composed system are not guaranteed by ASL designation alone. Tool-calling and computer-use style interfaces expand the action surface: the model can initiate multi-step operations against internal APIs, data stores, and external services. Residual risks such as prompt injection, over-privileged tool calling, data exfiltration, and uncontrolled multi-step actions sit outside a model provider’s scaling policy.

NIST’s AI Risk Management Framework reinforces the same separation of duty. Organizations must apply govern, map, measure, and manage functions to their own AI systems regardless of vendor safety policies. Provider evaluation evidence is necessary input to enterprise risk analysis. It is not a substitute for use-case-specific control design, testing, and ongoing operational monitoring.

In practice, governance teams should document a clean ownership split. Anthropic covers training and deployment safeguards under the RSP. The enterprise owns use-case approval, data governance, agent permissions, runtime policy enforcement, incident response, and residual risk acceptance for any agent that can act on enterprise systems beyond chatbot-only interaction.

Criteria for procurement and internal alignment

• Pin model and ASL context: Inventory model versions in use and record which RSP/ASL context and published evaluation scope apply to each version.
• Demand change notification paths: Require clear processes for capability-threshold crossings, safeguard changes, and customer notification affecting deployed models.
• Separate questionnaire from contract: Align RSP questionnaire responses with contractual expectations on incident notice, security controls, and model-change communication.
• Own residual agentic risk: Document residual risk acceptance where agents can act on enterprise systems; chatbot-only assumptions do not transfer to tool-enabled agents.
• Stage deployment on residual risk: Move offline evaluation to limited production to broader rollout only when exit criteria for monitoring, permissions, and policy enforcement are met.
• Map to internal frameworks: Treat RSP as vendor risk input to NIST AI RMF or equivalent functions; do not equate vendor policy alignment with regulatory compliance.