Datapacks lack a security boundary for command execution

Summary

The current Minecraft Java Edition datapack system is not a security sandbox. Datapacks can execute Minecraft commands through .mcfunction files and interact with a large portion of the game's command and data systems, but there is no general-purpose capability or permission boundary separating an individual datapack from the command engine.

This becomes increasingly problematic as datapacks are used for complex automation, administration systems, libraries, and large-scale gameplay frameworks.

Security concern

The primary concern is not that a normal .mcfunction file inherently provides arbitrary operating-system access. Rather, the concern is that the datapack execution model is not designed to be a security boundary.

Complex datapacks therefore have to implement their own validation, permission checks, input handling, and execution restrictions on top of the command system.

Dynamic command construction and macro/function mechanisms can also make this model more difficult to reason about securely, because data can become part of command execution.

A datapack should therefore not be treated as equivalent to a sandboxed plugin or isolated extension.

Architectural concern

As datapacks become more sophisticated, developers increasingly have to build a secondary security and execution layer around the command engine:

• custom permission systems

• command/input validation

• namespace conventions

• execution restrictions

• state management

• defensive checks around dynamic commands

• increasingly complex tick-based execution systems

This creates substantial complexity and makes security dependent on individual datapack implementations.

Proposed solution

Instead of continuously expanding the datapack command model, Minecraft could introduce a first-class Native Extension Runtime based on a capability-oriented API.

For example:

Minecraft
    │
    ▼
Extension Runtime
    │
    ├── Event API
    ├── Capability/Permission API
    ├── Player API
    ├── World API
    ├── Resource API
    └── Controlled Command API
             │
             ▼
         Extensions

Each extension would declare the capabilities it requires, and the runtime would enforce those capabilities rather than requiring every developer to implement an independent security layer.

The runtime could also provide event-driven execution instead of relying heavily on permanent tick/function chains.

Compatibility

This does not necessarily require immediate removal of datapacks.

A compatibility layer could allow existing datapacks to continue functioning while new projects migrate to the new runtime:

Legacy Datapack
       │
       ▼
Compatibility Runtime
       │
       ▼
Native Extension Runtime

Datapacks could eventually become a legacy compatibility format while the capability-based extension API becomes the preferred architecture for complex systems.

Expected benefits

Such an architecture could provide:

• a clearer security boundary

• explicit capability-based permissions

• stronger type safety

• event-driven execution

• better performance for complex systems

• reduced reliance on large tick/function graphs

• a more maintainable API for developers

• safer composition of third-party extensions

• a cleaner migration path away from increasingly complex datapack frameworks

The goal is not to remove the flexibility of datapacks, but to provide a properly isolated and capability-controlled extension mechanism for workloads that exceed what the command-based datapack model was designed to handle.

Relation to existing mod loaders

A natural objection is that Fabric, Forge, and NeoForge already provide this kind of capability. That is true, but they require a separate installation, are not officially supported, and are unavailable on many servers and platforms where only vanilla-compatible datapacks can run.

The proposal here is not to duplicate what mod loaders do, but to offer an officially supported, zero-install middle ground for developers who need real execution safety without requiring players or server operators to install a mod loader. Datapacks would remain the entry point for simple content; the extension runtime would be the officially supported option for complex systems that currently have no safe path other than "become a mod."

Cost and migration considerations

Introducing a Native Extension Runtime and a Compatibility Runtime is a substantial engineering investment, not a lightweight addition. Maintaining two parallel execution semantics (raw commands vs. capability-checked calls) indefinitely carries real long-term maintenance cost, and the compatibility layer would need to preserve exact command-engine behavior to avoid silently breaking existing datapacks.

Any implementation of this proposal should be expected to ship incrementally — for example, starting with an opt-in Capability/Permission API layered on top of the existing command engine, rather than a full runtime rewrite — so the security benefit can be delivered without committing to the full architecture