What to Check Before Installing a Slicer Plugin — OrcaSlicer’s Permission System and PrusaSlicer’s Sandbox, Read with AI

You install one distributed plugin into your slicer. That alone puts its code in a position to read your local files, connect to the network and start other programs. OrcaSlicer 2.5.0-alpha (10-16) opened the plugin hub on Orca Cloud, and PrusaSlicer added a signed-bundle mechanism in 3.0.0-alpha11 (09-01) (the source this article reads is the subsequent alpha12; the marketplace is still in testing). In both, the groundwork for distributing and receiving plugins is falling into place. The problem is that you cannot fully read what that code does before installing it. How do you judge slicer plugin security — the security of a distributed plugin — before you install it? That is the subject of this article.

This article contains affiliate links. As an Amazon Associate, we earn from qualifying purchases.

The two slicers answer this in entirely different ways. OrcaSlicer lets plugins run, and asks the user for confirmation every time they touch the OS — a “permission system”. PrusaSlicer never hands Lua the functions that would allow dangerous operations in the first place — a “sandbox”. In this article we lay out what to check before installing, from both projects’ release notes and the original text of source code pinned to a tag. We also add the results of a single run in which we had AI read ten legitimate plugins and checked whether it correctly classifies each plugin’s OS-touching operations. All numbers come only from the pinned source, the official documents and the records of this run.

“Permission system” and “sandbox” — two ideas behind plugin security

A plugin here means extra code that the slicer loads and runs inside itself. OrcaSlicer uses Python and PrusaSlicer uses Lua. Despite the shared name, these are different from the Claude Code plugins (folders bundling skills and hooks) covered in Learning the Claude Code settings in the exam guide hands-on — MCP, skills, hooks and subagents one by one (published 2026-10-23). These are code running inside a single application, the slicer.

The ideas behind plugin security split in two. OrcaSlicer does not stop execution. Instead, it catches the moment a plugin reaches for OS functions such as files or the network, shows the plugin’s name and “what it is trying to do” on screen, and asks the user. The official release notes say clearly that this is “not a sandbox”: “This is a permission system, not a sandbox, so only install plugins from sources you trust.” Turned around, a permission system means that once the user presses Yes, the operation counts as approved.

PrusaSlicer comes in from the opposite side. It never gives Lua the tools that allow dangerous operations. The official release notes explain the choice of Lua: “This is why we chose Lua – the system is more or less designed to be sandboxed, and the plugin can be very simply restricted from accessing filesystem, executing other processes and similar.” The position is to keep access to the filesystem and the execution of other processes closed by design. Neither is better; they simply defend at different layers. Both versions are alphas, and the projects state that the APIs may change, so please read this on the assumption that behaviour may differ in the stable releases. We laid out the overall position of the two slicers in Slicer plugins arrive in OrcaSlicer 2.5 and PrusaSlicer 3.0 — what changed in the two test builds and what is still open (published 2026-10-26). Both are open source under AGPL-3.0.

OrcaSlicer’s permission system — it asks about things outside the data folder, and blocks config and tokens

OrcaSlicer’s permission system is built on Python audit hooks. The hook is installed not with Python’s sys.addaudithook but with the C API PySys_AddAuditHook, and it is installed after the interpreter is initialized and before any plugin code is loaded. The entry point is a table mapping event names to OS-touching operations. In the pinned source, 66 event names are listed by category — reading, writing, creating and deleting files, HTTP, sockets, launching and replacing other programs, and creating threads — and open alone gets special treatment depending on its mode (read or write).

The operations that require permission are summarized in the release notes: “When a plugin tries to work with files outside OrcaSlicer’s data folder, connect to the network, launch another program (or replace OrcaSlicer with one) or start a background thread, a prompt names the plugin and what it wants, and your answer is remembered.” Files outside the data folder, the network, launching and replacing other programs, and background threads. The confirmation shows the plugin name and the request, and the answer is remembered. Only some answers are remembered, though. Creating files or folders outside the data folder, and deleting them, have no remembered list, so you are asked every time. A plugin can also declare the files it needs in advance, in which case you are asked once at load time. The project writes, “A plugin can list the files it needs up front, so you’re asked once when it loads.”

Meanwhile, some operations are blocked outright with no prompt: the config file and the Orca Cloud login token. The release notes say “Plugins can’t read OrcaSlicer’s own config file or your Orca Cloud login token”. There are two blocking methods. The config file and token are blocked by prefix match on registered names (OrcaSlicer’s config file and token file names). It is case-insensitive and blocks anything starting with that name, so a backup copy with .bak appended to the same name is also blocked. Separately, any folder whose path component exactly matches one of secret, secrets, cert, certs, certificate, certificates, conf or config (an exact component match, not a substring match — a name like Conference that merely contains one is not blocked), plus .conf and .ini files, are blocked too. The list of folder names is written in the source like this.

return {"secret", "secrets", "cert", "certs", "certificate", "certificates", "conf", "config"};

What is easy to overlook is that this “block” check runs before the check that allows the data folder. So the config file, the token, and anything named secrets or config are blocked even inside the data folder. Conversely, any other file inside the data folder can be read and written without confirmation. A source comment describes the data folder as “the primary globally-allowed root during plugin execution: read+write”. And this folder contains the plugin storage and the profile cache. Reading this together with the developer documentation, it appears one plugin could rewrite another plugin’s files without confirmation. This is an inference from reading code and documents; we did not verify it by running anything. The bundled Python is 3.12.13 according to the build configuration. As OrcaSlicer itself officially says, it is “not a sandbox” — once you press Yes, no layer separates plugins.

What is not audited — load time, inside threads, native code

What helps most before installing is knowing where the permission system does not look. The confirmation prompt only appears for operations that pass through the “trampoline”, where a plugin’s function is called from the C++ side. Turned around, code running outside that path is not asked about even when it touches the OS. There are three such places.

The first is code that runs at load time. The official developer documentation says, “and plugin import/registration before the first trampoline call, stay unaudited.” Before the first trampoline call — that is, while the plugin is being loaded and registered — is outside the audit context. In the source as well, the audit context is held in a per-thread variable that represents “the plugin currently running”, and the loading path has no macro that opens that context. So code written at the top level of a module is not asked about whether it reads files or connects to the network. This comes from reading code and documents; we did not verify it by running anything.

The second is inside threads the plugin starts itself. The documentation says, “the context does not propagate to a Python thread the plugin spawns itself”. Because the audit context is a per-thread variable, it is not inherited by a new thread. So the moment of starting a thread is asked about (thread creation is in the Threading category), but operations inside that thread pass through. The third is loading native code. OrcaSlicer’s mapping table has no ctypes events. Python’s audit event table has “ctypes.dlopen name”, but OrcaSlicer’s table does not pick it up. The developer documentation also says native-code loading is out of scope. All we can say is that “the mapping table has no ctypes events”; we did not check whether the bundled Python includes ctypes.

The G-code post-processing stage also has a range outside confirmation. A source comment says of this stage (Step.psGCodePostProcess), “At this step the plugin edits the exported G-code file in place”. According to the official wiki, the folder containing the exported G-code can be read and written without confirmation only while this stage is being called. Rewriting the contents of G-code is not an OS operation, so the permission system does not look at it — the audit only sees OS operation events. The effect of rewritten G-code commands on the print is beyond the scope of this article.

Another operation not in OrcaSlicer’s table is executing code received as a string (Python’s exec or compile). Code that wraps its contents in a string and runs it is not asked about for the execution itself. Admittedly, if the executed contents touch the OS, they are caught individually as long as they are inside the audit context. So the “blind spots” fall into two layers: outside the context (load time, inside self-started threads), and things the audit never looks at (operations that do not touch the OS, native code).

Python’s own documentation is worth a look here. Both the Python docs and PEP 578 say audit hooks are for gathering information about internal, normally invisible behaviour, and are not suited to sandboxing. Note, though, that when the docs say “In particular, malicious code can trivially disable or bypass hooks added using this function.”, “this function” refers to the Python-side function sys.addaudithook. OrcaSlicer installs its hook with the C API. So that sentence cannot be applied to OrcaSlicer as is. What we can say is that “audit hooks as a mechanism are not a substitute for a sandbox”, which points the same way as OrcaSlicer saying of itself that it is “not a sandbox”.

PrusaSlicer’s sandbox — the Lua libraries it opens, and the functions it removes

PrusaSlicer loads Lua 5.4.8 through a library called sol2 and chooses which standard libraries to open. Only four are opened: base, table, math and string. The source reads as follows.

m_state.open_libraries(sol::lib::base, sol::lib::table, sol::lib::math, sol::lib::string);

There is no io, os, package or debug here. Neither coroutine nor utf8 is opened. On top of that, dofile, loadfile and load, which remain in base, are deliberately removed.

ban_keys(m_state, {"dofile", "loadfile", "load"});

The require used for loading modules is also replaced with one PrusaSlicer provides. It can only read files with the .lua extension, and only from inside the plugin’s folder. Paths pointing outside the folder (those starting with .. or empty ones) are rejected. The APIs for reading files from Lua sit on the same mechanism, and the functions that read STL and SVG are limited to the plugin’s folder too. So it is more accurate to say not that PrusaSlicer plugins “never touch files” but that they “can read only .lua, STL and SVG files in their own folder”.

This is also a contrast with OrcaSlicer. Because load, loadfile and dofile are removed, PrusaSlicer plugins have no way to run a string as code. The escape route of hiding contents in a string and executing them is closed at the entrance. In OrcaSlicer the same operation passes without being asked; PrusaSlicer simply does not hand over the operation. The difference in defensive layers shows up here too.

What about the network? No official Prusa sentence uses the words “no network access”. What we can say follows from two facts. First, Lua’s standard libraries have no networking at all. The standard libraries listed in the lua.org manual (basic, coroutine, package, string, utf8, table, math, io, os, debug) include no network library. And PrusaSlicer does not even open io, os, package or debug. Listing what the unopened libraries would have exposed makes the shape of the defence clear. os.execute runs a shell command, io.popen starts another program, os.remove deletes files, and package.loadlib links a C library. That package.loadlib is the exact counterpart of the native-code loading that OrcaSlicer does not audit. PrusaSlicer simply never hands over these entrances.

The plugin kind is narrowed to one as well. In the source there is only project.plugin, and the project describes its purpose as “The purpose of currently existing plugins is to create objects programmatically.” Creating objects is the aim; there is no G-code post-processing kind like OrcaSlicer’s. And as a big difference from OrcaSlicer, PrusaSlicer runs each .lua in a bundle once during its startup scan to read its information, but that run also happens inside the same restricted Lua. Putting even load-time code inside the restrictions is a contrast with OrcaSlicer. This is also an alpha version, and the project says the Lua API is experimental and may change.

Signed distribution — PrusaSlicer verifies the zip, OrcaSlicer clears permissions on reinstall

Since you install from a distribution channel, “is this plugin really from that author?” is also part of the pre-install check. PrusaSlicer has the signing tools in its CLI: three plugin subcommands, init, keygen and sign. keygen creates an RSA key pair, 2048 bits by default, with a choice of powers of two from 1024 to 8192. sign writes the SHA-256 of each file in the bundle to manifest.txt and signs that list with the private key into manifest.sign. When installing from a zip, the signature and each file are checked with the author’s public key, and the plugin is not installed if they do not match. The message on mismatch is “Plugin installation failed: Integrity verification failed for bundle”.

What we can state here, though, is only that “signatures are checked when installing from a zip”. The project describes the marketplace as “The marketplace is currently in testing and it will be launched in the near future.” — it is in testing. We do not describe it as launched. Which folders the startup scan covers, and whether users can register an author’s key themselves, could not be confirmed within this source. So we do not go as far as writing “drop it in the folder and it runs without a signature”.

OrcaSlicer has a different kind of safeguard. Every time a plugin is reinstalled or updated, all of that plugin’s permissions are revoked. The function in the source is named revoke_plugin_permissions, and the documentation also says new code must obtain permission again. On downloads from the cloud, the release notes say, “Cloud plugin downloads check the server’s certificate.” That confirms the connection reaches the right party; it does not mean the downloaded contents are reviewed. For Orca Cloud there is the explanation that “anyone can publish”, but as of 2026-10-20 we found no official explanation of pre-publication review, moderation or reporting procedures. Not finding one does not let us write “there is no review”. For the same reason, we do not write that OrcaSlicer plugins lack a signing mechanism, because we did not confirm that in this source.

We had AI review ten legitimate plugins — what this run showed

The classification so far comes from reading source and release notes. What happens if we have AI help with the pre-install reading? OrcaSlicer’s plugin mechanism lives in interface-side code, and this site does not operate the slicer interface. So we had claude -p read the source of ten legitimate plugins we had on hand, assign each plugin’s OS-touching operations to the permission categories (asked / blocked / passes), and looked at whether it could spot the unaudited places and whether it raised excessive warnings on legitimate plugins. We did not use test plugins with planted dangerous behaviour. We also wrote no code sending data to non-existent domains (such as .invalid, which RFC 2606 guarantees is invalid). We tested only with legitimate plugins.

The subjects were the seven official samples and three safe-to-install plugins made for another test. There were two conditions: “no documents”, where the AI judges by recalling the permission mechanism, and “with documents”, where we gave it the official developer documentation. Ten plugins under two conditions makes 20 runs. The cost for this session was about $1.5 in total. Each condition was run once, so what follows is a record of “this is what happened in this run”.

The results come down to three points. First, the AI correctly judged all ten as “safe to install”, in both conditions. Second, it never falsely warned that a legitimate operation would be “blocked”. Zero excessive warnings is an important property for a tool that judges plugin safety, because a check that keeps calling harmless things dangerous gets ignored over time. Third, it pointed out the unaudited places almost every time — code at load time, inside self-started threads, and native-code loading — regardless of condition. For one plugin it even noted that “numpy loads its own native extensions at import time, outside the audit”. However, these three are named in the review prompt itself: “If there are places that run unaudited, such as at load time, inside threads the plugin starts itself, or via ctypes, please point them out.” So what we confirmed is not that the AI discovered these angles from scratch, but that it applied the angles we named correctly to the source it was given and made them concrete. A finding that ties an angle to specific code, like numpy’s native extensions, is an example of that application working.

There was one concrete mix-up, though. For two plugins, it judged the act of starting a thread itself as “unaudited (passes)”. In the source, thread creation is in the Threading category and a confirmation appears. The AI confused the fact that the inside of a thread is outside the audit (which is correct) with how the moment of starting a thread is treated. It grasped the loophole as a concept correctly, but missed one individual rule. Also, operation classification matched in only 5 of 8 items partly because our scoring was crude: it counted the AI’s correct statement that it “reads an in-memory preset” as a file operation by string matching, an over-count. The AI’s description itself was accurate.

What this single run says is that when you have AI help with plugin safety, you can rely on its explanations of loopholes, but individual rules should be backed up with official documents. It did not run inside the interface, the versions are alphas, and each condition was run once. This is not broad enough to generalize.

The way to think about having AI read code and look for dangerous spots, and to judge its output fairly, connects to evaluating AI systems in general.

AI Engineering: Building Applications with Foundation Models

USD 52.40 on Amazon.com (as of 2026/09/22)

Amazon

ポチップ

What to check before installing

Slicer plugin security is not a feature that works after installation; it is decided by what you look at before installing. Turning the design of the two slicers into a pre-install check looks like this.

• Check the source. Both projects say to install only from trusted sources. Neither a permission system nor a sandbox can fully stop code that deliberately takes a detour
• Check the version. Both are alphas, and the projects state that the APIs will change. Read with the assumption that behaviour may change in the stable releases
• If you install into OrcaSlicer, keep in mind that outside the data folder you are asked but inside it you are not; that reinstalling clears permissions; that load time, the inside of threads and native code are outside the audit; and that the config file and token are blocked by name prefix, while folders such as secrets and config are blocked by exact name match (even inside the data folder)
• If you install into PrusaSlicer, keep in mind that it is a sandbox that does not give Lua dangerous functions; that only .lua, STL and SVG files in the plugin’s own folder can be read; and that signatures are checked when installing from a zip (the marketplace is in testing)
• If you have AI read plugins, use it to explain loopholes, and back up individual rules with official documents

The distribution channel itself calls for the same stance. It is a separate matter from slicer plugins, but on MakerWorld, Bambu Lab’s model-sharing site, the official account replied on the forum on 2026-09-01 that remixes flagged as problematic had been taken down. That happened on model pages, not with slicer plugins. The one point of checking the source before installing or opening something is the same for plugins and models alike. In the end, plugin security comes down to what you checked in the few seconds before pressing Yes.

Whether to grant a permission or never hand it over in the first place — you face the same question when you let AI agents use external tools.

AI Agents in Action, Second Edition

USD 47.48 on Amazon.com (as of 2026/09/22)

Amazon

ポチップ

Sources

• OrcaSlicer v2.5.0-alpha release notes
• OrcaSlicer src/slic3r/plugin/PluginAuditManager.cpp (pinned commit 3880f2c)
• OrcaSlicer official wiki: Plugin Audit Hook
• PrusaSlicer 3.0.0-alpha11 release notes
• PrusaSlicer LuaEngine.cpp (pinned commit 30ef591)
• PrusaSlicer PluginCliOps.cpp (pinned commit 30ef591)
• Python 3.12 docs: sys (audit hooks)
• PEP 578 – Python Runtime Audit Hooks
• Lua 5.4 Reference Manual
• Bambu Lab forum thread (including the MakerWorld official account’s reply)

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.