Uncategorized

Hazina Plugin Security: Sandboxing Runtime-Generated Code

Running dynamically generated code in production sounds scary. And it should – if you do it wrong. Hazina’s plugin sandbox is designed with security as the primary concern, using multiple layers of protection.

Defense in Depth

Hazina uses four layers of security for plugins:

  1. Compilation-time analysis – Block dangerous code before it compiles
  2. Namespace whitelisting – Only approved APIs are available
  3. Runtime sandbox – Timeout and memory limits
  4. Service injection control – Plugins only access services you explicitly allow

Compilation-Time Security

// These patterns are blocked at compile time:
// - Direct file system access (System.IO.File, Directory)
// - Raw network calls (Socket, HttpClient)
// - Process execution (Process.Start)
// - Reflection (Assembly.Load, Type.InvokeMember)
// - Thread manipulation (Thread.Start, Task.Run)

Configuring the Sandbox

builder.Services.AddHazinaPlugins(options => {
    options.Security = new PluginSecuritySettings {
        // Namespace whitelist
        AllowedNamespaces = new[] {
            "System",
            "System.Linq",
            "System.Collections.Generic",
            "System.Text.Json",
            "MyApp.Models"   // Your own safe types
        },

        // Execution limits
        MaxExecutionTime = TimeSpan.FromSeconds(30),
        MaxMemoryMB = 128,

        // Service access
        AllowedServices = new[] {
            typeof(IEmailService),
            typeof(ILogger),
            typeof(IDocumentStore)
        }
    };
});

The Plugin Context

Plugins don’t have direct access to DI – they go through a controlled context:

// Inside a plugin:
var logger = context.GetService<ILogger>();    // OK - whitelisted
var db = context.GetService<DbContext>();       // Throws - not whitelisted
var param = context.GetParameter<Customer>("customer"); // Safe parameter access

Timeout Protection

try
{
    var result = await pluginManager.ExecuteAsync("MyPlugin", parameters);
}
catch (PluginTimeoutException ex)
{
    logger.LogWarning("Plugin {Name} timed out after {Duration}",
        ex.PluginName, ex.Duration);
}

Audit Trail

Every plugin execution is logged:

  • Who created the plugin
  • When it was compiled
  • Every execution with duration and result
  • Version history with diffs

In the next post, we’ll look at Agent Orchestration – Hazina’s framework for building autonomous AI agents.

Frequently Asked Questions

How does Hazina ensure the security of runtime-generated code?

Hazina employs a multi-layered security approach called Defense in Depth, which includes compilation-time analysis to block dangerous code, namespace whitelisting for approved APIs, a runtime sandbox with execution limits, and controlled service access for plugins.

What types of code are blocked at compile time in Hazina?

Hazina blocks several dangerous code patterns at compile time, including direct file system access, raw network calls, process execution, reflection, and thread manipulation, ensuring that only safe code can be executed.

How can developers configure the Hazina plugin sandbox?

Developers can configure the Hazina plugin sandbox by using the `AddHazinaPlugins` method, where they can set security options such as allowed namespaces, execution limits, and permitted services to control what the plugins can access.

What information is logged during plugin execution in Hazina?

Hazina logs comprehensive details during plugin execution, including who created the plugin, when it was compiled, each execution’s duration and result, and version history with diffs, providing a thorough audit trail for accountability.

Terug naar overzicht
ENNL