新一代网页格式WebAssembly提供极佳的执行效率，让浏览器也能够执行像是游戏或是Photoshop这类重量级网页应用程序，而Mozilla要进一步扩展WebAssembly的可移植性，让WebAssembly应用程序顺利跨出浏览器，因此开始推动WebAssembly系统接口WASI，使WebAssembly能以更主动的方式与系统核心沟通。
由于WebAssembly是一个概念机器（Conceptual Machine）而非物理机器的汇编语言，因此可以在不同的平台上执行，而要让WebAssembly在浏览器之外，还能在不同的操作系统上执行，需要一个概念操作系统的系统接口，而这正是Mozilla致力制定WebAssembly系统接口WASI的原因，以扩展WebAssembly到更多的平台。
一般应用程序可以通过系统调用，请求操作系统核心执行特定操作，在多数的设备上，这是程序代码可以访问系统资源的唯一方法，而由于多数开发语言都有标准函示库，因此开发者也不需要知道不同操作系统的实例，只要知道怎么使用接口就行了，当程序代码在编译的时候，工具链会依照程序代码目标系统，选择需要的接口实例，而这个实例则取决于操作系统API的函数，每个操作系统有所区别，像是对Windows机器就会使用Windows API，为Mac或Linux机器编译就会使用POSIX。
但这样的模式却无法套用到WebAssembly上，在WebAssembly编译阶段，系统仍然不知道应用程序的目标操作系统，因此也无法在标准函数库的WebAssembly实例，使用单一操作系统的接口。虽然现在WebAssembly已经可以在浏览器之外执行，但是却使用非正规的方法。
Emscripten编译工具在网页上仿真操作系统接口POSIX，让开发人员特以使用C标准函数库中的函数，为此Emscripten创建了C标准函数库的实例，实例分为两部分，一部分编译成WebAssembly模块，另一部分则以JavaScript中介程序代码实例，而JavaScript中介程序代码会调用浏览器与操作系统沟通。
要在没有浏览器的情况下执行WebAssembly，执行的Runtime需要实例JavaScript中介程序代码中的函数，Mozilla提到，这些JavaScript中介程序代码的接口并非为标准而设计，甚至还对外公开。因此这只能作为暂时的解法，为了WebAssembly生态系统统的长久发展，需要寻求更根本的解决方案。
为了要保持WebAssembly的可移植性以及安全性，Mozilla提出了WebAssembly系统接口解决方案，构建一套模块化的标准接口，而这项工作从最基础的wasi-core开始，wasi-core将包含所有应用程序需要的基础，包括文件、网络链接、时间以及随机数字等POSIX功能，来允许应用程序执行打开、关闭、读取或是写入文件等工作。
但wasi-core也不会涵盖POSIX的所有部分，像是程序概念就不会完全映射到WebAssembly上，而每个WebAssembly引擎也不需要支持像是fork这样的程序操作。 Mozilla表示，模块化的好处在于让利基平台可以只使用适合的WASI部分，像是Rust就能直接在标准函数库使用wasi-core，对C和C++而言，则可以使用C标准函数库实例wasi-sysroot。 Mozilla希望Clang这类编译器也可以与WASI API兼容，像Rust编译器和Emscripten等工具链，把WASI纳入系统实例中。
Mozilla表示，wasi-core是WebAssembly正式跨出网页的第一步，并为其生态系统统创建了良好的基础，而在wasi-core完全标准化之后，还需要解决异步I /O、文件监控与文件锁定等工作。