The developers of models used to simulate the evacuation from fire events, referred to here as egress models, are in a difficult position. It is in their interest to develop models that are quick and easy to employ, especially given the profusion of models and the expansion of application opportunities. At the same time, it is also in the model developers’ interest to reduce model misuse by inexpert users. Model misuse is characterized here as instances where results are produced through the use of inappropriate data and/or behavioural settings, which can lead to the generation of inappropriate or incredible results. While the authors advocate for the proper use of egress models in quantifying egress performance of a building design, the authors of this article are sceptical advocates of egress models, particularly in their design, their use in regulatory guidance, and the expertise of users. This paper represents an attempt to promote the proper use of egress models by suggesting a means to combat accidental model misuse. Previous work by the authors of this paper considered the availability of default values in simulation tools, and in particular egress models, and their potential for contributing to model misuse. Here, the term ‘default’ relates to a pre-set, fixed value (or distribution) for a parameter (e.g. the value for unimpeded walking speed) or the application of a specific behavioural algorithm in the model (e.g. agents travel along the path to their nearest exit). While the inclusion of default values enables out-of- the-box use of models without in-depth familiarization with input formats and data structures, defaults often represent optimistic and even unrealistic evacuation conditions or occupant behaviour, which can lead to model misuse. Most egress models provide default values for five core behavioural elements: pre-evacuation time, travel speeds, route usage and availability, and flow conditions. These five core behavioural elements typically need to be represented in order for the model to function at all. The authors suggest that bounding default settings, rather than optimistic values, should be provided for each of the core behavioural elements. In the context of this article, a bounding default setting is a value derived from relevant empirical data that prolongs the overall evacuation time produced for a particular design. If the model user wishes to decrease the conservative nature of a particular estimate or set of estimates, which will almost certainly be the case, he/she would then be required to explicitly justify the modification of the bounding default value. This approach then allows the immediate use of the model, but in effect forces the user to modify the settings in order to obtain a credible scenario for the purposes of design. These bounding values are not presented as values typically used in engineering scenarios. They are instead presented as values that would produce conservative results if used and would therefore typically require the user to modify the values in order to represent the scenario of interest. The bounding values suggested are therefore deliberately conservative in order to ensure both user intervention and user justification of this intervention to third parties reviewing the engineering process. The approach presented is designed to support model developers in their desire to have potential engineers use the model out-of-the-box, encouraging training and familiarization efforts, while aiding third party reviewers of the results, allowing them to compare any parameters employed with an accepted set of bounding parameter values. The use of bounding model default parameters is presented as an initial step in addressing accidental model misuse, with the acknowledgement that it would need to be refined and developed. However, this approach might also be integrated into other more substantive regulatory and licensing efforts should they be instigated.