Beam Responsible Use Guide

The mission of Reflection AI, Inc. (“Reflection”) is to make intelligence open and accessible to all. We build open models so that individuals and institutions can exercise meaningful control over the intelligence they rely on and participate directly in shaping the future of AI. We are convinced that openness is a powerful engine of progress. Shared models broaden participation and enable ecosystems of research, innovation, and economic opportunity that no single organization can reproduce on its own. They also make independent scrutiny possible: researchers and developers can inspect, stress-test, adapt, and improve models and their safeguards, strengthening not only individual systems but the wider AI ecosystem. This commitment reflects a broader principle. The capabilities of one of the most consequential technologies of our time should be widely distributed rather than concentrated in the hands of a small number of providers. Students, researchers, developers, companies, governments, and institutions should be able to study advanced AI, build on it, and deploy it on their own terms. Access to model weights gives organizations meaningful control over the AI systems they rely on. It enables them to operate models within the infrastructure they govern, apply their own security, compliance, and oversight frameworks, and adapt the technology to their specific needs. Openness, in this sense, is more than access to a model. It provides durable agency over the technology on which institutions increasingly depend.

​

About This Guide

This Responsible Use Guide provides practical guidance for responsibly adapting, integrating, deploying, and operating Beam. The Guide is built around five principles:

• Know what you are deploying
• Control what the model can do
• Increase safeguards with autonomy
• Test the system you actually build
• Design for failure

This Guide should be read with the Beam model license, the Acceptable Use Policy, the Beam model card, the Model Technical Report, and Reflection’s Open Safety Framework, all linked . Those materials describe Beam, how it was developed, and how we evaluated it. This Guide addresses the next stage: how to deploy and use Beam responsibly. Responsibility after release: Once an organization downloads and deploys Beam, it assumes responsibility for the system it creates around the model, including the capabilities and permissions it enables, the safeguards it implements, the evaluations it conducts, and the behavior experienced by its users. That responsibility becomes particularly important when the model is modified. Our evaluations and safety findings apply to the model as released by Reflection. Fine-tuning, merging, or otherwise modifying the weights may alter the model’s capabilities and safety characteristics and should therefore be accompanied by appropriate evaluation and safeguards. This Guide is intended to make that transition of responsibility clear and provide practical guidance for managing it. How to interpret this Guide: This Guide sets out recommended practices. The appropriate measures will depend on the nature of the deployment, the capabilities made available to the model, and the risks associated with its intended use. This Guide is not legal advice and does not replace your own assessment of the risks your application presents or your obligations under applicable law.

​

Understand the Model

Before building with a Reflection model, understand what the model can do, where it has been evaluated, and where its limitations remain. Reflection publishes information about each model’s capabilities and safety characteristics through its model card, the Open Safety Framework, and the Model Technical Report. Before deployment, review the information relevant to your intended use, including:

• Intended uses and known limitations
• Capability and safety evaluations
• Safety training and safeguards
• Known failure modes and residual risks
• Supported model variants and configurations

AI models can produce inaccurate, incomplete, inconsistent, or inappropriate outputs. Their performance can also vary across tasks, languages, contexts, and deployment environments. Reflection’s evaluations describe the Beam model we released under the conditions in which we evaluated it. They should not be treated as a guarantee of performance or as being representative of an application built with the model. If you materially modify the model or place it in a substantially different deployment environment, you should reassess whether the original evaluation results remain applicable. Residual risks to plan for: Because of the nature of open-weight models, the behavior of the model is dependent upon the manner in which it is deployed. Deployments should therefore be designed with these points in mind.

• Safety training is not an immutable property of the model. Beam’s trained safety behavior can be weakened or removed through subsequent fine-tuning, whether deliberately or as an unintended consequence of task-specific adaptation. Model-level safety should therefore be treated as one layer within a broader system of safeguards, rather than as a substitute for deployment-level controls.
• Model modifications can change safety behavior. Quantization, distillation, merging, and other modifications may alter safety characteristics even where general benchmark performance remains broadly unchanged. Modified models should be evaluated on their own properties rather than assumed to retain those of the original model.
• Evaluation results do not capture every deployment environment. Our evaluations are conducted using defined configurations, datasets, and testing conditions. Production environments may introduce materially different conditions, including longer contexts, additional languages, adversarial interactions, and tool-enabled or multi-step workflows. Deployment-specific evaluation remains important.
• Controls implemented by a hosting or application layer are not embedded in the released model parameters. Open weights can be run independently of Reflection and of any controls implemented by a particular deployer. Organizations should therefore ensure that safeguards on which they rely are implemented and maintained within the systems they control.

The Beam Model Card describes the conditions under which we evaluated the model and the results we observed, including changes in safety behavior following model modification. We recommend reviewing those findings before fine-tuning or otherwise modifying Beam.

​

Understand Your Deployment

The potential risks associated with your use of a Reflection model will depend upon how you choose to deploy and adapt that model. A model used to summarize documents presents a different deployment profile from the same model connected to a browser, code execution environment, financial account, or other external system. As a starting point, it is important for you to identify the level of autonomy in your deployment: These levels are cumulative. If you are deploying a system at a higher level, you should generally implement the controls appropriate to the levels below it as well. Classify honestly: Classify your system according to what it can actually do, not how it is described or intended to be used. Teams can underestimate the level of agency their systems possess. A summarizer with access to a shared document store is L1, not L0. An assistant that files a ticket on a user’s behalf is L2, not L1. A coding assistant that executes the tests it generates is L3. As a practical rule, if the system can take an action that would require a person to intervene to reverse, it should be classified at least as L2. Also consider factors that can increase the consequences of failure or misuse, including:

• Access to sensitive data
• Privileged system access
• Scale and number of users
• Ability to affect third parties
• High-impact or consequential decisions
• Vulnerable users
• Actions that are difficult to reverse
• Public or externally accessible deployment

The relevant distinction is not how a product is described, but the authority it gives the model: what the system can access, change, execute, persist, or delegate.

​

Define Your Use Policy

Before designing safeguards, establish clearly what your system is intended to do, and where its boundaries lie. A deployment-specific use policy provides the foundation for the controls that follow. Classifiers, permissions, evaluations, and escalation procedures should all operate against a common set of defined expectations. A practical use policy should distinguish among four categories:

• Prohibited. Uses the system must not support under any circumstances.
• Restricted. Uses permitted only where specified conditions are met, such as human review, verified users, limited tool access, or jurisdiction-specific requirements.
• Permitted. Uses for which the system is designed, evaluated, and supported.
• Out of scope. Uses that are not expressly prohibited but have not been evaluated or supported.

The policy should reflect the realities of your deployment rather than rely on a generic list of prohibited topics. Consider who can use the system, what information and capabilities it can access, what actions it can take, and how those capabilities could lead to harm. Define boundaries around those pathways. Topic-based policies alone can be both overinclusive and underinclusive, restricting legitimate activity while failing to address harmful behavior that falls outside predefined categories. The policy should also be operational. Each requirement should map to an enforceable or verifiable control, such as a classifier, permission boundary, evaluation case, or review process. A policy that is not reflected in the operation of the system remains documentation rather than an effective safeguard. Finally, assign clear ownership and establish a regular review process. Your deployment policy should remain consistent with the Beam model license and Reflection’s applicable use guidance, which continue to apply alongside any additional requirements you establish.

​

Control What the Model Can Do

Separate what the model is technically able to do from what the deployed system permits it to do. A model being capable of performing an action does not mean your system should give it permission to perform that action. As models gain access to tools and external environments, developers should control separately:

• What the model can see: Limit access to the information required for the intended task. Apply appropriate permissions to sensitive data, retrieval systems, files, databases, and user information.
• What the model can call: Restrict the tools, APIs, services, and functions available to the model. Do not expose unnecessary capabilities.
• What the model can change: Use least-privilege credentials and limit write permissions. A system that needs to read a repository, for example, should not automatically receive permission to modify it.
• What the model can spend: Set appropriate limits on financial transactions, API usage, compute, retries, and other resources.
• What the model can delegate: For agentic and multi-agent systems, define whether the model can create subtasks, invoke other agents, or delegate permissions. Bound the depth and scope of delegation. A subagent should not be able to acquire authority its caller did not hold.
• What requires human approval: Use meaningful human authorization for consequential or difficult-to-reverse actions where appropriate. Approval should occur before the action is executed and provide enough information for the reviewer to make an informed decision. Approval that arrives too frequently, too late, or without the context needed to evaluate it will be granted reflexively, which is worse than no approval step because it creates a record suggesting review occurred.
• How the system can be stopped: Design mechanisms to interrupt or contain unwanted behavior, including timeouts, circuit breakers, permission revocation, rollback, and kill mechanisms where appropriate. Test these while the system is running, not only in design review.

As a general rule, the harder an action is to reverse, the stronger the controls should be before it is executed.

​

Build Your Safeguard Stack

Do not rely on the model’s trained behavior as your only safety mechanism. As described above, that behavior can be modified or removed, and on open weights it is the layer least under your control. The model is part of the safeguard stack. It is not the safeguard stack. Deployers may also use open safeguard models published by other developers alongside Beam. Any third-party safeguard should be evaluated against your own use policy and deployment context rather than adopted based on its default configuration. Its performance and license terms remain those of the third-party provider. Depending on the deployment, a defense-in-depth approach may include several layers.

• Input controls: Detect or restrict abusive, malicious, or otherwise disallowed inputs where appropriate.
• Instruction controls: Separate trusted system instructions from user input and other untrusted content. Protect system-level policies from unauthorized modification.
• Retrieval controls: Apply access controls to retrieved information and treat retrieved content as potentially untrusted. Consider the provenance and permissions associated with information entering the model’s context.
• Output controls: Apply appropriate output classification, validation, grounding, or review before outputs reach users or trigger downstream actions.
• Action controls: Authorize sensitive actions at the point of execution rather than relying solely on the model to decide whether an action is appropriate.
• State and memory controls: Control what information is stored, for how long, and who or what can access it. Maintain appropriate separation between users and trust domains. In systems that retain memory across sessions, treat stored content as a durable input: information written once can influence behavior indefinitely, and content that entered from an untrusted source should not become trusted merely because it persisted.
• Human controls: Provide escalation and review mechanisms where model outputs or actions can have significant consequences.
• Operational controls: Use appropriate logging, rate limits, anomaly detection, access enforcement, and incident response. In practice this means content returning from a tool, a retrieval, or a web page is input from an untrusted party rather than context, and should pass the same controls you apply to user input. Where a system cannot distinguish instructions from data, the effective defense is at the point of action rather than in the phrasing of the prompt.

For systems using retrieval, browsing, tools, or agents, design retrieval and tool integrations so that externally supplied content cannot acquire the authority of trusted instructions. Untrusted content should not silently acquire authority to instruct the system or authorize actions. We also plan to release the Reflection Safety Suite, an open evaluation suite designed to help the community assess how effectively a deployed safety stack detects and addresses harmful behavior across a broad range of harms. The Safety Suite is intended to support evaluation of the system as a whole, not only the safety behavior of the underlying model.

​

Test What You Deploy

Reflection evaluates the Beam model it releases. You should evaluate the system you build. These answer different questions: ours asks what the model can do, yours asks whether your system behaves acceptably for your users. Our results cannot substitute for yours. A deployed system may combine the model with prompts, fine-tuning, retrieval systems, tools, permissions, memory, safeguards, and other components. Each can change the behavior and risk profile of the resulting system. Before deployment, evaluate at least four dimensions:

1. Capability: What can the system actually do, including capabilities that were not central to its intended use?
2. Reliability: Does the system perform its intended task consistently and accurately enough for the deployment context?
3. Safety: How does the system behave when users misuse it, attempt to circumvent safeguards, or request harmful outputs?
4. Security: Can users, external content, or other systems manipulate the model’s tools, data, credentials, permissions, or actions?

Evaluation should reflect the environment in which the system will actually operate. For systems with tools or external access, testing should consider risks such as prompt injection, tool abuse, privilege escalation, data exposure, unintended actions, and multi-step attacks. Derive your test cases from your use policy. Each prohibited and restricted use should have at least one case that checks the system actually behaves as the policy says. Add adversarial cases written by someone who did not build the system, and keep the set under version control alongside the code it tests. Decide your release criteria before you test, not after. Write down what results would cause you not to deploy. Set release thresholds in advance so the acceptance criterion is not influenced by the observed results. Do not treat evaluation as a one-time release exercise. Re-run relevant tests after material changes to:

• Model weights
• Fine-tuning
• System prompts
• Tools
• Permissions
• Retrieval systems
• Safeguards
• Deployment environment

Test the system you actually deploy, not only the model you started with.

​

Higher-Risk Uses

Some uses require additional care because model errors, misuse, or unintended actions can create more serious consequences. Examples include, but are not limited to:

• Software and cybersecurity: Beam is a capable coding model. Take particular care with deployments that discover or exploit vulnerabilities, generate offensive tooling, or commit agent-authored code to systems others depend on.
• Biological, chemical, radiological, and nuclear domains: Do not rely on topic filtering alone in these domains; use access, scope, and domain-specific review controls appropriate to the deployment. Where a deployment touches these areas, prefer restricting access, narrowing scope, and adding domain review over relying on refusal behavior.
• Health and clinical care: Distinguish between providing information and directing care. Documentation, summarization, and administrative support carry different risks and obligations from diagnosis, dosing, or treatment recommendations. For uses that may affect patient care, consider clinician review before outputs reach patients or inform treatment, and assess whether the application is subject to medical device or clinical decision support requirements in each jurisdiction where it operates.
• Financial or legal services: Regulatory requirements for advice, suitability, professional practice, and decision-making apply regardless of whether AI produced the output. Beam may generate plausible but incorrect citations, authorities, or figures. Verify material references against primary sources before they inform client advice, filings, or consequential decisions, and retain appropriate records of AI-generated outputs and human review.
• Human resources and employment: Screening, ranking, and evaluating people can produce disparate outcomes even when protected characteristics are not explicit inputs. Some jurisdictions also impose requirements such as bias testing, candidate notice, or human oversight. Preserve meaningful human decision-making, test for disparate impact across relevant groups, and maintain records sufficient to explain and review individual decisions.
• Minors and vulnerable users: Consider age-appropriate deployment, conversations that may touch crisis or self-harm, and clear escalation to a human. Some situations should not be handled by an automated system at all.
• Elections and political persuasion: Consider disclosure to end users, provenance for generated content, and controls against coordinated inauthentic use.
• Defense, intelligence, and export-controlled contexts: Consider classification boundaries, the human judgment your application requires before it acts, and the export control obligations that attach to model weights and to your deployment.
• Other consequential decisions affecting individuals.

For these deployments, general-purpose model safeguards may not be sufficient. Consider stronger domain-specific controls, specialized evaluations, restricted access, appropriate human oversight, logging and auditability, and clearly defined escalation procedures. Before deploying in a higher-risk context, ask:

• What happens if the model is wrong?
• What happens if the model is deliberately misused?
• What happens if a safeguard fails?
• Can the resulting action be detected, stopped, or reversed?
• Is human judgment required before the system acts?
• Who is accountable for the outcome, and do they know they are?

​

Modify and Redistribute Responsibly

Open weights allow developers to adapt models for new purposes. Those modifications can also change the model’s capabilities, reliability, and safety behavior. Relevant modifications may include:

• Fine-tuning
• Preference tuning
• Continued training
• Model merging
• Distillation
• Quantization
• Other material changes to model behavior

If you materially modify a Reflection model, document what you changed and reassess the resulting model. At minimum, consider recording:

• The model and version you started from
• The modification performed
• The purpose of the modification
• Relevant evaluations rerun
• Material changes in capabilities or behavior
• Identified regressions
• Safeguards applied
• Intended deployment context

When you modify the weights, Reflection’s safety findings no longer describe your model. This is not a formality: fine-tuning can reduce refusal behavior substantially, including when the tuning data contains nothing harmful and the objective is unrelated to safety. Re-run the safety evaluations that matter for your deployment before you ship, and if you lack the infrastructure to do so, treat that as a reason to deploy the unmodified model rather than a reason to skip the step. If you redistribute a modified model, clearly distinguish it from Reflection’s original release and provide downstream users with enough information to understand its lineage, modifications, evaluations, safeguards, and known limitations. Pass on what you would have wanted to receive: your recipients are making the same decisions you made, with less information.

​

Monitor, Respond, and Improve

Responsible use continues after deployment. Where appropriate, introduce systems progressively: Test → limited deployment → broader deployment Monitor signals relevant to your system, which may include:

• Safeguard activations
• Abnormal tool use
• Attempts to circumvent controls
• Unexpected model behavior
• Action failures
• User reports
• Performance or behavioral drift
• Newly identified vulnerabilities

Decide before deployment what conditions should trigger intervention. Depending on the system, responses may include:

• Strengthening safeguards
• Restricting permissions
• Disabling a tool
• Limiting access
• Rolling back a change
• Suspending the deployment

A simple incident-response cycle is: Detect → Contain → Investigate → Correct → Re-evaluate Decide in advance who can invoke each of these and who is reachable out of hours. An incident is a poor time to discover that the only person who can revoke a credential is on leave. After a significant incident or material change, evaluate whether existing safeguards and deployment assumptions remain appropriate.

​

Reporting Issues to Reflection

Responsible open-model development depends on information flowing back as well as outward. We encourage developers, researchers, and deployers to report significant issues involving Reflection models, including:

• Previously unidentified model vulnerabilities
• Material safeguard failures
• Unexpected dangerous capabilities
• Significant safety regressions
• Novel or systemic misuse patterns
• Security issues affecting Reflection-provided tools or safeguards

Please send an email to and include enough information to reproduce and assess the issue, where safe and appropriate.

​

Keeping this Guide current

This Guide will evolve alongside Beam and our understanding of how it is used in practice. We will update it as new risks, failure modes, and effective safeguards emerge. Material revisions will be dated and accompanied by a summary of the changes. If you identify guidance that is inaccurate, unclear, or incomplete, please contact us at . Feedback from organizations deploying Beam in real-world environments is particularly valuable in helping us improve this guidance over time.